While they removed cookie banners and say they no longer include dependencies that set cookies, browsing around the site for a bit I still see several cookies set. For example, visiting https://changelog.getsentry.com I get first-party cookies "_GRECAPTCHA", "ph_phc_UlHlA3tIQlE89WRH9NSy0MzlOg1XYiUXnXiYjKBJ4OT_posthog", and "_launchnotes_session", plus third-party cookie "_GRECAPTCHA" on recaptcha.net.
I also got a player.vimeo.com cookie at some point, but wasn't able to reproduce.
If you're running a complex modern site and decide to do away with cookie banners, you generally need to pair this with browser automation that crawls your site and verifies that you (and your dependencies) are in fact not setting any cookies.
You're right that fighting these cookies is not trivial and automation helps a lot. The remaining cookies are functional ones which are needed to use the sandbox for instance. That the changelog sets cookies is a known issue that will be resolved once the changelog is moved off launchnotes.
Poking around a bit more, visiting https://sentry.io/auth/login/ but performing no action sets first-party cookies __stripe_mid, __stripe_sid, session, and sentry-sc. If I don't log in, but then visit other pages on the site those cookies are still sent.
I don't see why it's necessary that that these cookies be set before I actually log into the page? Or, if it is necessary for a non-obvious reason, I don't see why they need to be sent when visiting other pages under sentry.io instead of being scoped to /auth/login/ ?
A lot of these cookies are used to prevent CSRF or tracking flow state (eg: redirect target for login) through SSO. I'm not sure about the behavior of the stripe one. Generally once you go to a login page I'm pretty sure you will log in :)
I really don't see how a duration of one year and Same-Site=Lax on the sentry-sc cookie passed legal review, but perhaps your legal team is comfortable with a more aggressive approach than I'm used to.
The duration is part of the functionality. In interpreting the e-Privacy directive a general principle is that durations should not be longer than required to implement the required functionality. If you read through https://ec.europa.eu/justice/article-29/documentation/opinio... you'll see lots of discussion of appropriate durations.
The opinion document as far as I'm aware has no legal force. That said, I'm sure durations can always be re-evaluated but the case of "i'm going to log in but then not" is a corner case that's not exactly top of mind. I think the bigger task here is to defer loading stripe until necessary.
I think this is a grey area: I can't find any explicit official guidance on whether using cookies to detect bots fits within the e-Privacy exemptions. (I had thought it didn't but that's not worth much!)
> If you're running a complex modern site and decide to do away with cookie banners, you generally need to pair this with browser automation that crawls your site and verifies that you (and your dependencies) are in fact not setting any cookies.
Correction: any cookies which are not technically required for the basic operation of the site (such as a shopping cart ID).
I'm out of the loop on the latest and greatest web technologies:
if I'm a shopping cart website, how do I keep track of you as a user/session enough to identify you and pair you to the contents of your cart on my backend without a cookie?
Cramming a sessionId into localStorage/sessionStorage seems kind of like the same thing? Am I missing somehting?
The post you were replying to (unless it was edited after your reply) specifically mentioned a shopping cart cookie as one that could be classed as strictly necessary. There are other options but they have issues (tracking via query string or form values doesn't work well with multiple tabs open for instance). The cart ID can be the session ID too for as long as it is needed.
Of course they don't have to be stored, in fact they shouldn't be stored. They are session level naturally so belong in session level cookies not more permanent storage.
Also, while session tokens in cookies are usually fine to be defined as strictly essential for the main site, they are generally not for 3rd party cookies.
> localStorage/sessionStorage seems kind of like the same thing? Am I missing somehting?
No, those are more often used in equivalent ways to cookies though they don't do exactly the same job, extra logic is needed if your server-side needs to access the stored information. Cookie values are sent to the web server(s) with every request (except where certain flags are set), data in session/local storage needs to be explicitly read out and sent on in GET or POST parameters when needed.
Before cookies we used session ids in the query string of the URLs. Maybe you noticed some URL with a JSESSIONID argument in the URL. Same thing.
Those are worse than cookies for a number of reasons but they are functionally equivalent.
Anyway, there is nothing wrong with cookies in general. Privacy-wise the problem are cookies used for tracking. Any other technology would have the same problems and would need an explicit consent from the user, if you are subject to GDPR and similar legislation.
I believe that under GDPR cookies that are used only for technical purposes and not related to personal information are exempt from any consent and don't need to be informed with the infamous cookie banner.
Is not about cookies, is about their content and purpose.
Persisting login cookies if the user didn't explicitly consent to data collection is specifically _not_ exempted by ePrivacy. To quote a EU Working Group's opinion on this: 'Persistent login cookies which store an authentication token across browser sessions are not exempted under CRITERION B. This is an important distinction because the user may not be immediately aware of the fact that closing the browser will not clear their authentication settings. They may return to the website under the assumption that they are anonymous whilst in fact they are still logged in to the service. The commonly seen method of using a checkbox and a simple information note such as “remember me (uses cookies)” next to the submit form would be an appropriate means of gaining consent therefore negating the need to apply an exemption in this case.'
While the GDPR has added additional restrictions, the basic framework is still in force: you can't store information client-side (cookies, localStorage etc) unless (a) it is "strictly necessary" to fulfill a user request or (b) you get user consent. All the cookies above look to me like they don't meet that bar; the site seems to still fulfill my requests with cookies disabled.
They might be tracking whether I'm logged in, but since I didn't log into the site I didn't consent for them to store that state on my client. The e-Privacy directive is quite particular, and unless these cookies are "strictly necessary" to operate the sandbox they're not allowed.
A CSRF vulnerability on a login form is a bit of a weird one: doesn't this require that the user has submitted their username and password to a site that isn't yours, in which case the attacker has successfully phished the user and can impersonate them or keep them on a proxy of your site?
(Spitballing: a standard way to implement CSRF protection with no cookies at all is when you generate the form you include a nonce. Then when the form is submitted you check whether it's a nonce you generated, which you do either by having stored it or generated it by hashing information you've stored. Implemented naively on a login form this would allow the attacker to fetch your page, extract the nonce, and include it in a cross-site request. But you could require it to be from the same IP. Alternatively I think you could fix this by having your login form set a custom header, which then browsers won't allow a cross-site POST for without a CORS preflight which you'd reject. But at this point I'm brainstorming and please don't take any of this very seriously!)
Why would you ever use a cookies to store a CSRF token? A CSRF token is a per request value and that's not what cookies are designed for. Generally the CSRF token is a hidden value on the login form.
In that case the cookie can at least be scoped to the login form with a Path attribute and limited to the current session, which these aren't. The cookies on https://sentry.io/auth/login/ set without user intervention are valid beyond the current browser session and two of them have durations of a year. One even has Same-Site=Lax!
(It's also not clear to me that cookies are required, if there are other technically sound options that do this without setting cookies.)
If you authenticate users only via Same-Site=Strict cookies you're protected against CSRF in modern browsers: a cross-site request won't have the auth cookie.
Session cookies are often encrypted by frameworks using a server side secret.
This allows storing data such as the CRSF token value to check against the one in the hidden form element or X-CSRF-Token without inserting in a DB every time someone loads up a form.
Note that to prevent session fixation, the session ought to be reset on a successful login (and logout), so it would require additional code to perform tracking across a successful login.
Session cookies are also used for Rails flash messages, commonly used to display errors in forms (including login forms), which often do HTTP redirects to GET routes in their non-GET controller actions.
The underlying subtext is that these session cookies can be a necessity of securing the provided service, and thus can fall under valid "strictly necessary" usage, as long as they are not abused for tracking (by default nothing in the session cookie is stored nor logged anywhere)
It might also just be done by whatever underlying web framework they use without them realizing. Like maybe a call to a method that checks if you are authenticated creates those cookies deep in some library they have less control / ownership of. Just taking a guess.
Possibly! But then they need to choose: take full control of their stack to where they can ensure it doesn't set unnecessary cookies, or use cookie banners.
If they're essential for doing what the user wants, though, then (a) no one cares and (b) they don't need e-Privacy consent and so don't need a cookie banner.
Similarly, visiting https://try.sentry-demo.com I got cookies "sentrysid", "sc", and "sudo".
I also got a player.vimeo.com cookie at some point, but wasn't able to reproduce.
If you're running a complex modern site and decide to do away with cookie banners, you generally need to pair this with browser automation that crawls your site and verifies that you (and your dependencies) are in fact not setting any cookies.