Hacker News Reader

Comment by 0xy | Hacker News Reader

Almost every new web API throws a bone to the ad companies who use it for fingerprinting.

The AudioContext API dishes out sensitive and specific audio device latency information that can be used to identify you to a high degree of accuracy, even if the web page in question never plays audio.

If you're ever bored one day, have a go reverse engineering some adware JS code to see what they're up to.

AudioContext for a static ad? Canvas fingerprinting? DRM fingerprinting? All of this has been enabled by both Google and Mozilla, who serve the same ad masters.

Mozilla is entirely dependent on ad money, as is Google. So they turn a blind eye to the security disasters being rolled out every month -- which Google's customers subsequently abuse.

This will be no different, it's yet another datapoint to identify you when perfectly good userspace solutions have existed forever.

View on HN

I don't think the fingerprinting capabilities are caused by malice on the behalf of Mozilla or Google.

Even if they made $0.00 from ad revenue, they would still be on the losing side of the battle against tracking. You can't have many features without exposing something about the client. As soon as you have things like multiple versions, optional features, plugins, and UI metrics, you've lost the battle already. Just your fonts alone can identify you to a reasonable accuracy.

How would you solve this problem? Have everyone run the exact same browser in a virtual machine sandbox, with all traffic running through a common VPN? No plugins, ever? No i18n? No preferences of any type? Upscale a fixed-sized image to your screen's physical resolution and just learn to live with the blur?

That's where you'd have to begin, but I guarantee the ad people would find a way around it. Key press cadence timing. Mouse movement patterns. Something. They'll find a way.

The first principle should be to separate "documents" from "webapps". An article on NYTimes should be classified as a document which comes with a sandbox with minimal data collection. Of course, as things stand, every site wants to become an app because that's how the incentives are set up. "Apps" - which can collect more data - should come with significant user friction: permissions dialog, standardized ToS, disclosures etc. Similarly, sites that offer "documents" (i.e. no tracking), should be incentivized in other ways (share button, micropayments etc).

There's a lot that can be done.

Every data point represents more bits of information used to identify users.

I would believe Mozilla and Google were good actors if they went back and cleaned up their security vulnerability "Web APIs" when they get used almost exclusively for fingerprinting.

They don't make any attempt to fix the vulnerabilities, they simply add more. Coincidentally, their ad clients directly benefit. Ain't that something.

This makes no sense for this example. It's an always enabled browser security API. It doesn't expose anything about the device, it doesn't even have state, they're just proposing a new Sanitizer API with methods to sanitize DOM objects. All you could detect is its presence, which provides far less info than the browser version alone.

There are other fingerprinting issues on the web, sure, but this is not one of them. The knee-jerk "all changes on the web are bad" responses are not helpful.

The change is redundant because there are userspace solutions today, and they will continue to be used for decades.

So what use does this serve? Another fingerprinting vector to narrow down browser versions, or worse -- a security hole.

When the "Web Audio API" was rolled out by the Chrome team not only was it fundamentally flawed, but it also contained memory leak CVEs.

Every time they add more trash to the browser nobody asks for (except their ad clients), they introduce more security problems.

So -- why are they adding more APIs when they could fix the old ones that are utterly broken and abused daily by the ad industry? $$$.

The browser version is always already accessible, and even in future plans to reduce user agent info (https://www.chromestatus.com/feature/5704553745874944) the major version number is never going to be hidden.

This API exposes zero new fingerprinting bits.

Meanwhile userspace solutions for the same solution are a) occasionally buggy b) not as widely used as they should be c) not as performant as they could be if implemented directly within the browser and d) not automatically updated as new browser features are released. Standardizing this will improve all of that.

It is valuable to standardize APIs and build them into the web for features like this where there's a clearly correct approach that's required by a large percentage of modern sites (anything with client side dynamic content). Having browser vendors implement this, embedded in the browser itself and supported by browser implementers directly, is a free security win for the web.

The intent is to shift the responsibility to the browser. Decades worth of userspace solution have failed us. The browser is pretty good at HTML parsing.

Because DOMPurify is not perfect. Due to some problem of HTML parsing, there were some ways to bypass it: https://research.securitum.com/mutation-xss-via-mathml-mutat...

Having a builtin XSS sanatizer means it could always use a single parser to prevent such bypass.

I haven’t delved, but this shouldn’t be a fingerprinting vector (except for the one bit of whether it’s implemented), as all browsers will be implementing the same thing, like with HTML parsing.

As for the other cases you describe, I’d say the problem isn’t so much that fingerprinting vectors exist as it is that ad providers allow arbitrary unsandboxed code execution, which is an obviously-terrible idea that never should have happened.

Yeah I would love to hear someone from Mozilla or Google respond to this.

There's literally nothing to respond to. There's no sensitive information exposed by this API...or any information, for that matter.

Reply on news.ycombinator.com