Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web fingerprinting is worse than I thought

bitestring.com

Post reply on HN
Print view View original

281–290 of 524 posts

Re: Web fingerprinting is worse than I thought

#281

Post by withinboredom »

chrismorgan wrote: post #262
withinboredom wrote: post #226

Earlier quoted context omitted.

It’s fun to put Easter eggs for people like you. https://once.getswytch.com

I have no idea what you’re talking about. That URL only tries to load one piece of JavaScript, htmx, and all it does is unbreak the mobile navigation. (Aside: this mobile navigation is, incidentally, the worst implementation I have ever encountered: instead of twiddling some classes or such, which would happen instantly, it makes an HTTP request that responds with the new navbar. For me, this means at least half a se…

Haha. Yeah, it is pretty terrible and I made it.

It’s mostly a tech demo, so the things it does are intentionally weird/strange.

Re: Web fingerprinting is worse than I thought

#282

Post by cobbaut »

How many websites do you need to visit before being unique in the world?

Say I follow AS Monaco football, then look for Lego Castle figurines and finally visit a forum on Alaskan Malamute dogs. The combination of these three websites is pretty close to unique in the world imho.

Surely most people can be uniquely identified after visiting a couple more, unless we change browser and ip-address and GPU and set resistFingerprinting=true and ... and clear cookies after every website we visit.

Re: Web fingerprinting is worse than I thought

#283

Post by Vinnl »

illiarian wrote: post #20

Note also: As the number of APIs increases, so does the fingerprinting. E.g. MIDI device enumeration (no prompt in Chrome, prompt in FF, not implemented in Safari): https://twitter.com/denschub/status/1582730985778556931?s=20

Didn't Firefox also require the user to install an extension before enabling MIDI support?

Edit: I think MDN confirms this, with the asterisk next to Firefox: https://developer.mozilla.org/en-US/docs/Web/API/Web_MIDI_AP...

Edit 2: oh, the tweet shows two prompts, one of them to install the extension, so I suppose that is actually the prompt you're referring to.

Re: Web fingerprinting is worse than I thought

#284

Post by nordsieck »

factormeta wrote: post #197
illiarian wrote: post #20

Note also: As the number of APIs increases, so does the fingerprinting. E.g. MIDI device enumeration (no prompt in Chrome, prompt in FF, not implemented in Safari): https://twitter.com/denschub/status/1582730985778556931?s=20

We need 2 classes of web. One for document based that doesn't require JS to run (secure). Insecure, all the SPA and anything that require JS to see the full content.

> We need 2 classes of web. One for document based that doesn't require JS to run (secure).

I've wondered for a long time if a sort of posh gopher based on markdown with extensions would be able to make a comeback. Especially if it allowed for CSS.

Re: Web fingerprinting is worse than I thought

#285

Post by nordsieck »

giancarlostoro wrote: post #228
grishka wrote: post #217

Earlier quoted context omitted.

Back in the day, we had a nice boundary between the document and the "app". Then for some reason we decided that Flash doesn't need to be a thing any more and erased that boundary by building the app functionality into browsers themselves, making the app and the document inseparable. We should have invested that effort into building an open source Flash player instead. One of the nicest things about Flash was that yo…

Java Applets were worse though, every time I got a virus of any sort from merely browsing generic sites, it always happened due to Java in the browser. I finally stopped installing Java for the web and my security problems went away. Flash had some security nightmares all the time too if I remember correctly but I dont think it ever screwed me over like Java did. I think unless we lock down new APIs that aide in fing…

> I think unless we lock down new APIs that aide in fingerprinting to only be accessible to WebAssembly and let people block or enable WASM theres not too much else we can do.

IMO, it should be enough if incognito mode presents an identical fingerprint on everyone's browser.

Re: Web fingerprinting is worse than I thought

#286

Post by danbruc »

than3 wrote: post #200
danbruc wrote: post #177

Can we fingerprint fingerprinting code and block it? At first glance it seems like code accessing all kinds of unrelated high entropy APIs should be something detectable. But then static analysis might be too hard in face of obfuscation so it would have to be done using dynamic analysis which kind of means you let the fingerprinting happen but are now at least aware of it. So how do you prevent the fingerprint from b…

The short answer is no you can't block it because that identifies to the site owner that you are blocking it (as a negative match). You'd have to mask every informational API with a suitable corrupted alternative that is plausible.

This is confusing whether it can be blocked and whether it would be effective. Every time you do something unique, you of course become identifiable. But the idea is of course that you are not the only one blocking these scripts which will only make the entire group identifiable. You could for example try to block those scripts with a widely used ad blocker which would make you not stand out any more than any user of that specific ad blocker. It would probably not be too effective as URIs and file hashes or whatever ad blockers use are relatively easy to change, but in principle you do not have to become uniquely identifiable by blocking fingerprinting scripts if enough people are doing so.

Re: Web fingerprinting is worse than I thought

#288

Post by giancarlostoro »

dgroshev wrote: post #240
giancarlostoro wrote: post #236

Earlier quoted context omitted.

They should enforce that Do Not Track is honored. Its the easiest way, and websites dont need silly cookie consent dialogs if set.

DNT is ~useless because it's opt-out, whereas "auxiliary", non-essential tracking is opt-in under GDPR. Websites don't need cookie consent dialogs if they only use cookies to do things that don't need to be consented to, like providing the service they are offering. Look at Apple's website, they don't have any.

My argument is current laws did nothing to give teeth to DNT. I'm not worried about what the technological defaults are, but I would argue that without DNT being legitimized, it was dead on arrival. We have had it in browsers for ages, and we've dropped the ball on enforcing it for ages.

My other argument is, if you detect DNT, the cookie consent dialog shouldn't be shown at all.

Re: Web fingerprinting is worse than I thought

#289

Post by 323 »

izacus wrote: post #116
than3 wrote: post #113

Earlier quoted context omitted.

The short answer which should be obvious... regulatory doesn't work, legal doesn't currently work. The burden of proof is on the claimant, and with proper information control you can't ever meet that burden of proof. It becomes an ant versus a gorilla instead of David vs. Goliath. Tell me, how do you differentiate a simple random alpha-numeric string from another random string that may have been generated as a finger…

Can you provide any proof that "regulatory doesn't work"? Might be my European outlook, but consumer law has been stupidly effective at curbing abuses from companies here and was much more effective than playing the technology race USA is trying to fight. There's always a next side-step, the next abuse a company can invent - and you keep trying to push the responsibility of avoiding it to users (by adding more and mo…

> Might be my European outlook

How did the EU cookie laws and GDPR solved this problem? It's as widespread as before, except that now you are annoyed by prompts too.

Re: Web fingerprinting is worse than I thought

#290

Post by tomxor »

I think Firefox might actually enable this by default for third party sites, but not 100% what this about:config one does:

  privacy.trackingprotection.fingerprinting.enabled
This would make sense since messing with values for the root frame could cause unwanted side effects, but you're not likely to care if some iframe gets your screen resolution or CPU count wrong.
Post reply on HN