* Browser Fingerprinting @ 2020-04-15 5:44 Emanuel Berg via Users list for the GNU Emacs text editor 2020-04-15 19:19 ` Tomas Nordin 0 siblings, 1 reply; 20+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-04-15 5:44 UTC (permalink / raw) To: help-gnu-emacs; +Cc: emacs-w3m 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Browser Fingerprinting 2020-04-15 5:44 Browser Fingerprinting Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-04-15 19:19 ` Tomas Nordin 2020-04-17 1:51 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-04-17 2:55 ` [emacs-w3m:13608] " Boruch Baum 0 siblings, 2 replies; 20+ messages in thread From: Tomas Nordin @ 2020-04-15 19:19 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs; +Cc: emacs-w3m 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Browser Fingerprinting 2020-04-15 19:19 ` Tomas Nordin @ 2020-04-17 1:51 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-04-17 7:46 ` Tomas Nordin 2020-04-17 2:55 ` [emacs-w3m:13608] " Boruch Baum 1 sibling, 1 reply; 20+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-04-17 1:51 UTC (permalink / raw) To: help-gnu-emacs; +Cc: emacs-w3m 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Browser Fingerprinting 2020-04-17 1:51 ` Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-04-17 7:46 ` Tomas Nordin 0 siblings, 0 replies; 20+ messages in thread From: Tomas Nordin @ 2020-04-17 7:46 UTC (permalink / raw) To: Emanuel Berg, help-gnu-emacs; +Cc: emacs-w3m 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... ^ permalink raw reply [flat|nested] 20+ messages in thread
* [emacs-w3m:13608] Re: Browser Fingerprinting 2020-04-15 19:19 ` Tomas Nordin 2020-04-17 1:51 ` Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-04-17 2:55 ` Boruch Baum 2020-04-17 3:33 ` [emacs-w3m:13609] " Emanuel Berg ` (3 more replies) 1 sibling, 4 replies; 20+ messages in thread From: Boruch Baum @ 2020-04-17 2:55 UTC (permalink / raw) To: tomasn, emacs-w3m; +Cc: Emanuel Berg, help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [emacs-w3m:13609] Re: Browser Fingerprinting 2020-04-17 2:55 ` [emacs-w3m:13608] " Boruch Baum @ 2020-04-17 3:33 ` Emanuel Berg 2020-04-17 8:15 ` [emacs-w3m:13607] " Tomas Nordin ` (2 subsequent siblings) 3 siblings, 0 replies; 20+ messages in thread From: Emanuel Berg @ 2020-04-17 3:33 UTC (permalink / raw) To: emacs-w3m; +Cc: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 2:55 ` [emacs-w3m:13608] " Boruch Baum 2020-04-17 3:33 ` [emacs-w3m:13609] " Emanuel Berg @ 2020-04-17 8:15 ` Tomas Nordin 2020-04-17 8:57 ` [emacs-w3m:13611] " Boruch Baum 2020-04-17 8:17 ` tomas 2020-04-17 19:31 ` Vladimir Sedach 3 siblings, 1 reply; 20+ messages in thread From: Tomas Nordin @ 2020-04-17 8:15 UTC (permalink / raw) To: Boruch Baum, emacs-w3m; +Cc: help-gnu-emacs, Emanuel Berg 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* [emacs-w3m:13611] Re: Browser Fingerprinting 2020-04-17 8:15 ` [emacs-w3m:13607] " Tomas Nordin @ 2020-04-17 8:57 ` Boruch Baum 2020-04-17 9:35 ` [emacs-w3m:13607] " tomas 2020-04-18 10:12 ` Tomas Nordin 0 siblings, 2 replies; 20+ messages in thread From: Boruch Baum @ 2020-04-17 8:57 UTC (permalink / raw) To: Tomas Nordin; +Cc: emacs-w3m, Emanuel Berg, help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 8:57 ` [emacs-w3m:13611] " Boruch Baum @ 2020-04-17 9:35 ` tomas 2020-04-17 19:17 ` Vladimir Sedach 2020-04-17 21:50 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-04-18 10:12 ` Tomas Nordin 1 sibling, 2 replies; 20+ messages in thread From: tomas @ 2020-04-17 9:35 UTC (permalink / raw) To: help-gnu-emacs [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 9:35 ` [emacs-w3m:13607] " tomas @ 2020-04-17 19:17 ` Vladimir Sedach 2020-04-17 21:08 ` Vladimir Sedach 2020-04-17 21:50 ` Emanuel Berg via Users list for the GNU Emacs text editor 1 sibling, 1 reply; 20+ messages in thread From: Vladimir Sedach @ 2020-04-17 19:17 UTC (permalink / raw) To: tomas; +Cc: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 19:17 ` Vladimir Sedach @ 2020-04-17 21:08 ` Vladimir Sedach 2020-04-18 1:46 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 1 reply; 20+ messages in thread From: Vladimir Sedach @ 2020-04-17 21:08 UTC (permalink / raw) To: tomas; +Cc: help-gnu-emacs, emacs-w3m 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 21:08 ` Vladimir Sedach @ 2020-04-18 1:46 ` Emanuel Berg via Users list for the GNU Emacs text editor 0 siblings, 0 replies; 20+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-04-18 1:46 UTC (permalink / raw) To: help-gnu-emacs; +Cc: emacs-w3m 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 9:35 ` [emacs-w3m:13607] " tomas 2020-04-17 19:17 ` Vladimir Sedach @ 2020-04-17 21:50 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-04-18 6:56 ` tomas 1 sibling, 1 reply; 20+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-04-17 21:50 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 21:50 ` Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-04-18 6:56 ` tomas 0 siblings, 0 replies; 20+ messages in thread From: tomas @ 2020-04-18 6:56 UTC (permalink / raw) To: help-gnu-emacs [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 8:57 ` [emacs-w3m:13611] " Boruch Baum 2020-04-17 9:35 ` [emacs-w3m:13607] " tomas @ 2020-04-18 10:12 ` Tomas Nordin 2020-04-19 1:26 ` Boruch Baum 2020-04-19 3:16 ` Emanuel Berg via Users list for the GNU Emacs text editor 1 sibling, 2 replies; 20+ messages in thread From: Tomas Nordin @ 2020-04-18 10:12 UTC (permalink / raw) To: Boruch Baum; +Cc: help-gnu-emacs, emacs-w3m, Emanuel Berg 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-18 10:12 ` Tomas Nordin @ 2020-04-19 1:26 ` Boruch Baum 2020-04-19 3:16 ` Emanuel Berg via Users list for the GNU Emacs text editor 1 sibling, 0 replies; 20+ messages in thread From: Boruch Baum @ 2020-04-19 1:26 UTC (permalink / raw) To: Tomas Nordin; +Cc: help-gnu-emacs, emacs-w3m, Emanuel Berg 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-18 10:12 ` Tomas Nordin 2020-04-19 1:26 ` Boruch Baum @ 2020-04-19 3:16 ` Emanuel Berg via Users list for the GNU Emacs text editor 1 sibling, 0 replies; 20+ messages in thread From: Emanuel Berg via Users list for the GNU Emacs text editor @ 2020-04-19 3:16 UTC (permalink / raw) To: help-gnu-emacs; +Cc: emacs-w3m 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 2:55 ` [emacs-w3m:13608] " Boruch Baum 2020-04-17 3:33 ` [emacs-w3m:13609] " Emanuel Berg 2020-04-17 8:15 ` [emacs-w3m:13607] " Tomas Nordin @ 2020-04-17 8:17 ` tomas 2020-04-17 19:31 ` Vladimir Sedach 3 siblings, 0 replies; 20+ messages in thread From: tomas @ 2020-04-17 8:17 UTC (permalink / raw) To: help-gnu-emacs [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 2:55 ` [emacs-w3m:13608] " Boruch Baum ` (2 preceding siblings ...) 2020-04-17 8:17 ` tomas @ 2020-04-17 19:31 ` Vladimir Sedach 2020-04-19 1:21 ` Boruch Baum 3 siblings, 1 reply; 20+ messages in thread From: Vladimir Sedach @ 2020-04-17 19:31 UTC (permalink / raw) To: Boruch Baum; +Cc: help-gnu-emacs, emacs-w3m 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [emacs-w3m:13607] Re: Browser Fingerprinting 2020-04-17 19:31 ` Vladimir Sedach @ 2020-04-19 1:21 ` Boruch Baum 0 siblings, 0 replies; 20+ messages in thread From: Boruch Baum @ 2020-04-19 1:21 UTC (permalink / raw) To: Vladimir Sedach; +Cc: help-gnu-emacs, emacs-w3m 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2020-04-19 3:16 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-04-15 5:44 Browser Fingerprinting Emanuel Berg via Users list for the GNU Emacs text editor 2020-04-15 19:19 ` Tomas Nordin 2020-04-17 1:51 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-04-17 7:46 ` Tomas Nordin 2020-04-17 2:55 ` [emacs-w3m:13608] " Boruch Baum 2020-04-17 3:33 ` [emacs-w3m:13609] " Emanuel Berg 2020-04-17 8:15 ` [emacs-w3m:13607] " Tomas Nordin 2020-04-17 8:57 ` [emacs-w3m:13611] " Boruch Baum 2020-04-17 9:35 ` [emacs-w3m:13607] " tomas 2020-04-17 19:17 ` Vladimir Sedach 2020-04-17 21:08 ` Vladimir Sedach 2020-04-18 1:46 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-04-17 21:50 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-04-18 6:56 ` tomas 2020-04-18 10:12 ` Tomas Nordin 2020-04-19 1:26 ` Boruch Baum 2020-04-19 3:16 ` Emanuel Berg via Users list for the GNU Emacs text editor 2020-04-17 8:17 ` tomas 2020-04-17 19:31 ` Vladimir Sedach 2020-04-19 1:21 ` Boruch Baum
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).