Browser Fingerprinting

Browser Fingerprinting

[Emanuel Berg via Users list for the GNU Emacs text editor]

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.

The way they do fingerprinting is with cookies, with
JavaScript, and/or with HTML5 canvas (which uses
JavaScript).

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)

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)

Now, check out the progress on [2] :)

(The language is still "en" - however I don't think
anyone can be tracked using that data...)

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!
But that's not a browser issue, people who look for that
kind of anonymity will probably use VPN or Tor or be on
some other *net altogether, besides the internet...

Even if you feel you have nothing to hide, and you are
not paranoid, it can be a good feeling not to give
anything to these bozos anyway :)


[1] https://pixelprivacy.com/resources/browser-fingerprinting/

[2] https://amiunique.org/fpNoJS

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Browser Fingerprinting

[Tomas Nordin]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> 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.
I was then unique among 216 118 browsers. I think the count is tested
browser the last N days. I did it again now and was unique among 175 561
browser the last 45 days with 17.42 bits of identifying information
(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  
Does your browser protect from fingerprinting?       ✗ no  

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

> 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)

Didn't do that.

> Now, check out the progress on [2] :)

Here I get

... full fingerprint is unique among the 1 936 960 collected so far.

> (The language is still "en" - however I don't think
> anyone can be tracked using that data...)
>
> 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)

> But that's not a browser issue, people who look for that kind of
> anonymity will probably use VPN or Tor or be on some other *net
> altogether, besides the internet...
>
> Even if you feel you have nothing to hide, and you are
> not paranoid, it can be a good feeling not to give
> anything to these bozos anyway :)

Browser fingerprinting for tracking users ought to be illegal. It's just
wrong, no matter you have something to hide or not. Edward Snowden said
something I agree with -- saying that you don't care about privacy
because you don't have anything to hide is like saying you don't care
about freedom of speech because you have nothing to say.

Best regards
--
Tomas

Re: Browser Fingerprinting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Tomas Nordin wrote:

>> 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 [...]

That doesn't work for me, just says

  loading...

  Refresh (3 sec) [...]

>> 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)

Without an IP that points from the server record to your
conapt, just knowing that someone with a certain browser
has requested a service from the server - I don't think
that will be enough to associate the user with the
action - not legally, and not even practically, let's
say you deal with organized crime or live in
a dictatorship - or am I wrong? Because how will they
find you?

> Browser fingerprinting for tracking users ought to be
> illegal. It's just wrong, no matter you have something
> to hide or not. Edward Snowden said something I agree
> with -- saying that you don't care about privacy
> because you don't have anything to hide is like saying
> you don't care about freedom of speech because you
> have nothing to say.

Well, OK :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

[emacs-w3m:13608] Re: Browser Fingerprinting

[Boruch Baum]

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@debian.org>.

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

[emacs-w3m:13609] Re: Browser Fingerprinting

[Emanuel Berg]

Boruch Baum wrote:

> fingerprinting can only happen when the client either
> voluntarily puts fingerprinting data in HTTP GET/POST
> requests [...] AFAICT, neither emacs-w3m nor w3m
> do either.

C-h v w3m-add-user-agent RET

    w3m-add-user-agent is a variable defined in ‘w3m.el’.
    Its value is nil
    Original value was t

    Documentation:
    Non-nil means add the User-Agent field to the request header.
    The value of ‘w3m-user-agent’ is used for the field body.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Browser Fingerprinting

[Tomas Nordin]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Tomas Nordin wrote:
>
>>> 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 [...]
>
> That doesn't work for me, just says
>
>   loading...
>
>   Refresh (3 sec) [...]

After a number of such reloads I got the results...

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[Tomas Nordin]

Boruch Baum <boruch_baum@gmx.com> writes:

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

The fields tested as browser characteristics were

User Agent
HTTP_ACCEPT Headers
Browser Plugin Details
Time Zone Offset
Time Zone
Screen Size and Color Depth
System Fonts
Are Cookies Enabled?
Limited supercookie test
Hash of canvas fingerprint
Hash of WebGL fingerprint
WebGL Vendor & Renderer
DNT Header Enabled?
Language
Platform
Touch Support
Ad Blocker Used
AudioContext fingerprint
CPU Class
Hardware Concurrency
Device Memory (GB)

And most of the values are "no javascript" when testing with w3m,
otherwise yes/no or true/false. The "no javascript" gives a
fingerprinting value as well (bits of identifying information).

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

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.

Best regards
--
Tomas

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[tomas]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Thu, Apr 16, 2020 at 10:55:14PM -0400, Boruch Baum wrote:

