Application-monitoring company Sentry recently wrote about their experience removing cookies on their site, which allowed them to drop their cookie banner. I'm glad they wrote this up! But it also illustrates why many sites have cookie banners even when they don't seem to being doing anything risky.

I was curious whether their site actually did avoid setting any cookies, and visited it in a private browsing window with third-party cookies enables. As I browsed around the site I noticed several cookies being set:

• Loading changelog.getsentry.com I received first-party cookies _GRECAPTCHA, ph_phc_UlHlA3tIQlE89WRH9NSy0MzlOg1XYiUXnXiYjKBJ4OT_posthog, and _launchnotes_session, plus third-party cookie _GRECAPTCHA on recaptcha.net.

• Loading try.sentry-demo.com I received first-party cookies sentrysid, sc, and sudo.

• Loading sentry.io/auth/login I recieved first-party cookies __stripe_mid, __stripe_sid, session, and sentry-sc, plus a third-party cookie m on m.stripe.network.

• Loading docs.sentry.io/product/performance/performance-video I received third-party cookie __cf_bm from player.vimeo.com.

It's possible there are others; I didn't run any sort of exhaustive search.

Now, Sentry does say:

For clarification, Sentry has removed all cookies, other than essential cookies that do not require site visitor consent. Work with your legal team to better understand which of your cookies qualify as essential cookies under the laws that apply to you.

And from a perspective of removing cookie banners this is right: you don't need to completely stop using cookies, you just need to limit your use of cookies to cases that are "strictly necessary in order to provide an information society service explicitly requested by the subscriber or user". For example, per the official guidance some things that are ok include setting a cookie when someone logs in, chooses a setting like "dark mode", or adds an item to their shopping cart: you can't do what the user asked for without cookies. But even then, you have to be quite careful to stay within the narrow limits of this exception: the guidance clarifies that you should generally use an expiration of a few hours or configure the cookie to be deleted when the user closes their browser.

Looking over the cookies they're currently setting, it doesn't look to me like they fall within this exception:

• I don't see any reason why the changelog page would need to set cookies. When I asked they said this was a known issue that they were working on fixing.

• While it's possible that the Sandbox implementation does fundamentally require cookies, because it's simulating a complex application you'd normally log in for, if you first load the sandbox none of that is accessible. It has a modal dialog asking for you work email address, and without it none of the functionality works. They should at least postpone setting the cookies until you've submitted the form:

  

• I don't see why a login page requires setting any cookies: while you do need to set a cookie if the user actually logs in, I just loaded the page. When I asked they brought up CSRF prevention but that's a bit of a strange one. CSRF is an attack an attacker site directs the browser to submit a form to a victim site. If the victim site isn't taking steps to fight CSRF then it won't understand that the user didn't actually initiate this request, and the attacker can use this to take actions as the victim. But a CSRF vulnerability on a login would imply that the attacker had already successfully phished the user, at which point they can already initiate any action they wish on behalf of the user.

  Even if these cookies are needed to prevent CSRF in a way I'm not seeing, I don't see why you would need one like sentry-sc that has a one-year expiration and a Same-Site=Lax opt in to being shared in third-party contexts. And since none of these use Path to scope themselves to just the login form, once you've visited that page you'll be sending cookies on every future pageview anywhere on the site.

• The Vimeo third-party cookie __cf_bm, is more debatable. It's documented 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.

Overall I have a lot of sympathy for Sentry here. They're trying to be careful in how they use cookies, and I think cookies they have are mostly very reasonable and shouldn't require a cookie banner. On the other hand they do seem to me, as a lay person, to be out of compliance with the e-Privacy directive.

I think this is a good demonstration of why companies generally do choose to stick with cookie banners even though they're annoying. Technically-inclined users will say that as long as you're not doing anything nefarious you don't need to ask consent, but the exceptions the regulations set out are really quite narrow and it's easy to go wrong.

(I'd love to see the regulations changed here: there's no reason to single out storing data on the client for special treatment. The general protections in the GDPR offer a much more consistent approach to data privacy, and I'm not convinced e-Privacy adds anything useful anymore. And then, of course, a regulation that leads to cookie banners and other consent walls everywhere that people mostly click through without reading is clearly not working well.)