You're right that fighting these cookies is not trivial and automation helps a l...

jefftk · 2024-01-12T16:45:59 1705077959

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/ ?

the_mitsuhiko · 2024-01-12T17:20:39 1705080039

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

jefftk · 2024-01-12T17:27:24 1705080444

> 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 · 2024-01-12T17:34:20 1705080860

The 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 · 2024-01-12T17:37:31 1705081051

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_mitsuhiko · 2024-01-12T17:40:25 1705081225

The purpose and functionality of the cookie is what matters, not the duration.

jefftk · 2024-01-12T17:44:31 1705081471

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_mitsuhiko · 2024-01-12T17:51:44 1705081904

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.

jefftk · 2024-01-12T18:17:36 1705083456

> The opinion document as far as I'm aware has no legal force.

Agreed! But without this guidance we're just stuck guessing what "strictly necessary" means.

jefftk · 2024-01-12T16:37:25 1705077445

Thanks! Also, I did figure out how to reproduce the Vimeo player cookie. If I visit https://docs.sentry.io/product/performance/performance-video... I get a __cf_bm cookie from player.vimeo.com.

the_mitsuhiko · 2024-01-12T17:21:25 1705080085

Thanks. Going to look into that one.

jefftk · 2024-01-13T02:47:18 1705114038

I looked a bit more: it's documented at 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!)