Remix.run Logo
joquarky 5 days ago

Seems like it should be a browser setting that controls a request header.

benjiweber 5 days ago | parent | next [-]

Something like https://en.wikipedia.org/wiki/Do_Not_Track ? Which failed in part because Microsoft turned it on by default which even further disincentivised publishers from respecting it.

beeflet 5 days ago | parent | next [-]

The fix here would be to legally force them to comply with Do Not Track instead of forcing them to post compliant banners

Cthulhu_ 5 days ago | parent [-]

They are not forced to use banners, they are forced to get explicit opt-in permission before tracking users, which can be done in non-obtrusive ways.

beeflet 5 days ago | parent [-]

Okay, so regard the Do_Not_Track header as explicit opt-out permission

charcircuit 4 days ago | parent | next [-]

No browser implements it as an explicit one where you have to explicitly specify which businesses you do not which to track you.

const_cast 4 days ago | parent | prev [-]

They would never do this willingly, because they don't want you to automatically opt out of tracking.

The annoyance of the cookie banners is the entire draw for companies. Its not a downside. They're user-hostile. You are their enemy. Their goal is to wear you down and trick you into opting-in, so they can both track with impunity and follow the law.

beeflet 4 days ago | parent [-]

>They would never do this willingly

I know, that is why I am saying you would force them to respect Do_Not_Track by law.

catlifeonmars 5 days ago | parent | prev [-]

No your browser can just… choose not to send cookies. The website publisher has no say in that.

9rx 5 days ago | parent [-]

Cookies are the easiest way to keep track of a user, but if browsers regularly stop sending cookies then website operators will just find another method to fingerprint users and then we're back to square one with the law still requiring publishers to receive opt-in approval, but with no requirements on how.

quectophoton 5 days ago | parent [-]

> then website operators will just find another method to fingerprint users

Example: The identifier you get when you pass anti-bot challenges (Cloudflare, Anubis, etc).

Thorrez 4 days ago | parent [-]

That's not a cookie?

quectophoton 4 days ago | parent [-]

It probably is, currently. But even if cookies are not used, the identifier for this type of functionality would still need to be stored somewhere and passed to the server in some way to avoid showing another CAPTCHA to the user.

Whatever mechanism they choose to uniquely identify you, they will insist it's necessary for another purpose and they totally are not piggybacking on it for tracking (e.g. for the CAPTCHA example, they would insist it's absolutely necessary to protect themselves from DDoS).

As another example, they can always respond with HTML where all links themselves are an opaque hash that internally contain "route + your id" when decrypted. Then emphasizing that all links are always different even for same routes to "show they are randomly generated", and saying that they do this because... idk, detecting scraping or something random but plausible-sounding. Or whatever sneaky variation of the `?PHPSESSID=` query param from old times.

(Yeah I know the last example doesn't a lot make sense, I didn't think too hard about it, the point is that they will probably find a way somehow.)

popcorncowboy 5 days ago | parent | prev [-]

There's a reason the largest advertising company in the world hasn't sanctioned this move.