Live data from Hacker News

The privacy nightmare of browser fingerprinting

kevinboone.me

71–80 of 456 posts

Re: The privacy nightmare of browser fingerprinting

#71
post #58

Earlier quoted context omitted.

>An answer usually contains more information than just that one bit. Isn't the point to ask yes or no questions?

Yes, but you can make assumptions based on what you know about humans generally. Like their example that if you ask if you have long hair. If you answer yes the likelihood is you are probably female. You can think of all sorts of questions and answers like this, and when you combine with the assumptions and answers from previous answers you can make even more assumptions. They won't always be correct, but you don't h…

https://medium.com/@colin.fraser/target-didnt-figure-out-a-t...

https://www.predictiveanalyticsworld.com/machinelearningtime...

Re: The privacy nightmare of browser fingerprinting

#72
post #40

It reminds me of a game we played with students of data classification algorithms like ID3: How many yes/no questions do we need to uniquely identify everyone in this room? With like 12 students, that's 4 bits, and it often ends up with 2-3 questions. It starts off with the obvious ones - man/woman/diverse, but then a realization comes in: An answer usually contains more information than just that one bit. If you hav…

[flagged]

Re: The privacy nightmare of browser fingerprinting

#74
post #55

Earlier quoted context omitted.

>An answer usually contains more information than just that one bit. Isn't the point to ask yes or no questions?

Yes, but multiple yes or no questions in combination can easily yield more information than they should in a real dataset. That's the real educational point.

You seem to be confused about the difference between "less" and "more". In general a yes-no question gives less than 1 bit of information if yes and no are not equally likely. There is no way it can be expected to give more.

Re: The privacy nightmare of browser fingerprinting

#75
post #63
post #52

Firefox w/ the Arkenfox user.js is probably as good as it gets in terms of privacy. By default, this config burns cookies on exit, standardizes the time zone to UTC, spoofs the canvas fingerprint, and does other helpful things. Basically, it makes Firefox expose the same information as the Tor browser. In addition, I block most known advertizing/tracking domains at the DNS level (I run my own server, and use Hagezi's…

Orion Browser (Kagi Product) prevents fingerprinters from running by default. https://help.kagi.com/orion/privacy-and-security/preventing-...

How do they reliably detect fingerprinting? Did they solve the Halting Problem? Sounds fishy.

Re: The privacy nightmare of browser fingerprinting

#76
post #40

It reminds me of a game we played with students of data classification algorithms like ID3: How many yes/no questions do we need to uniquely identify everyone in this room? With like 12 students, that's 4 bits, and it often ends up with 2-3 questions. It starts off with the obvious ones - man/woman/diverse, but then a realization comes in: An answer usually contains more information than just that one bit. If you hav…

[flagged]

I think a plain reading of the post you’re replying to would be “obvious as a way of segmenting people”.

Re: The privacy nightmare of browser fingerprinting

#77
post #40

It reminds me of a game we played with students of data classification algorithms like ID3: How many yes/no questions do we need to uniquely identify everyone in this room? With like 12 students, that's 4 bits, and it often ends up with 2-3 questions. It starts off with the obvious ones - man/woman/diverse, but then a realization comes in: An answer usually contains more information than just that one bit. If you hav…

[flagged]

It's obvious in the sense that most people will start out with that as their first question.

Re: The privacy nightmare of browser fingerprinting

#78
post #20

Thanks for the browser recommendations. I switched to the Mullvad browser. The other recommendation, LibreWolf, provides the following warning on install which scared me away: "Warning: librewolf has been deprecated because it does not pass the macOS Gatekeeper check! It will be disabled on 2026-09-01."

tldr -- it's fine. MacOS Gatekeeper will create warnings about products that are not signed via the apple developer program, which is $99/year librewolf is an open source product, that is very strictly a "community" libre / FOSS project. naturally, having an individual take up notarization assumedly, you are using brew -- brew recently decided to stop supporting / deprecate all casks that does not pass gatekeeper che…

Why would I trust any software that doesn’t pass the gatekeeper test? Even if it claims to be “open source” with links to some code repo there is no guarantee the binary blob you are running was built using only that code and nothing else.

Sure even with the gatekeeper test you can’t be sure it’s built against only the claimed code but it does guarantee:

1) the binary hasn’t been modified since it was signed 2) the binary was signed by somebody in possession of the private key 3) there is some measure of identification via Apple on who or what signed the binary 4) somebody was willing to fork over $99 to sign the binary

It’s not perfect security by any means but it is something. Otherwise the binary you are running might as well have come from some sketchy email attachment. And fuck that. Why would I want that on my machine?

I get that the $99 might be a hurdle for “non-organized open source” (ie most open source… doesn’t have a non-profit entity to take up the expense and credential management, etc…)… and there are probably ways apple could make it easier for such “collectives”… but ultimately I’d argue that signed binaries are good for everybody. While imperfect, they provide some form of traceability and accountability.

obviously it’s not a 100% guarantee of being fuckery-free. The private key might have been compromised, the appleid might have been hijacked and the developer program might have been enrolled with stolen credit cards… but it’s still a hurdle to filter out a large swath of low effort nonsense.

Re: The privacy nightmare of browser fingerprinting

#79
post #40

It reminds me of a game we played with students of data classification algorithms like ID3: How many yes/no questions do we need to uniquely identify everyone in this room? With like 12 students, that's 4 bits, and it often ends up with 2-3 questions. It starts off with the obvious ones - man/woman/diverse, but then a realization comes in: An answer usually contains more information than just that one bit. If you hav…

> An answer usually contains more information than just that one bit. That means there is less information in the question "do they have long hair?", not more. Asking "long hair?" and then "woman?" is probably, in most groups, roughly the same as just the first or second question alone. So the second question added much less than one bit of information because the answer is probably "yes". "Long hair" and then "metal…

Ah, I flipped it in my head. That happens after 10 years.

In this case, it was often an interesting exercise in bias as well. "Woman?" would usually single out 1-2 persons out of the 15, so it was a terrible question. It was CompSci after all. "Long hair?", lumping women and metal heads into one group would often split it into half and half. That was much better, and then spurred creative thoughts like travel distance, or bus stations.

Re: The privacy nightmare of browser fingerprinting

#80

The core of the problem is that we've made this behavior of "run javascript that pulls more javascript and then run that too" the default. Stallman was right, as always.

Does he have a strong stance of JS in the browser? In any case, I don't think many people would agree that the dubious extra privacy you gain from blocking that is really worth breaking half the web. Fingerprinting is not too hard even without JS.

I would re-frame "is it really worth breaking half the web" as those sites are not compliant to begin with. Nothing in the web standards stack mandates javascript, its an optional feature! Web developers of yore understood that a fundamental property of a properly written web site was to degrade gracefully if javascript wasn't available, but the groupthink of the past decade has chosen weaponized incompetence over doing their jobs and in the process has not only thrown a load of noncompliant insecure garbage out there, but broken a load of accessibility standards, and other things in the process.
Post reply on HN