Live data from Hacker News

Web fingerprinting is worse than I thought

bitestring.com

291–300 of 524 posts

Re: Web fingerprinting is worse than I thought

#291
post #186

Earlier quoted context omitted.

I think Stallman just shot himself in the foot by even revealing that much. Unless a lot of people do the same thing, it's very easy to conclude that it was Richard Stallman who sent that WGET request, granted a few variables. The difficult part is perhaps tracking it back to its actual source, but I don't think Stallman is that hard to find. All this is of course extremely chilling. I'm sure a profile could be built…

I actually did exactly that a while ago. Where I worked, we didn't have internet access but we had email access, so as a workaround, I made an email server on my home machine that fetched web pages for me. A coworker took it even further and made a proxy server that automated the process so you could actually browse the web, although very slowly. Just to say that Stallman is not the only one with this idea. It was in…

In Germany there is a "WhatsApp" SIM [1], where you have to pay for normal internet use, but WhatsApp texts are free of charge.

With a technique which you described, you could probably abuse a phone with this SIM as a "free" hot spot with infinite data.

[1] https://www.whatsappsim.de/

Re: Web fingerprinting is worse than I thought

#292

I remember once in college I'd shared my phone's hotspot to connect a TV to the internet after it had abruptly stopped working. And all of a sudden the ads being shown (on YouTube) switched from the local language to mine, both of which are completely different.

The combination of IP, language preference and available fonts is very potent and not obvious to Americans.

Re: Web fingerprinting is worse than I thought

#293
I dont think this is a proper way to test it.

It matters more how unique your fingerprint is than how consistent or reproducible it is. Just testing if you get the same fingerprint back on your second visit doesn't tell you much if you don't know how many people "share" your fingerprint.

As a silly example, if you gave all users the same fingerprint, it would be very consistent but also useless as a tracking method.

Re: Web fingerprinting is worse than I thought

#294

Ha! I followed the instructions and went to fingerprint.com and it all 'crashed' because I had JavaScript turned off—that's my normal default setting. I have five different browsers on my smartphone and three on the PC all sans JS and none of them are Chrome. Also, normal operation is to automatically delete all cookies at session's end. My smartphone and PCs are de-googleized and firewalled and I never see ads in my…

Before you get all jubilant, note that they have fingerprinting techniques which don't use JS[0]. It was able to identity me. Contrary to popular opinion, disabling JS doesn't protect you from fingerprinting.

They describe their approach[1]. They use HTTP headers and conditional request triggered by CSS conditional media queries to gather data. Something like @media(...) {background: url(/tracking/$clientid)}. But in principle, they could also try and fingerprint the TCP/IP stack or the TLS implementation. I'm not sure it would get them more data than OS+Browser, though.

[0] https://noscriptfingerprint.com/

[1] https://fingerprint.com/blog/disabling-javascript-wont-stop-...

Re: Web fingerprinting is worse than I thought

#296
post #214

Earlier quoted context omitted.

Not if you disable JS, cause the website then can't see any of these customizations.

Except that disabling JavaScript is an anomaly all on its own. The dozens of users running without JavaScript might not be individually fingerprint able but it's still a small enough cohort that I don't know how much I'd lean on that. Figure in the user agent string and it's probably unique enough a subgroup to sell ads to.

Also that cuts down the group so much, i imagine other things that are usually too coarse grained to be useful suddenly become much more useful. E.g. geoip location or accept-language headers.

Re: Web fingerprinting is worse than I thought

#297
post #4

It's important to know that the mentioned "resistFingerprinting" breaks a lot of the web. Examples include the back button, uploading photos on some websites uploads random data instead of the photo, etc.

I've been using it for years. I've barely noticed.

Re: Web fingerprinting is worse than I thought

#298
post #200

Earlier quoted context omitted.

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…

> This is confusing whether it can be blocked and whether it would be effective.

It shouldn't be confusing because its really fairly simple.

The gist is this... so long as determinism as a systems property holds true in a system, you can leak information by the absence of something when compared to another expected thing. This is how inference works in many respects, you have properties and you can deduce or infer from whether those are present additional information that is not necessarily given.

Most gifted problem solvers probably couldn't tell you that is what they are doing because its unconscious often a result of years of observation.

Computers fundamentally require certain system properties such as determinism to do work in the first place, and you can inject non-determinism into those processes in ways that won't break underlying subsystems as long as its within an expected range and that can make it indeterminate. An indeterminate fingerprint is useless.

In the case of outright blocking the code from running, you leak information that you are blocking it by preventing it from running since they expect a range of values back and a null (the response when nothing gets sent back) is itself a value (or state if you want to be technical).

The site then only has to test for this semi-unique case (i.e a null represents a single group of people who are blocking it) and then prevent the site from responding to you. They are the gatekeepers because they control their infrastructure.

Incidentally this is how almost all the Are you human tests work. It collects an intrusive fingerprint, and if its within a range that corresponds to a known user spectrum of values then it allows you to continue to the site.

This is a rough boiled down explanation, it can get quite a bit more abstract and technical when talking about whether determinism is present (i.e. how do you test for it).

Ultimately, if you can understand determinism, you fundamentally understand the limits of computation and how computers work at a barebones level. It also gives you the ability to find whether certain types of problems are impossible (and thus you don't waste your time on them, or unproductive avenues).

Re: Web fingerprinting is worse than I thought

#299

Earlier quoted context omitted.

Not if you disable JS, cause the website then can't see any of these customizations.

Not if you disable JS, cause the website then can't see any of these customizations. That's adorable. I guess you're not old enough to remember when we used to track people with things like invisible pixels. Or todays equivalent: testing CSS parameters. Neither require JavaScript, and there are a hundred other non-JavaScript methods.

Hah! I used to embed invisible pixels for our marketing department decades ago.

Re: Web fingerprinting is worse than I thought

#300
post #278

Earlier quoted context omitted.

> is slow as usual: It's funny because for anything Chrome deems beneficial to Google they are anything but slow, including shipping APIs that no other browser agreed on.

Having been someone at Google working on new browser APIs, that's slow too. But maybe it doesn't look as slow from the outside?

> But maybe it doesn't look as slow from the outside?

Google ships 400 new APIs per year. It readily ships API within a month after it spits out a half-prepared spec and asks other browsers for input.

Even benign changes like CSS headline balancing was sent to TAG three weeks ago, and will ship a month from now.

From the outside this is neck-breaking speed with utter disregard for anything. But when user privacy is concerned? Nah, must spend sweet time to do anything.

Post reply on HN