Hacker News Reader

Comment by n144q | Hacker News Reader

About time. It has never achieved anything meaningful for protecting your privacy, if not helping the opposite by providing yet another signal to help uniquely identify a user and improve tracking.

Although, anti-tracking in general is basically fighting a losing battle. Go to https://amiunique.org/ and you'll see why. I use Firefox with all possible protection mechanics -- "strict" tracking protection mode, uBlock origin, yet I cannot escape first-party tracking.

One striking example: These days browsers may expose how many cores your device's CPU has to websites. That alone could eliminate 80%-90% of users. Combined with user agent, IP, language etc you are pretty much uniquely identified.

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/h...

View on HN

What I'd love to see is a default JavaScript environment (ideally across all browsers, but at least in FF) that is sufficiently basic as to be identical for all users with an icon appearing in the address bar when a site wishes to use advanced features that might enable tracking, so that these can be enabled on a case-by-case basis.

Low script rather than no script, if you will.

> Although, anti-tracking in general is basically fighting a losing battle. Go to https://amiunique.org/ and you'll see why.

The goal shouldn't be to appear non-unique. There are too many little things that will out you. Even if you somehow account for every single one of them today your next browser update could enable more and you can't trust that amiunique.org is looking at every identifying data point either. It's an arms race you're going to lose.

What you want is to be differently unique for each website you visit. Even better if you have JS disabled by default and sites can't collect 90% of the data points your browser exposes at all. The best protection you could get would be to change up IP addresses via VPN and randomize your user-agent and other tells.

> Even better if you have JS disabled by default and sites can't collect 90% of the data points your browser exposes at all.

There's two gigantic issues with that:

1. Most websites won't work

2. Most people like websites to work, and so they have JS turned on. If you don't, you'll stick out like a sore thumb.

You'd be surprised at how many websites work just fine with JS disabled, at least in terms of providing the content you want. Menus/navigation might not work, and I wouldn't even attempt online shopping without JS, but enough websites still manage to display basic text and images without JS that it's a surprising annoyance when they fail to.

Sticking out like a sore thumb isn't a problem as long as you look like a different person's sore thumb to the next website.

> Sticking out like a sore thumb isn't a problem as long as you look like a different person's thumb to the next website.

Being consistently unique is okay as long as the tracking party is simply generating programmatic hashes. But if you're always unique, but in a specific way, it doesn't matter. The total amount of entropy matters.

> I wouldn't even attempt online shopping without JS,

So, a nonstarter for basically all normal internet users.

All of Amazon.com works with their adsystem domain disabled by uMatrix. Only about half of their almost 100 js files are needed to browse products.

I get by using no-script universally and it's rare that I need to allow JS for more than 2-3 domains to get a site fully functional. Usually it's limited to site, and site-cdn.

It's also nice that with no-script and uBlock origin that it only takes a couple clicks to whitelist something and even then you only need to do it once and it can remember it for the next time. You can also use add-ons like LocalCDN so that a lot of commonly used JS can be used without a remote connection.

There are two orthogonal issues. You're mainly talking about the need of making the tracking (for people who don't want to be tracked) impractical; what also needs to be done is to make it illegal.

I feel like DNT was a "rushed" (i.e. with no legal backing) attempt to achieve the latter.

> These days browsers may expose how many cores your device's CPU has to websites.

This information could be determined prior to the introduction of navigator.hardwareConcurrency.

I published a timing attack polyfill that derives this information and initially proposed the navigator.hardwareConcurrency API as a replacement for this timing attack polyfill.

In addition to the fundamental utility of this API, browser vendors also saw implementing this as a way to save battery life by making it no longer necessary for websites to benchmark user devices to determine this value.

Reply on news.ycombinator.com