Show HN: Are you trackable? An irrevocable persistent browser cookie | Hacker News Reader

Show HN: Are you trackable? An irrevocable persistent browser cookie

ubercookie.robinlinus.com

35 pointsCapira18 comments

This is a fundamental problem with running arbitrary untrusted code on your machine. Things like your display size and desktop decorations suddenly become security-relevant.

Browsers need to start recognizing these as high-priority security vulnerabilities and make it a point to preempt them by design. Or they need to explicitly acknowledge that they cannot and start reducing their javascript attack surface to a simpler foundation more appropriate for interactive web pages.

Code running for a web page should have no idea of what size screen or aspect ratio it is displaying on - if a developer wants to draw pixel perfect graphics, they should be creating an app. Many better methods exist for distributing full-featured programs to run on one's machine - they generally involve auditing by a third party. Sandboxed execution is a nifty thing, but it's negligent to assert that it's infallible and eschew further security measures.

How should developers accomplish simple things like responsive design without knowing the screen size?

If a design is truly responsive, it should not require javascript for doing so. The browser itself should be deciding layout policy.

You do realise that responsive design is mainly done with CSS, right?

Yes. Upon reflection it's not that relevant to this discussion, but my point is that with just simple media queries, nefarious developers can use 1x1 tracking pixels (as background images, for example) to accomplish fingerprinting.

What exact method are you referring to with tracking pixels? I'm only aware of doing so based on the cache, which can be defeated by clearing the cache.

Loading pixels can be used to allow cross-site communication, but that's not really what's under discussion here (and FWIW doesn't run afoul of the security model I expect from a browser)

I recall reading about a scheme that puts a different 1x1 tracking pixel for every CSS pixel breakpoint, and then uses that as a piece of info in the fingerprint. I don't remember the details, I can't find it, and the tracker would still have to join on something (probably IP, which wouldn't work very well.)

The usage of "getClientRects" is not about measuring the display size. The idea is to render some text into an empty element and then measuring the elements dimensions. The dimensions vary slightly depending on your browser, installed fonts, your OS, your machine etc...

Display size is just a nice concrete example of something that seems quite harmless, but is not.

getClientRects is exactly the kind of thing that would be carelessly standardized by developers working for surveillance companies with little care for users' security. As I said, there is little reason for code supporting a web page to need that type of functionality. And if it "really" is needed, then the rendering specification needs to be based on a fully formalized algorithm (ala a networked game or Bitcoin) with every parameter quantified in bits. And yes, I realize how different from the current stack this would be.

Note that your fingerprint is equal among your Firefox and Tor Browser on the same machine.

Yeah, that's pretty disturbing. But I seem to get two different fingerprints. Refreshing the page 10 or so times, I usually get one, and then it switches to the other for another ~10 page reloads, and then back again.

FF49 on Ubuntu 16.04.

I got a different fingerprint on each reload (for about 5-10 reloads). I'm not running noscript, but do have a decent number of other privacy related addons.

Strange, for me (Chrome on Moto E) simply reloading the page causes the fingerprint to change.

Same for me, but, Chrome on OSX.

I get a different fingerprint on basically every page reload. Sometimes it repeats.

Interesting, Brave browser blocks this method.

Does it? For me fingerprinting works on different devices with Brave Browser...

I could beat it by using a different browser (e.g. chrome vs firefox) on my machine.

Across browsers it works only if both browsers are based on the same engine.

- Group1: Chrome, Chromium, Opera, ...

- Group2: Firefox, Tor Browser, ...

- Group3: on iOS every browser is based on Safari

- ...

Though with a backend you could track users switching among Chrome and Firefox by misusing WebRTC to leak the private IP ( https://www.perfect-privacy.com/webrtc-leaktest/ ). If the switching between browsers happens in a short period of time, the public + private IP is a pretty solid guess. If you observe and store this connection once you can always track the user switching among the two browsers.

Reply on news.ycombinator.com