[...]

> > 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,

"Browser fingerprinting" is just a catch-all term for trying to
extract as many tidbits of characteristics to be able to identify
that individual browser instance. This can range from "voluntarily"
provided model/version up to some image rendering timings, etc.

See [1] to get an idea.

Cheers

[1] https://en.wikipedia.org/wiki/Browser_fingerprinting#Browser_fingerprint
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[emacs-w3m:13611] Re: Browser Fingerprinting

[Boruch Baum]

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

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

On Fri, Apr 17, 2020 at 04:57:16AM -0400, Boruch Baum wrote:
> 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."

What I'd do is randomly select from a choice of, say, 100
popular browser strings.

Bonus points if we manage to come up with a random schedule
which is "just right" -- too much random and "they" [1] notice,
too little random and they're not confused enough.

Cheers

[1] No, not some little grey men. Just the algorithms. Paid by
   the ad industry, so working for them...
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[Vladimir Sedach]

tomas@tuxteam.de writes:
>>    "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."
>
> What I'd do is randomly select from a choice of, say, 100
> popular browser strings.

A while back I tried setting w3m-user-agent to a recent Firefox
user-agent string. Some websites (YouTube is one example I recall)
started returning different pages that assumed JavaScript and AJAX
and were no longer usable in emacs-w3m.

--
Vladimir Sedach
Software engineering services in Los Angeles https://oneofus.la

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[Vladimir Sedach]

Boruch Baum <boruch_baum@gmx.com> writes:
> 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".

Cookies in emacs-w3m can be enabled per-domain:

--8<---------------cut here---------------start------------->8---
(setq w3m-cookie-reject-domains '(".")
      w3m-cookie-accept-domains '(".common-lisp.net"
                                  ".gnu.org"))
--8<---------------cut here---------------end--------------->8---

--
Vladimir Sedach
Software engineering services in Los Angeles https://oneofus.la

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[Vladimir Sedach]

Vladimir Sedach <vas@oneofus.la> writes:
> A while back I tried setting w3m-user-agent to a recent Firefox
> user-agent string. Some websites (YouTube is one example I recall)
> started returning different pages that assumed JavaScript and AJAX
> and were no longer usable in emacs-w3m.

I should have checked my configuration before posting the above.
emacs-w3m has an option to send different user agent strings to
specified domains. Example from my current configuration:

