disable user tracking cookies
Closed this issue · 3 comments
There should be a way to completely disable all user tracking cookies.
All that is needed is to not call SetUser() in the client constructor.
Hi, thanks for the feedback :-)
Firstly (and possibly most importantly), I agree there should be a way of disabling cookies. Moving past that, and in the interests of coming up with an improved approach, let me explain why we do this. User tracking is great when you want to identify a user - it's also great when you don't want to identify a user but understand the impact of an error.
For example, if you have an error happen 10000 times, is it a bad thing? It sounds like a bad thing. But what if it only affected 1 user? And you had a million happy users? What if that one user was a spam bot?
Our fundamental goal is to build the best error service available, and that means we're focused on not just building a quantitative tool, but a qualitative tool. Understanding real impact falls into the quality bucket.
So, when we set a user initially, it's just a random token. That way, at the very least, we can figure out at our end if the number of affected users is high or low. It's not identifying, you can think of it as a correlation token. If you want to set more details, like an email address, you can - and that will provide more info in Raygun, but you don't have to.
Generally speaking, I'm not personally keen to drop qualitative features. But, going back to the start of my reply, I'd be happy to find a way to avoid cookies if possible :-) I'd also ask to know the reason you're unhappy with Raygun setting a cookie (plenty of good reasons, just curious of yours).
I hope that helps explain the thinking!
You're letting an error tracking component bleed features into other parts of the application and then forcing an implementation. Too many assumptions in this design about the system it will be used in. What if the consuming system doesn't support cookies such as a REST API? Or not even have the concept of a user? Or already have a different user id storage mechanism? Why not just use the client IP address as a proxy for user rather than expecting people to store personally identifiable information in you system? Why would you need three cookies for this?
This resolved my Airbrake vs Raygun question.
Thanks for the feedback. We will be adding a feature to disable the user tracking which will appear in a release shortly along with #42. This will take care of systems which do not support the concept as in your first and second points.
The user having a different user ID storage mechanism is specifically taken care of by the fact that SetUser takes parameters which they can use to specify their custom IDs and any other (optional) data they wish. This is in line with the other providers and the overall goal for Raygun to provide a first-class experience around visualizing where and why their errors are occurring, and to whom, as John-Daniel has previously mentioned.
By default we do not use or expect personally identifiable information such as the end-user IP address to identify the end user - as a result a UUID is stored against them. The user is of course free to provide the IP address as an ID to SetUser() if they so choose. Three cookies are used due to needing to record whether a random UUID was assigned or whether a user-specified ID was provided, and the isAnonymous field is for feature-parity with the other providers and is reserved for usage by Raygun at a later date.