4 ms·
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 sandbo
by 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 agoThanks! 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 agoThanks. Going to look into that one.
- jefftk 3y agoI 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 agoPoking 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/ ?
- the_mitsuhiko 3y agoA 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 :)
- jefftk 3y ago> A lot of these cookies are used to prevent CSRF Maybe I'm being dense, but I don't see CSRF risks with a login form? > once you go to a login page I'm pretty sure you will log in That seems very reasonable to me, but I don't think it's what the e-Privacy directive says? (I'm in general very sympathetic, and wish the directive set a lower bar than "strictly necessary" for functional client-side storage.)
- the_mitsuhiko 3y agoThe ePrivacy directive is not that descriptive. The use of this cookie is fine as per legal review. All our forms have the same CSRF protection, that goes for login and other things too.
- jefftk 3y agoI 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_mitsuhiko 3y agoThe purpose and functionality of the cookie is what matters, not the duration.
- jefftk 3y agoThe 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/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio... you'll see lots of discussion of appropriate durations.