[emacs-w3m:13608] Re: Browser Fingerprinting
Boruch Baum <[email protected]> Thu, 16 Apr 2020 22:55:14 -0400
| Newsgroups | gmane.emacs.w3m,gmane.emacs.help |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]>. 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