Hacker News Reader

Comment by tptacek | Hacker News Reader

Be disappointed all you want, but they're not really "addressing" fingerprinting. It is exceptionally difficult --- computer-science Hard difficult --- to prevent fingerprinting; all you can really do is break popular libraries people use today. It's an arms race, and a much harder arms race than exploit-hardened runtimes are.

View on HN

Is it? As I understand it, fingerprinting relies on properties and headers, both of which could be altered (eg adding headers for software that doesn't exist, and only sometimes, change the order, etc). You probably can't make them do it so that websites can't see the browser type, and you might not want to.

No, fingerprinting is much deeper than that. Look at how DNS cookies work, for instance; you can create a serviceable fingerprint of a device just from how resolvers randomize multiple A records for the same label.

It's actually pretty easy overall... just don't use JavaScript and don't send user-agent string that shows browser/OS information.

You will be part of the rare minority that uses that configuration which by itself is a fingerprint.

The point probably was to make that configuration default

That configuration will not be the default. You might just as productively argue that the best way to defeat fingerprinting would be to default to Gopher.

You can do a lot of things with just HTML and CSS, more than what Gopher allows.

And for what you can't, a banner asking for permission to run Javascript, like we have/had for Java/Flash/ActiveX

Can a user meaningfully determine the correct answer to that question?

The experience is “I clicked no and nothing worked” vs “I clicked yes and the site worked”.

I get that you don’t like it, but the reality is that the web is a platform that includes JS as a core technology. The reason for limiting java and activex was because they had catastrophically terrible security properties more or less by design.

Even flash had problems, but was sensible enough to correct many deficiencies and defer to the browser for interaction with anything outside of its view. Which is why you weren't asked about running flash on every website you went to. JS and the various web/html/dom APIs all have much much stricter constraints than anything flash had - they are designed to be safe in spite of all content being untrusted.

More over dialogs like that are largely recognized among browser developers as being a form of blame shifting - a regular user has no reasonable way to determine whether or not saying “yes” is safe. The purpose of asking them, is so that if something does go wrong you can say “they shouldn’t have clicked yes”.

> Can a user meaningfully determine the correct answer to that question?

> The experience is “I clicked no and nothing worked” vs “I clicked yes and the site worked”.

I agree; but the extra click may be an insentive for web developpers to try not to use JS.

> Which is why you weren't asked about running flash on every website you went to.

Firefox did ask about running Flash, because "attackers can also use the security flaws in Flash": https://support.mozilla.org/en-US/kb/set-adobe-flash-click-p...

> they are designed to be safe in spite of all content being untrusted

But they have flaws, like Flash.

Just as long as we're all clear that this is not a real debate, and a serious programming language connected to the DOM is not going anywhere; you are stuck with that design.

> just HTML and CSS,

yes, @media queries for example that trivially let the site fingerprint you again.

That would be pretty nice in many ways.

No web browser is going to disable JavaScript by default and Google is one of the worst offenders when it comes to User-Agent sniffing (you can experiment with this on your own by setting a custom User-Agent and attempting to use various Google websites).

And even then that's far from enough to stop fingerprinting. Ordering of http headers has been used to fingerprint browsers. The <picture> element can be used to leak browser screen size. CSS can leak information in @media and @support queries by requesting specific images. It's even possible to create "DNS cookies".

More: http/2 passive fingerprinting: https://www.akamai.com/us/en/multimedia/documents/white-pape... Fingerprinting servers based on header order: http://www.net-square.com/httprint_paper.html#httpheader List of CSS Media queries, including vendor specific ones: https://browserleaks.com/css DNS Cookies Demonstration: http://dnscookie.com/

DNS cookies, by the way, are awesome.

User-agent strings should have been abolished long ago. It may not do much against sniffing, but it would spare us monstrosities like "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134"

I was surprised to see how many popular websites rely on things like user agent or referer header to deliver functionality. As soon as you start tinkering with them, they stop working, or say you use an older browser, etc.

Back in the day, safari 2.0.4 encountered a large amount of site breakage because sites were using useragent.indexof(“4”)!=-1 as the test for “are you Netscape 4”, and if you were then they’d use netscape’s layer apis (netscape’s alternative to css). Any changes to the user agent are very scary - that’s kind of how they ended being as terrible as they are.

Yet still sites continue to use the user agent to gate access. The same sites also like to complain about how bizarre UA strings are.

Unfortunately websites break if you stop sending it or dramatically change it. Most browsers can't afford the risk of a dramatic change here.

Breaking things is (sometimes) the only way to progress.

Browser and OS information is not the biggest info leak, it really isn’t.

Compared to cookies in the request.

Time stamps in the request and the tls header.

IP address, etc etc

People vastly overestimate the value of those data in the UA

There's a lot of fingerprintable info in HTTP headers other than User-Agent and in parts of the User-Agent string other than the browser/OS versions.

Reply on news.ycombinator.com