Re: Browser Fingerprinting

[Boruch Baum <boruch_baum@xxxxxxx>]

On 2020-04-15 21:19, Tomas Nordin wrote:
> Emanuel Berg via Users list for the GNU Emacs text editor

Thank for cc'ing this list. I'm interested in this topic and would like
to stay in the loop for it.

> > Here is an interesting article on so called "Browser
> > Fingerprinting" [1]. This can be of some concern to
> > people using uncommon browsers like Emacs-w3m.
>
> I did this test at https://panopticlick.eff.org in 2017 with emacs w3m.
> ...
> (emacs w3m). Here are some more stats from that test:
>
>                         Test                         Result
> Is your browser blocking tracking ads?               ✓ yes
> Is your browser blocking invisible trackers?         ✓ yes
> Is your browser accepting Do Not Track commitments?  ✗ no

This 'Do Not Track' standard is a very modern development that I
understand no-one (server-side) honestly honors. I remember reading that
using it client-side only serves to identify you as someone likely to be
using privacy protections, which is undesirable because you're just
begging the server-side to invoke counter-measures.

> Does your browser protect from fingerprinting?       ✗ no

This has me puzzled. How did the website reach this answer? My memory of
this subject is that fingerprinting can only happen when the client
either voluntarily puts fingerprinting data in HTTP GET/POST requests,
or when the client has a javascript API that can be queried to reveal
fingerprinting data. AFAICT, neither emacs-w3m nor w3m do either. Off
the top of my head, some examples of fingerprint data that I remember
being common are: available fonts, display geometry and properties,
geo-location, data from device sensors (eg. temperature, accelerometer)
, hardware specifications, software environment, and device specific
stuff like UUID numbers.

BTW, If you are using a modern and updated version of linux, you may be
surprised to find that year ~2016 someone quietly added a small file
named 'machine-id' to your /etc directory. This would be the ultimate
identifying fingerprint, and has been brought to you/us courtesy of the
Red-Hat corporation, a genuinely giant supporter of and contributor to
open-source software, FOSS, systemd, dbus, etc. Red Hat corporation only
exists because of their major paying customers, so indirectly that
obligates us to be grateful to those customers, which probably include
your nation's counterpart to the US Department of Defense and US
National Security Agency.

But, like I said, AFAICT neither emacs-w3m nor w3m have any way for a
server to see the contents of /etc/machine-id.

>
> > Because Emacs-w3m doesn't support JavaScript, one should
> > be safe from all that save for the cookies, but they can
> > be be disabled with
> >
> >   (setq w3m-use-cookies nil)
>
> didn't turn that off...

If you can live with setting this variable to nil, that's great.
However, many people use websites that just won't work without a local
session cookie. For those cases, emacs-w3m currently requires the user
to set the variable t, and to remember to manually delete the generated
cookies 'when appropriate', which is an intentionally vague way of
saying "it's complicated".

FYI, command M-x w3m-cookie allows you to view and manually manipulate
cookie data. I think that it's bound by default to keybinding M-k. There
also exists command M-x w3m-cookie-clear. Additionally, I've had a
long-standing pull-request pending for a feature I wrote to clear ALL the
browser's personal history (w3m-history-scrub).

  https://github.com/emacs-w3m/emacs-w3m/pull/2

I've been using the feature for over a year in my personal version

  https://github.com/Boruch-Baum/emacs-w3m

> > Then there is also the User-Agent field in the HTTP
> > request which browser supplies voluntarily.
> > Because Emacs-w3m isn't the most common of browsers,
> > this field can be used to identify YOU - possibly.
> > Inhibit with
> >
> >   (setq w3m-add-user-agent nil)

A few years ago, I reported a bug that this variable wasn't being
respected when set to nil. This wasn't a bug in emacs-w3m, but in w3m.
emacs-w3m uses w3m as a back-end, and w3m wasn't respecting nil
user-agent requests. Instead, w3m was replacing nil with its own default
string. This bug may have been fixed, but I don't remember. The person
who should know would be the w3m maintainer, Tatsuya Kinoshita
<tats@xxxxxxxxxx>.

What might be more useful is to set variable w3m-add-user-agent to t,
and then set w3m-user-agent to some generic and popular user-agent string.

> > Of course, the IP is still there, because otherwise the
> > server won't know where to send the requested HTML.
> > I think it is much more likely that tracking will be
> > done using that, than the browser fingerprint!
>
> Maybe. EFF explained to me at the time that browser fingerprinting is
> more effective since IP can change over time and can be fiddled with
> with VPN and so on. (Of course browser can change as well but anyway)

If your client is accessing the internet from behind a router, it may be
sharing public-facing ipv4 address with all other devices behind that
router.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0