Live data from Hacker News

We removed advertising cookies, here's what happened

blog.sentry.io

121–130 of 191 posts

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

#121
post #117

Earlier quoted context omitted.

I believe that knowing whether or not you are logged would be part of the strictly necessary.

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

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

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

#122

Earlier quoted context omitted.

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

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?

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

If you want to persist the cart for longer than the current session or a few hours, though, you need consent.

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

#123
post #37
post #26

Earlier quoted context omitted.

The same stance on privacy that somehow makes it okay for you to scan all your users' code for AI training without consent?

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.

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

#124
post #85

> 42.7% of internet users worldwide use ad blockers. Given how many people I know that still type google into the google search bar, I find this number to be extraordinarily high.

This was the money shot here. If that many people are trying to get away from what you do, maybe you shouldn't be doing it.

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

#125
post #95
post #4

Funny that the site tries to load some garbage from googletagmanager.com

Ah, GTM. I think people might be shocked that access to this RCE backdoor is often given to non-technical roles and even outsourced marketing resources..With no controls in place at all. Security nightmare.

That's why at Sentry non-technical people don't have the ability to publish new GTM versions. It's tightly controlled because we don't want marketing to shove things in there without engineering and security reviewing.

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

#126
post #49
post #46

Earlier quoted context omitted.

But even if you only use your own cookies, you will still have to show one of those annoying cookie banners first...

Only if you use the cookies to track users. Cookies like authentication and things needed by the website to work do not require the banner. And so I think Sentry did the right thing, one can go to sentry.io and browse without having this fugly banner to dismiss every time.

Authentication is the most reliable form of user tracking.

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

#127
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?

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.

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

#128
post #63

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 I get first-party cookies "_GRECAPTCHA", "ph_phc_UlHlA3tIQlE89WRH9NSy0MzlOg1XYiUXnXiYjKBJ4OT_posthog", and "_launchnotes_session", plus third-party cookie "_GRECAPTCHA" on recaptcha.net. Similarly, visi…

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

Still cookies though even if essential.

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

#129
> We market to developers who notoriously do not like being marketed to (we should know; we are a developer-led company and Sentry users ourselves), so the idea of removing ad cookies instantly intrigued us.

Ooh, they're going after that anti-marketer market. That's a huge market! Look at our research!

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

#130
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?

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

A CSRF vulnerability on a login form is a bit of a weird one: doesn't this require that the user has submitted their username and password to a site that isn't yours, in which case the attacker has successfully phished the user and can impersonate them or keep them on a proxy of your site?

(Spitballing: a standard way to implement CSRF protection with no cookies at all is when you generate the form you include a nonce. Then when the form is submitted you check whether it's a nonce you generated, which you do either by having stored it or generated it by hashing information you've stored. Implemented naively on a login form this would allow the attacker to fetch your page, extract the nonce, and include it in a cross-site request. But you could require it to be from the same IP. Alternatively I think you could fix this by having your login form set a custom header, which then browsers won't allow a cross-site POST for without a CORS preflight which you'd reject. But at this point I'm brainstorming and please don't take any of this very seriously!)

Post reply on HN