
Against privacy defeatism: why browsers can still stop fingerprinting - randomwalker
https://freedom-to-tinker.com/2018/06/29/against-privacy-defeatism-why-browsers-can-still-stop-fingerprinting/
======
fpgaminer
Over the years I've noticed this, privacy defeatism, amongst other excuses
used to push back against security and privacy enhancements.

Another is security chicken and egg. "Because A isn't secure, there's no point
in securing B. And because B isn't secure, there's no point in securing A."
I've seen arguments along those lines used against improving the security of,
for example, DNS and SNI. Or just DNS in general. "There's no point in
securing DNS because your ISP can see what IP addresses you connect to."

The all-or-nothing argument has been used to argue against HTTPS. "State
actors like China can circumvent HTTPS, since they control trusted CAs! So why
use HTTPS at all?"

Then there's the arguments against security because "it makes development
harder!" People have argued against mandatory HTTPS saying that it makes
developing websites harder.

The list goes on.

Luckily it seems that pro-security and pro-privacy succeed in the end, for the
most part. But those that use these pathological arguments have certainly
delayed things more than they should have been.

~~~
neverfone
I'm not a privacy defeatist, but I am a fingerprinting defeatist. Here's why:
I don't think it's realistic for caching and anti-fingerprinting to co-exist,
and given those two options users will always pick the former because the
latter would be perceived as slow. The classic example is:

<script src=foobar.js>

Where foobar.js just returns something like "var id=0x1234567", the user who
doesn't want to be fingerprinted cannot cache this script because it could be
uniquely generated.

~~~
DennisP
Why not cache it for the user, but go ahead and retrieve it in the background?

~~~
neverfone
I don't understand the question, it's either cached or not.

If it's not cached, then it has to be fetched synchronously for anything
depending on its value to work - so it's slow.

If it is cached, then the cached value is known.

------
hartator
Chrome has no interest in doing that.

Google uses browser fingerprinting for their ads, and to make sure a real user
is requesting their services.

I would trust Safari a lot more to implement something like this.

~~~
AngryData
That is a big reason I stopped using chrome. I block all the cookies and
scripts I can but they were still collecting data from other shit and serving
me obvious directed ads.

~~~
gsnedders
I don't know about Google, but AIUI FB does targeted advertising based on
source IPs if there's a very small number of users from a given IP.

As long as they know the source IP, they can implement some form of tracking.

------
mikedilger
There are two ways to defeat fingerprinting: 1) Be common: have your data
match what others are sending 2) Be unique on every page request: scramble
your data

Browsers in category (2) are not trackable, even though they appear to be
fingerprintable. Each page request is a different fingerprint.

What is unclear from the article is whether the studies mentioned (EFF, INRIA)
considered that and tested that. Does anyone know? Because privacy does not
require non-unique fingerprints, it just requires untrackability.

~~~
incompatible
Are there any readily-available browser plugins (or whatever) that implement
(2)?

~~~
beagle3
Firefox has two about:Config settings, one stops canvas fingerprinting, the
other notifies.

Other settings stop giving out a list of plugins or fonts. And e.g. unlock or
umatriz can rotate your user agent.

It’s not perfect, but with a few tweaks Firefox is much much harder to
fingerprint - though IPv6 tends to undo all of that because many providers
assign a prefix per customer which will never change and can be used by anyone
to correlate.

~~~
gsnedders
How common is the setup those settings put you in, though? Are you more or
less unique in that bin?

------
kodablah
> why browsers can still _stop_ fingerprinting (emphasis mine)

> privacy defenses don’t need to be perfect. Many researchers and engineers
> think about privacy in all-or-nothing terms

So browsers can't stop fingerprinting but they can reduce it, and the article
author's title falls in the same all-or-nothing trap that they criticize
others for. Too often practicality is viewed as defeatism. I don't remember
defeatism, I remember practical limitations to stopping all uniqueness vectors
but realization that some can be stopped.

~~~
incompatible
I remember somebody who worked with Firefox saying that even the idea of not
by default revealing the OS and hardware platform received too much
opposition.

------
csours
To be clear: Yes we should fight fingerprinting...

But: I don't care if only 5% of internet users are uniquely identifiable. I
care if _I_ am uniquely identifiable.

