Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We removed advertising cookies, here's what happened

blog.sentry.io

Post reply on HN
Print view View original

141–150 of 191 posts

Re: We removed advertising cookies, here's what happened

#141

Post by jefftk »

giancarlostoro wrote: post #137
jefftk wrote: post #117

Earlier quoted context omitted.

The way most sites do this is that absence of a cookie indicates not logged in; any reason this wouldn't work here?

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.

Re: We removed advertising cookies, here's what happened

#142

Post by the_mitsuhiko »

jefftk wrote: post #113
the_mitsuhiko wrote: post #107

Earlier quoted context omitted.

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.

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.

Thanks. Going to look into that one.

Re: We removed advertising cookies, here's what happened

#143

Post by giancarlostoro »

jefftk wrote: post #141
giancarlostoro wrote: post #137

Earlier quoted context omitted.

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.

I am certain if I am in any way right they could overprice the behavior, but im making a wild guess. Or maybe they missed a page.

Re: We removed advertising cookies, here's what happened

#144

Post by the_mitsuhiko »

zilti wrote: post #123
dxdm wrote: post #37

Earlier quoted context omitted.

Could you elaborate on what they are doing?

Sentry scans all data sent to it to train their problem solving assistant, no matter if you use it or not, and there is no opt-out.

That is incorrect. We are not doing that.

Re: We removed advertising cookies, here's what happened

#145

Post by jefftk »

the_mitsuhiko wrote: post #140
jefftk wrote: post #119

Earlier quoted context omitted.

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 t…

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

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

Re: We removed advertising cookies, here's what happened

#146

Post by mark_story »

shkkmo wrote: post #127
mark_story wrote: post #121

Earlier quoted context omitted.

That's fair, not having a cookie could work for session, how would you handle CSRF protection on a login form without cookies?

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.

Cookies are used for double-submit CSRF protection pattern. One copy of the CSRF token is put into a hidden form field, and the other is in a cookie.

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

Re: We removed advertising cookies, here's what happened

#147

Post by stalfosknight »

b2bsaas00 wrote: post #29

I have a campaign with a UTM link, once the user lands on our page we save this UTM as cookie and then we persist on our db at sign up. Is this complaint with GDPR and will it still possible in the future?

Can we just not have all that tracking bullshit in URLs please?

Re: We removed advertising cookies, here's what happened

#148

Post by firejake308 »

araes wrote: post #139

The most interesting part of this article personally was "Google's getting rid of cookies". Wait, what? How is this the first time I've heard of this? Apparently the move is already delayed until Q2 2024 (lots of pushback at the office) [1] However, it's still difficult to believe. Must be an utter nightmare for people who built their entire business stack on cookies. [1] https://techcrunch.com/2022/07/27/google-dela…

I guess they're trying to push their new Topics API instead?

Re: We removed advertising cookies, here's what happened

#149

Post by jefftk »

mark_story wrote: post #146
shkkmo wrote: post #127

Earlier quoted context omitted.

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.

Cookies are used for double-submit CSRF protection pattern. One copy of the CSRF token is put into a hidden form field, and the other is in a cookie. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

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

Re: We removed advertising cookies, here's what happened

#150

Post by the_mitsuhiko »

jefftk wrote: post #145
the_mitsuhiko wrote: post #140

Earlier quoted context omitted.

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

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

Post reply on HN