Re: Browser Fingerprinting

[Boruch Baum <boruch_baum@xxxxxxx>]

On 2020-04-17 10:15, Tomas Nordin wrote:
> The fields tested as browser characteristtics were
> ...

Thanks. Good to know.

> The most identifying characteristics is User Agent followed by
> HTTP_ACCEPT Headers.

Of course emacs-w3m and w3m have no choice but to send them, but ...


> Browsing the web with a text based browser is not a common thing to do,
> so from a browser fingerprinting point of view I guess the uniqeness is
> to be expected.

Right. That's why I suggested in my original e-mail...


   "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."

That leaves us with the matter of the HTTP_ACCEPT Headers. My memory is
that the information sent in that header is very limited, just a set of
mime-types that the server can use to send data to the client. That
doesn't seem to me to be much from which to create a fingerprint, but it
would be great to do a comparison. emacs-w3m does have configurable
variables for that feature that I guess ought to be what is in those
headers (see, for example, w3m-content-type-alist and
w3m-default-content-type) Otherwise, I don't know what identifying
information is in that header. I don't have time to look at this now,
but have added it to my (long) emacs-w3m to-do list. As is true with the
case of the user-agent string, I would have to also see what w3m is
sending.

If you do more research on this, please keep me informed, and if I have
any other insights, I'd be happy to share them. The simplest test would
be check the uniqueness score after following my suggestion about using
a false user-agent string. A second step would be to compare ACCEPT
headers with a common browser, and see how changing the emacs-w3m
variables can cause the results to yield a better result.

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