--8<---------------cut here---------------start------------->8---
(setq w3m-user-agent
      "Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
      w3m-user-agent-site-specific-alist
      '(("youtube.com" . "Emacs-w3m/1.4.620 w3m/0.5.3")))
--8<---------------cut here---------------end--------------->8---

--
Vladimir Sedach
Software engineering services in Los Angeles https://oneofus.la

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

> What I'd do is randomly select from a choice of, say,
> 100 popular browser strings.

Well, not _everyone_ who objects to this is an Emacs-w3m
user. Actually I'm sure the vast majority who disables
this feature does not use Emacs-w3m. So they can't tell
we use Emacs-w3m just because there is no UA!

Besides, as long as there is data, incorrect as it might
be, this still encourages them to develop algorithms
that will act upon that data, and this might hurt
everyone else who still submits correct data.

So I say we should not submit any data for two reasons,
one, other people are also not submitting theirs, and
two, other people are submitting theirs :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Vladimir Sedach wrote:

>> A while back I tried setting w3m-user-agent to
>> a recent Firefox user-agent string. Some websites
>> (YouTube is one example I recall) started returning
>> different pages that assumed JavaScript and AJAX and
>> were no longer usable in emacs-w3m.
>
> I should have checked my configuration before posting
> the above. emacs-w3m has an option to send different
> user agent strings to specified domains. Example from
> my current configuration:
>
> (setq w3m-user-agent
>       "Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
>       w3m-user-agent-site-specific-alist
>       '(("youtube.com" . "Emacs-w3m/1.4.620 w3m/0.5.3")))

You can still, with w3m-user-agent nil even for YouTube,
use Emacs-w3m to get URLs and then use mpv(1) to
play them.

It is better for other reasons as well as mpv is
configurable and generally just more powerful than the
web UI.

Here is a guy who does videos on fixed gear bicycles.
Note that the videos will just keep playing, so it is
also less fiddly as you don't have to get a new videos
all the time, and when you had enough, just hit SPC to
pause (or Q to quit, with the option
save-position-on-quit [1]).

  bike () {
      mpv 'https://www.youtube.com/channel/UCrkVFY8V-H_JEH-Nv7ylN5g'
  }

And here is live news from Australian TV, ABC:

  abc () {
      mpv 'https://www.youtube.com/watch?v=WsRUC73L-MA'
  }


[1] https://dataswamp.org/~incal/conf/mpv/mpv.conf
    https://dataswamp.org/~incal/conf/mpv/input.conf

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

On Fri, Apr 17, 2020 at 11:50:19PM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> tomas wrote:
> 
> > What I'd do is randomly select from a choice of, say,
> > 100 popular browser strings.
> 
> Well, not _everyone_ who objects to this is an Emacs-w3m
> user. Actually I'm sure the vast majority who disables
> this feature does not use Emacs-w3m. So they can't tell
> we use Emacs-w3m just because there is no UA!

I was proposing that with some tongue-in-cheek ;-P

But yes, this stupid data collection craze does get on my nerves,
sometimes.

> Besides, as long as there is data, incorrect as it might
> be, this still encourages them to develop algorithms
> that will act upon that data, and this might hurt
> everyone else who still submits correct data.

If the data is uniformly distributed, it'll hurt everyone uniformly
(again, somewhat tongue-in-cheek ;-P

> So I say we should not submit any data for two reasons,
> one, other people are also not submitting theirs, and
> two, other people are submitting theirs :)

A friend of mine once proposed to return the contents of
/dev/urandom if the server requests a cookie. All of it.

But that was still a time when half of the Web servers there
didn't request a cookie.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[Tomas Nordin]

Boruch Baum <boruch_baum@gmx.com> writes:

> 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

Different browsers (mis)use this header string differently [1]. The
string lists mime types in a certain order with some optional ratings
for each. If an un-common browser has this string different from common
browsers it adds uniqueness.

[1] https://www.newmediacampaigns.com/blog/browser-rest-http-accept-headers

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[Boruch Baum]

On 2020-04-17 12:31, Vladimir Sedach wrote:
> Cookies in emacs-w3m can be enabled per-domain:
>
> --8<---------------cut here---------------start------------->8---
> (setq w3m-cookie-reject-domains '(".")
>       w3m-cookie-accept-domains '(".common-lisp.net"
>                                   ".gnu.org"))
> --8<---------------cut here---------------end--------------->8---

Thanks. I had forgotten about that.

A similar feature exists for user-agent strings:
w3m-user-agent-site-specific-alist.

Also, I had forgotten that emacs-w3m has a command w3m-user-agent-change
to allow the user to change user agent strings on the fly. See also
variables w3m-user-agent-alist and w3m-user-agent-default-alist.

What a wonderful and feature-rich piece of software! And it was
originally written over 20 years ago! Thanks Katsumi and Tsuchiya and
every one else!

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

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[Boruch Baum]

On 2020-04-18 12:12, Tomas Nordin wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
> > That leaves us with the matter of the HTTP_ACCEPT Headers.
> > ...
>
> Different browsers (mis)use this header string differently [1]. The
> string lists mime types in a certain order with some optional ratings
> for each. If an un-common browser has this string different from common
> browsers it adds uniqueness.
>
> [1] https://www.newmediacampaigns.com/blog/browser-rest-http-accept-headers

Good to know, Thanks. If you have any test or comparison data of
how w3m/emacs-w3m actually operates versus common browsers, please share.

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

Re: [emacs-w3m:13607] Re: Browser Fingerprinting

[Emanuel Berg via Users list for the GNU Emacs text editor]

Tomas Nordin wrote:

> Different browsers (mis)use this header string
> differently [1]. The string lists mime types in
> a certain order with some optional ratings for each.
> If an un-common browser has this string different from
> common browsers it adds uniqueness.
>
> [1] https://www.newmediacampaigns.com/blog/browser-rest-http-accept-headers

But now we are talking some other string, right?

The UA string as defined in `w3m-user-agent' is, in my
system at least "Emacs-w3m/1.4.632
w3m/0.5.3+git20190105", it seems to be made up of the
version numbers of Emacs-w3m and w3m(1), which are BTW
derived/also present (?) from/in `emacs-w3m-version' and
`w3m-version'.

However what they speak of in that URL is a string that
states in what form the server should grant a HTTP
request from the browser. I didn't find any Emacs-w3m
variable for that but outside of Emacs-w3m but still in
Emacs this sounds like it:

  url-mime-accept-string
  String to send to the server in the Accept: field in
  HTTP requests.

I don't know what that package is tho, nor if it is used
by Emacs-w3m.

Its nil anyway.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal