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?
We removed advertising cookies, here's what happened
121–130 of 191 posts
Re: We removed advertising cookies, here's what happened
#122Earlier 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?
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
#123Earlier 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?
Re: We removed advertising cookies, here's what happened
#124> 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.
Re: We removed advertising cookies, here's what happened
#125Funny 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.
Re: We removed advertising cookies, here's what happened
#126Earlier 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.
Re: We removed advertising cookies, here's what happened
#127Earlier 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?
Re: We removed advertising cookies, here's what happened
#128While 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.
Re: We removed advertising cookies, here's what happened
#129Ooh, 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
#130Earlier 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?
(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!)