~~~
Iolaum
If you are not uniquely identifiable but 99% of the users are that's enough to
identify you. That's why US Navy funded the tor project. If their people were
the only ones that could hide from other governments then those other
governments knew who those unidentified people were.

~~~
meowface
This is also a big issue with NoScript and similar plugins. A very small
percentage of real users (ignoring bots and headless browsers and such)
intentionally disable JavaScript, so they're painting a target on themselves
while trying to do the opposite.

~~~
mikedilger
This is true. However, most users of NoScript/uMatrix/uBlock are blocking the
script that actually does the fingerprinting. So while the server could infer
information because the script didn't run, usually they get no notification
and tracking simply fails.

~~~
progval
For once, let's thank web developers who assume everyone has javascript
enabled.

------
TekMol
The whole article seems to be based on this study:

[https://www.doc.ic.ac.uk/~maffeis/331/EffectivenessOfFingerp...](https://www.doc.ic.ac.uk/~maffeis/331/EffectivenessOfFingerprinting.pdf)

And sees it as an indicator that preventing fingerprinting is possible:

    
    
        Only a third of users had unique fingerprints,
        despite the researchers’ use of a comprehensive
        set of 17 fingerprinting attributes.
    

To me, the 17 attributes do not seem comprehensive at all. For example they
don't make use of the users IP. So much can be derived from the IP. Carrier,
approximate location etc. They also don't use the local IP, which is leaked
via WebRTC:

[https://browserleaks.com/webrtc](https://browserleaks.com/webrtc)

They also don't seem to measure the performance of CPU, RAM and GPU when
performing different tasks.

But yes: Browsers should do more to prevent fingerprinting. But it seems they
have no inclination to do so. That they don't plug the WebRTC hole that leaks
the local IP is a strong indicator for me that privacy is low on the list of
the browser vendors. Or maybe not on the list at all.

------
mirimir
There's generally a tradeoff between usability and performance, and resistance
to fingerprinting. If your browser has WebGL enabled, the machine (not just
the browser) can be fingerprinted. If it caches resources, adversaries can
discover browsing history.

~~~
amelius
> If your browser has WebGL enabled, the machine (not just the browser) can be
> fingerprinted.

Curious, how would that work exactly? (I've never used WebGL yet in any code).

> If it caches resources, adversaries can discover browsing history.

Same question. I was under the impression that cached resources can be
accessed only by the domain that introduces them.

~~~
deleted_account
This paper discusses the details:

[http://yinzhicao.org/TrackingFree/crossbrowsertracking_NDSS1...](http://yinzhicao.org/TrackingFree/crossbrowsertracking_NDSS17.pdf)

You can also visit their site to see it in action:
[http://uniquemachine.org/](http://uniquemachine.org/)

~~~
mirimir
And re the demo:

> Your graphics card does not seem to support WebGL.

So NoScript is blocking WebGL, as promised.

------
xg15
The irony seems to be this:

> _But there’s another pill that’s harder to swallow: the recent study was
> able to test users in the wild only because the researchers didn’t ask or
> notify the users. [2] With Internet experiments, there is a tension between
> traditional informed consent and validity of findings, and we need new
> ethical norms to resolve this._

So the result of their privacy-advocating study was itself only obtainable by
breaching the privacy of their participants. (I.e. making them participants
without them knowing or consenting to it)

------
ape4
The article mentions Canvas, Battery, Audio,and WebRTC. Should these all
request a user OK before being used?

~~~
alkonaut
Definitely for high entropy APIs at least. Checking if audio or canvas exists
is just two bits.

But e.g. being able to read canvas pixels is absolutely insane that it’s
allowed.

So if just these sources of huge entropy were default swithed off, as the
article says, fingerprinting would be a lot harder.

~~~
arendtio
Especially, canvas would become useless in an opt-in scenario and would just
foster permission fatigue (people just clicking "Allow" because it makes those
dialogs go away).

Another option might be to define closely (pixel-by-pixel) how a canvas should
look like after a specific action. That way vendors would have less room for
'their way' of drawing things but the result would look equal and would be
useless for fingerprinting.

Similarly, one could define a list of fonts which every browser should bring
and all other fonts should be loaded from a server. It would eliminate the
'you have special fonts installed' problem completely.

~~~
alkonaut
The canvas wouldn’t be opt in, only the _pixel reading_ feature would be - and
that’s an edge case that I can’t imagine being used in even one in a thousand
uses of Canvas. Just drawing to a canvas has no privacy implications and
covers almost all uses.

------
textmode
"Another lesson is that privacy defenses don't need to be perfect. Many
researchers and engineers think about privacy in all-or-nothing terms: a
single mistake can be devastating, and if a defense won't be perfect, we
shouldn't deploy it at all."

This "all-or-nothing" perspective is rampant on www forums discussing computer
topics and certainly HN is no exception. It is particularly acute in any
discussions of "privacy" or "security".

There are countless examples.

Earlier this week the topic of SNI rose again to HN's front page.

A minor percentage1 of TLS-enabled websites require SNI. An unfortunate side
effect of SNI is that it makes it easier for third parties to observe which
websites users are accessing via TLS because it sends domainnames unencrypted
in the first packet.

Forum commenters will thus argue because there are other, more difficult means
for some third parties to observe these domainnames, e.g., through traffic
analysis, that the unencrypted SNI is therefore not an issue worth addressing.

All-or-nothing. If the privacy achieved by some proactive measure is not
"perfect" then to these commenters it is worthless.

But the HN front page reference suggested otherwise: It was an RFC describing
how the IETF is taking a proactive measure, trying to "fix" SNI, encrypting it
to prevent third parties from using it in ways detrimental to users.

There is an easier proactive measure. The popular browsers send SNI by
default, even if the website does not require it. The default behaviour is to
accomodate a minority of TLS-enabled websites at the expense of all users,
including those who may not be using this minority of websites.

To make an analogy to fingerprinting, imagine sending 17 unique identifiers
with every HTTP transaction when, say, only 5 are actually needed. The all-or-
nothing perspective adopted by forum commenters would dictate that it makes no
sense to reduce the number unless the number can be reduced to zero.

Amongst the security folks there is a concept sometimes called "defense in
depth". Commenters in discussions about security often agree there is no such
thing as "perfect" security and they cannot rely on a single, "silver bullet".
They must use multiple tactics.

Is privacy somehow different? There are many tactics users can take that,
cumulatively, can make things more difficult for the data collectors.

1 Survey of websites currently appearing on HN

Number of unique urls: 367

Number of http urls: 43

Number of https urls: 324

Number of https urls requiring SNI: 38

Number of https urls requiring correct SNI: 26

"Requiring correct SNI" means SNI must match Host header.

Summary

One can fetch 286 of the 324 https urls currently posted on HN with a HTTP
client that does not send SNI.

An additional 12 can be retrieved by sending a decoy SNI name that does not
match the Host header.

------
gasull
There is Privacy Possum, a Firefox and Chrome extension that works better
against fingerprinting than Privacy Badger:

[https://github.com/cowlicks/privacypossum](https://github.com/cowlicks/privacypossum)

~~~
aendruk
How does it differ from Privacy Badger? (In goals, threat model,
implementation, etc.?) I found the readme to be a little incomprehensible.

------
auslander
It starts saying all the right things, I was, like, expecting real tech stuff,
after intro, and ... post ends.

Where is per browser stats, correlations, data points and features? Canvas vs
IP vs User-agents?

~~~
ComodoHacker
That's what hypertext is for. Follow the links.

------
raven11
What is needed is a community written and funded privacy browser. Mozilla the
billion dollar non profit and Firefox their so called privacy first brwoser is
the biggest exfiltrator of user data. Their default 5000 user settings are all
geared towards feeding them and Google real time user activity feed. They have
moved from being Google data bi.ch to a major data collection thug themselves.
As such fingerprinting becomes at best a tangential issue.

------
jstewartmobile
Sets up a straw man of " _privacy defeatism_ ", then knocks it down with an
analysis of some French website's logs-- _as though any of this were a
technological problem in the first place_.

This is not a case of " _defense in depth_ " or " _something is better than
nothing_." This is the case of a surveillance capitalism asset performing to
spec.

Privacy in the browser is/was f-ed, plain and simple. Patch one hole, make two
more. That's how it's been for at least 20 years now. I see no reason for that
to change until the browser is obsolesced by something even better at fleecing
the peasants.

