(This only applies to visiting an actual web site, not when doing a search.)
This is exactly the opposite of what I said happens, however I did write that I am only surmising.
Lord Google sees a (periodic) request to download a list of bad sites. I guess if you are using TOR, that request may in fact not come from any meaningful IP address but I didn’t check to see whether that download bypasses TOR. It must come with some metadata but how significant that metadata would be, I don’t know.
At the time of visiting an actual web site, your web browser will make a check of the domain of the URL against the list of bad sites.
However I did see some discussion on the web suggesting that in some cases, if the site is rejected because it’s on the list of bad sites then the web browser will make a confirming check to make sure that revocation has not happened in the meantime (which sounds to me like functionality that I wouldn’t like!).
Tor Browser 13.5.1 (latest), based on Firefox 115.13.0esr
Actually, I was thinking about something like this…but would TorProject really leave this crap from Firefox ESR and not remove it downstream - I mean it TAINTS the browser!
Which raises another question: could it be that they are simply not aware of this behavior, so didn’t care to remove these DSN requests? I hardly believe this.
I’ve always had this setting disabled, after it was discovered that nosy Google was using this for spying and scraping more data from FF users (usually considered more “privacy-conscious”) This was a big scandal, I remember. Then Mozilla had to change this and implement their own block lists for malware accessing their own servers instead of Google’s. But even with this issue resolved, I don’t rely on Moz or Google for this, but on specific lists on UBo for this same purpose. So I don’t think it to be the problem, since the browser needs not accessing those lists or make any DNS requests for this purpose in the background.
I have also considered this could be caused not by the browser itself, but by an extension or a plug-in. So I checked launching TB with all extensions disabled, no plug-in, no search engine. But the browser stubbornly behaves the same way and does the 12 DNS requests first thing after launch nonetheless.
This is really puzzling and I can’t find an explanation for this strange behaviour.
Before creating a topic on the Tor Project Forum, try using Mullvad Browser and see if it reproduces the same behavior, as both Mullvad VPN and the Tor Project collaborated on it:
For what it’s worth, I don’t see that behaviour - but I am running a somewhat out of date version of TorBrowser (it is grinding through downloading the update now).
I see 2 HTTP requests (content-signature-2.cdn.mozilla.net and aus1.torproject.org), neither of which is particularly concerning and I see none of the DNS requests that you mention (either listed by the browser or in my DNS server logs).
After connecting to TOR I see a couple more HTTP requests (firefox.settings.services.mozilla.com and firefox-settings-attachments.cdn.mozilla.net), again nothing offensive.
OK, update completed but I am still well short of the version that you have. (I will need to look into that anyway.)
DNS now shows under DoH URL https://mozilla.cloudflare-dns.com/dns-query so it looks like the update caused Firefox to grow DoH functionality - and using Cloudflare for this may or may not be acceptable to the user.
In any case, still only seeing relatively benign hostnames referenced i.e. nothing googly.
After connecting I see some requests to securedrop.org which may or may not be bad.
SecureDrop is software used for submitting documents, usually in the form of leaks, to news organizations:
Depending on how you installed Tor Browser, it may have a home page about your new installation, along with Tor-related resources for you to consider using.
OK, so I moved my Tor Browser to one side and just downloaded it again from scratch. I now have 13.5.1 based on Firefox 115.13.0 i.e. same as you (and presumably I have a 100% vanilla Tor Browser configuration e.g. I have changed no settings).
On startup, aus1.torproject.org and versioncheck-bg.addons.mozilla.org
After Connect, securedrop.org, bridges.torproject.org, r3.o.lencr.org
I am totally inexperienced on the subject (although I would like to educate myself about it) so I prefer to use gnome web browser which, although crashing all the time, is the only browser, to my knowledge, oriented to privacy and security!
Thank you for trying this. I did so too in order to confirm your observations and it is true that a clean installation of 13.5.1 (with no other modification to settings) makes the problem disappear.
Those are legitimate: one is for checking if there is a version update for Tor, and the other checks the addons for potential updates. So the conclusion could only be this one: I must have someting in my profile that causes it. This was pretty hard to diagnose: moving things one by one from the old profile to the new install and checking each time if the DNS requests had come back. But in the end, I found the culprit: an older German anonymizing search engine I had installed, called Metager (for German MetaEngine) was doing those weird DNS requests at launch - but without actually accessing the sites it requested the IPs for.
So I should not have incriminated the TorProject for this! But these modern browsers have become so complicated now, it is hard to troubleshoot when something doesn’t work or seems weird/suspect…
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
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…