Browser fingerprinting is a hack, and exploits clear loopholes in browser privacy models.

I wouldn't rely on it because it's committing to an ongoing arms race against the browsers. One that I expect them to win.

> I wouldn't rely on it because it's committing to an ongoing arms race against the browsers. One that I expect them to win.

Don't be so sure about this. The world's most popular browser is developed by the world's largest advertising company. I'm not saying Google is intentionally sabotaging Chrome, but I doubt they're putting significant resources into anti-ad technologies.

Well, in the end it's their competitors that are hurt most when they close loopholes without warning. All chrome needs to do is hamstring ad-blockers (which they just did) and add a fingerprint that only google can use (like tying your google account to the browser for no reason...)

> Browser fingerprinting is a hack, and exploits clear loopholes in browser privacy models.

> I wouldn't rely on it because it's committing to an ongoing arms race against the browsers.

It doesn't seem to me that browsers are trying to win at all. For example, one of the greatest discriminators - font list - has been known about since people were talking about browser fingerprinting.

The fix would be pretty easy too: in incognito mode (or when toggled by the user), only support 2 fonts: 1 serif and 1 san-serif that ship with the browser on all platforms.

I don't think any of the browsers want to do that.

There are a number of other longstanding fingerprinting issues that are similarly easy to fix.

Last I checked, Safari in fact restricts the fonts web pages can see/use to ones that ship by default with MacOS. So you can't fingerprint a Safari user via fonts any further than "Safari user".

So yes, browsers, at least some of them, are in fact trying to win here.

You'd need a standardized font rendering engine to defeat fingerprinting via canvas.

"Same canvas image looks the same on every browser" seems like a desirable state of affairs to me?

I think the problem is that canvas can be GPU-accelerated, and GPUs don't have an exact standard for how each pixel will look.

> You'd need a standardized font rendering engine to defeat fingerprinting via canvas.

That's fair.

But that really only gives the attacker the OS (and perhaps the GPU vendor?). Not ideal for sure, but not that many bits of info, especially if you are in the majority (windows / intel)

> One that I expect them to win.

Sure, the basic things like "which fonts do you have installed" are easy to make consistent, but there are thousands of other ways to fingerprint a browser, many of which would have serious performance impacts if fixed. For example, Macbook Air's can only run at full CPU speed for about a second before slowing down. Just make a 2 second javascript busy loop and watch for the slowdown. Are you going to slow all users down all the time just so these macbook users can't be identified?

Doesn't Google have to leave a Chrome loophole for themselves that is less conspicuous than a specific exception for DoubleClick/Google?

The article (and Google Chrome's change) is mostly about auth cookies, not tracking ones.

What is the technical difference between an “auth” cookie and a “tracking” cookie?

None, its a usecase difference not a technical one. but samesite is designed to tackle csrf (a problem with using cookies for auth). It wont prevent user tracking.

Sure it can. Samesite cookies will prevent e.g. Google Analytics from identifying me between domains, since any samesite cookies they set for the domain from which they’re serving their script/pixel won’t be sent. (Presumably tracking prevention will eventually start to block cookies with samesite disabled).

Browsers have offered a "block third party cookies" setting for decades.

I'm honestly surprised none of the major browsers block third party cookies by default, it's much simpler XSRF protection than this as it doesn't rely on site developers updating and setting the new flag right.

Of course, two sites that seriously want to collaborate on user tracking (or login) can always forward the user’s whole browser window there and back, with URL parameters to synchronise first party cookies.

> as it doesn't rely on site developers updating and setting the new flag right.

Chrome is enabling this flag by default. Websites can opt out, but if they do nothing they are opted in.

Blocking third party cookies doesnt really stop csrf attacks. At most it makes the attack a bit more noticeable as it prevents some of the quieter methods of pulling off the attack. Since as far as i understand, if you submit a cross-domain POST form, that's still a first party cookie

> (Presumably tracking prevention will eventually start to block cookies with samesite disabled).

This means the privacy advantage doesn't really come now, it instead comes at some hypothetical point in the future.

It makes it harder though.

Does it?

Websites can just opt out if they dont like samesite cookies. Even if they couldnt, its trivial for the website operator to work around if they want (and website operators are almost always in on user tracking)

For authentication, there is also the HTTP basic and digest authentication. However, I do not know that any web browser provides functions for the user to manage this authentication. (It would also make it easier for the user to configure cross-site authentication, too.)

Not sure how this is relavent, but IE had document.execCommand('ClearAuthenticationCache'); for http or TLS auth. Dont think other browsers have anything

Yes, I heard of that, although that is done by the document script and what I was asking is a command for the user to enter instead.

Http basic/digest auth doesnt last beyond the session, so just close the browser window?

Probably putting a different username in the url would work too (in non ie)