Going a bit further into this difficult profile overhaul - since it seems to be the source of all my problems and I should have cleaned this mess a long time ago - I started reviewing my older prefs.js file and comparing it with the one on the current vanilla TBB (13.5.1) That’s when I found out that an all-important setting had now been reverted to opt-in by default in the vanilla browser:
beacon.enabled=true
I am very unhappy about this! I had this set to false a long long time ago, because it is a typical “phone home” and even worse “phone everywhere” spec that was successfully pushed by the Ad industry Lords into W3C standards as a “new convenience” for users - but in fact what it does is help them circumvent cookie anti-tracking in yet another manner.
Specifically, this pref is known as navigator.sendBeacon() and its purpose is to send data to (potentially cross-domain) servers, particularly when leaving a page.
I can’t explain the logic of the TorProject for setting this as opt-in by default: it serves only the Lords and has absolutely no other purpose or use for the end-user…
Fortunately, an other one same type of very problematic pref browser.send_pings (bool) also known as Hyperlink-auditing or <a ping> is still set to false by default. No need to change this manually via about:config
Create a topic on the Tor Project Forum about it.
Thanks for the heads-up. I hadn’t heard of this particular setting before, so I did some reading. This is more for anyone else since I assume you already know, based on what you wrote.
The basic thrust of it is - when you exit a page, the page reports back to the Overlords what you did on the page (i.e. no matter how it is implemented, a breach of privacy).
There are two available implementations:
- A page can use the Beacon API and then the web browser executes this breach of privacy, on behalf of the page, asynchronously.
- A page can use the XMLHttpRequest API call and then the page executes this breach of privacy itself, synchronously, which makes page navigation more laggy.
A max-privacy intrusive web page would try the former API and if the API is disabled, it would failover to the latter API.
A slightly nicer web page might try the former API and if the API is disabled, it would give up (taking the hint from the user that the user didn’t want this kind of snoopy sh!t).
Thank you for your suggestion. Not being registered with the Tor Project Forum, I can’t create a topic. Do I want to register in order to post? I’m not too keen on that. I don’t want to ever multiply the forums I am active on, and especially not if - being the case - I will probably be posting only once to ask about this beacon business.
Besides, although I’m very fond of their project and software, I don’t feel particularly competent in this area.
But I do hope maybe someone here also active on their forum would care to discuss the matter with them.
I am puzzled that it hasn’t been mentioned yet…could I really be the only one having spotted this issue? Strange.
EDIT: Actually, I found a thread on their gitlab:
Interesting discussion. Seems it is an issue more complex than it looked at first glance. It’s a problem of compatibility vs privacy…
Looks like the Tor Project team already has it well handled browser-side. That being said, thank you for sharing the GitLab link.
transform it to a no-op
Hmmm. If that got implemented then maybe you do want beacon.enabled=true
However, on vanilla Firefox you probably still want it false