6 ms·

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 s

by jefftk 3y ago

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 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. Similarly, visiting https://try.sentry-demo.com 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.

soyyo 3y ago
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.
- jefftk 3y ago
  Cookie banners predate the GDPR, and were initially a response to the ePrivacy Directive of 2002: https://en.wikipedia.org/wiki/EPrivacy_Directive https://en.wikipedia.org/wiki/EPrivacy_Directive 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. (Not a lawyer.)
- Waterluvian 3y ago
  Indeed. Cookies are incredibly useful for things the user really does want, like staying logged in across sessions/tabs.
  - jefftk 3y ago
    A login cookie does not require a consent banner, because logging in is an explicit user request. But I didn't log into Sentry in my testing.
    - orbat 3y ago
      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.' You can find the full opinion text here https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio...
      - jefftk 3y ago
        Sorry;you're right! I should have given the caveat that the login needs to be accompanied by a checkbox like that.
- deleted 3y ago
  [deleted]
ThePowerOfFuet 3y ago
> 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).
- MuffinFlavored 3y ago
  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?
  - johnkpaul 3y ago
    A link to the iOS App. :-D
  - pmontra 3y ago
    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.
  - jefftk 3y ago
    Using cookies or other client-side storage for a shopping cart doesn't require a cookie banner as long as you're careful to use the minimum practical duration. See section 2.3 of https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio... If you want to persist the cart for longer than the current session or a few hours, though, you need consent.
mark_story 3y ago
The sentrysid, sc, and sudo cookies are all login state cookies btw.
- jefftk 3y ago
  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.
  - mark_story 3y ago
    I believe that knowing whether or not you are logged would be part of the strictly necessary.
    - jefftk 3y ago
      The way most sites do this is that absence of a cookie indicates not logged in; any reason this wouldn't work here?
      - mark_story 3y ago
        That's fair, not having a cookie could work for session, how would you handle CSRF protection on a login form without cookies?
        shkkmo 3y ago
        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.
        jefftk 3y ago
        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.
deleted 3y ago
[deleted]
the_mitsuhiko 3y ago
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.
- jefftk 3y ago
  Thanks! Also, I did figure out how to reproduce the Vimeo player cookie. If I visit https://docs.sentry.io/product/performance/performance-video/ https://docs.sentry.io/product/performance/performance-video... I get a __cf_bm cookie from player.vimeo.com.
  - the_mitsuhiko 3y ago
    Thanks. Going to look into that one.
    - jefftk 3y ago
      I looked a bit more: it's documented at https://help.vimeo.com/hc/en-us/articles/12426260232977-Player-parameters-overview https://help.vimeo.com/hc/en-us/articles/12426260232977-Play... as an 'essential cookie' "which is part of Cloudflare's Bot Management service and helps mitigate risk associated with spam and bot traffic." 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!)
- jefftk 3y ago
  Poking around a bit more, visiting https://sentry.io/auth/login/ 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/ ?

by jefftk 3y ago

soyyo 3y ago

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.

jefftk 3y ago
Cookie banners predate the GDPR, and were initially a response to the ePrivacy Directive of 2002: https://en.wikipedia.org/wiki/EPrivacy_Directive https://en.wikipedia.org/wiki/EPrivacy_Directive 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. (Not a lawyer.)
Waterluvian 3y ago
Indeed. Cookies are incredibly useful for things the user really does want, like staying logged in across sessions/tabs.
- jefftk 3y ago
  A login cookie does not require a consent banner, because logging in is an explicit user request. But I didn't log into Sentry in my testing.
  - orbat 3y ago
    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.' You can find the full opinion text here https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio...
    - jefftk 3y ago
      Sorry;you're right! I should have given the caveat that the login needs to be accompanied by a checkbox like that.
deleted 3y ago
[deleted]

ThePowerOfFuet 3y ago

> 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).

MuffinFlavored 3y ago
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?
- johnkpaul 3y ago
  A link to the iOS App. :-D
- pmontra 3y ago
  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.
- jefftk 3y ago
  Using cookies or other client-side storage for a shopping cart doesn't require a cookie banner as long as you're careful to use the minimum practical duration. See section 2.3 of https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio... If you want to persist the cart for longer than the current session or a few hours, though, you need consent.

mark_story 3y ago

The sentrysid, sc, and sudo cookies are all login state cookies btw.

jefftk 3y ago
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.
- mark_story 3y ago
  I believe that knowing whether or not you are logged would be part of the strictly necessary.
  - jefftk 3y ago
    The way most sites do this is that absence of a cookie indicates not logged in; any reason this wouldn't work here?
    - mark_story 3y ago
      That's fair, not having a cookie could work for session, how would you handle CSRF protection on a login form without cookies?
      - shkkmo 3y ago
        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.
        jefftk 3y ago
        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.

deleted 3y ago

[deleted]

the_mitsuhiko 3y ago

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.

jefftk 3y ago
Thanks! Also, I did figure out how to reproduce the Vimeo player cookie. If I visit https://docs.sentry.io/product/performance/performance-video/ https://docs.sentry.io/product/performance/performance-video... I get a __cf_bm cookie from player.vimeo.com.
- the_mitsuhiko 3y ago
  Thanks. Going to look into that one.
  - jefftk 3y ago
    I looked a bit more: it's documented at https://help.vimeo.com/hc/en-us/articles/12426260232977-Player-parameters-overview https://help.vimeo.com/hc/en-us/articles/12426260232977-Play... as an 'essential cookie' "which is part of Cloudflare's Bot Management service and helps mitigate risk associated with spam and bot traffic." 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!)
jefftk 3y ago
Poking around a bit more, visiting https://sentry.io/auth/login/ 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/ ?