If a website could modify browser configuration, this would be an egregious breach of security.
As someone who actually has built Firefox (both for desktop and for Android), my understanding is that these external services often require API keys, which are specified at compile time. It is not possible for a user to add these keys via about:config or some other method, without patching or recompiling the binary.
If a website is capable of doing any of those things, the browser is deeply insecure, or deliberately backdoored. Either of those is an extraordinary claim that needs evidence, or else it is FUD. Actually, I would like to see any evidence at all that these “trackers” are actively sending data. “Evidence” in this case is source code or packet captures, not Exodus reports. I need evidence that this is actually happening.
Of course, as a freeness issue, Tor browser should not be shipping any proprietary bits at all. Disabling them is a fine temporary measure, but now that F-Droid has done the work to actually remove them, Tor browser should adopt their patches.
This is a particular concern, expecially when the upstream code changes. Even if you have verified that all trackers are disabled in a current build, it is easy for some of them to become partially activated in updates in ways that only exhaustive testing would be sure to catch.
I personally have come to the conclusion that no amount of laws will ever solve this problem. The only answer I see are technical solutions (like disabling JavaScript, etc.) that I can enact on my web browser that ensures that I never send tracking information to the web server. Every other proposed solution boils down to some form of “just trust us” which isn’t something I think I will ever do with random websites.
In addition, I would hope that we can have a vigorous discussion about the facts of the issue without resorting to personal attacks.
There are tickets which have remained open for years, if the issue is brought to their attention via ticket or blog comment it is still seen and acknowledged by the same people. They’ve known about this since 2018 but didn’t do anything due to the Guardian Project ≥ Tor handover which has long since been settled. I can’t think of any good reason for them not to fully remove.
I appreciate your input, especially as someone with a history of development in this particular aspect of app coding. I accept if I was wrong and anything I’ve said overzealously has only been for the betterment of anyone who hasn’t checked all bases. I did see in articles that it’s possible for a malicious exit node to install malware onto a system (https://www.securityweek.com/onionduke-apt-malware-distributed-malicious-tor-exit-node) and also redirect users to a non HTTPS version of a website or even to a different page entirely (Russian intelligence 'targets Tor anonymous browser' - BBC News) which isn’t good considering 27% of the entire Tor exit node range was found to be acting maliciously, luckily they were targeting cryptocurrency rather than data, although that collective 27% could probably be used to perform a fair number of correlation attacks (https://howtoremove.guide/hacker-in-control-of-tor-network-exit-nodes/amp/).
For these reasons it’s not unfair to assume that leveraging these trackers has been on the minds of most malicious operators for a while and if they were to succeed then we would only know afterwards.
I believe the app still contains all known trackers and telemetry? I know there was a difference in numbers between the F-Droid version and Google Play version but they still had trackers regardless. The only changes I can see is them removing whatever “gombile” is (Remove unused gombile project (#40323) · Issues · The Tor Project / Applications / tor-browser-build · GitLab) it’s a shame they couldn’t have spent 3 minutes removing other codes too…
Again, I am willing to accept if I was wrong. I don’t have the technical knowledge or ability to test for such evidence. If anybody is able to run this in a VM through traffic analysis software like Wireshark (if that even still exists) then I would be grateful for the results.
Yes it is certainly a reason for concern, hopefully the matter can be put to rest either through user testing or Tor implementation.
These trackers are highly integrated into the upstream Firefox code and removing them would break a lot of things. Because Tor is a rolling fork of Firefox, all this work would need to be replicated with each release, making it almost unfeasible with the current manpower. The best they can do is attempt to disable the code, so that every time it runs it exits before it sends any information. However, as I pointed out, it is very hard to do this in such a way that one can guarantee that is what always happens.
Case in point, see the following bug report originally filed against Privacy Browser that appears to be an issue with a modification that LineageOS has made to Android’s Autofill service that causes it to send a ping (and hence, tracking information) to Google even when the user has attempted to disable the Autofill service.
It is easy to make mistakes like this when not anticipating all code paths. It is even harder for the Guardian Project to anticipate how future changes to seemingly unrelated sections of Firefox might bypass disablement of trackers that they had fully tested and verified in previous releases.
So does that mean all Tor on Android users will have to just remain hopeful that nothing leaks unexpectedly? If so then it seems like a terrible state of affairs which should never have been allowed to happen in the first place. Mozilla didn’t use these trackers in the past but now obviously their beliefs and interests have changed. I did submit a comment to the blog suggesting they abandon Mozilla and start building all versions around Brave Browser which has plenty of good safety/privacy features along with no trackers or telemetry (Tor themselves still haven’t commented on the telemetry conditions, just the trackers) Brave on desktop implemented Tor traffic but I believe they ballsed it up somehow also. If Tor and Brave worked together as a joint effort and discontinue the Mozilla builds then perhaps things could be saved. It’s a long shot considering they didn’t even approve the comment but it is annoying to know I financially contributed to the development and continuation only to be stuck with this.
Earlier in this conversation I asked if the Guardian Project had any plans to eventually remove all the trackers from their source code. I am a patient man in these regards if I know that eventually the situation will be resolved and that the parties are making reasonable attempts to make progress in the interim. However, it appears that they currently have no plans to ever fully remove these trackers.
Regarding rebuilding the Tor browser on Chromium (Brave) instead of Firefox, Chromium has its own upstream problems that make a rolling fork unideal. See, for example, the following.
It certainly isn’t looking good then. Part of the reasons I donated was in hope of improvement being made to the app but obviously that was a misguided view in relation to their plans. Would I be correct in assuming these tracking and telemetry issues don’t occur in other versions for other operating systems? If so then the only feasible option is to use a desktop variant until something leaks in the app and more pressure is applied for removal. They did say then would look into removal if leaks were proven but look into is obviously a very vague term.
I would still also be interested in seeing results of packet analysis from this app so we can see at surface level if anything is leaking
Seeing as how a number of these trackers were built by Mozilla (the attached screenshot shows that there are 189 separate instances of mozilla.telemetry.glean included in the code) I would assume that similar code exists in the desktop version.
You can see the scripts and patches that are used to build Fennec F-Droid here. fenix-liberate.patch is the patch that adds the stubs for proprietary libraries (firebase, adjust). As noted elsewhere, Exodus reports false positives on these stubs. Why use stubs, then? So that application code that uses these libraries does not have to be modified.
This in prebuild.sh is where crash reporting and telemetry are disabled:
# Disable crash reporting
sed -i -e '/CRASH_REPORTING/s/true/false/' app/build.gradle
# Disable MetricController
sed -i -e '/TELEMETRY/s/true/false/' app/build.gradle
Why disable instead of remove? Unlike the Firebase libraries, the telemetry code is free software so it is okay from a freeness perspective. Removing it entirely would require calling application code to be patched out, so if anything it would be stubbed out like Firebase is, but this would still cause Exodus to report false positives, so there will still be complaints from people. As I have said, Exodus is not an anti-spyware tool and Exodus reports are not proof of malicious activity.
AFAIK Fennec still makes a handful of calls to Mozilla services (off the top of my head, it has to do so for add-on support - add-ons are automatically checked for updates and I don’t think this can be disabled or even manually done. I am not a fan of automatic updates). I suppose you could call that “tracking” (realistically any network connection could be used to track users).
Thank you for your explanation, it’s been one of the most informative comment thus far in my own opinion. I have taken a look at the links you provided and they have provided some reassurance in comparison to when I posted about it being dead. I am far from knowledgeable when it comes to coding but looking at the fenix patch I have noticed one thing I’d like further clarification on if possible. On line 216 to 217 there is this code and it says the page was modified 5 days ago?
public static Info getAdvertisingIdInfo(Context context) {
return new Info();
What exactly does an Advertising ID consist of and isn’t any form of ID a bad thing for Tor? The fact is literally says Get advertising ID info seems a bit sketchy, although I could be making something over nothing.
Since the telemetry code is disabled I assume it’s not important what code the telemetry uses?
Do you happen to have the ability of network analyzing the data from this app so we have undeniable visual evidence that all disabilities are working correctly without any leaks or any Mozilla implemented changes which could indirectly lead to an identification? I know it’s a lot to ask but as I said earlier you do seem to have the most knowledge about this topic.
That doesn’t mean anything, that’s not for Android specific installations and plenty of people natively trust Tor without a second thought, hundreds of thousands have been connected to the network during countless attacks, do you think they all know? Many only realize once their door gets blown off at 5am
However, note that this library is stubbed out. If you look at the full class definition here (lines 251 - 265), you will notice that the advertising ID that is returned by this stub is an empty string (in other words, useless for uniquely identifying anything).
public class AdvertisingIdClient {
public static final class Info {
public String getId() {
return "";
}
}
public static Info getAdvertisingIdInfo(Context context) {
return new Info();
}
}
Note that I am talking about Fennec F-Droid here, not Tor Browser. As far as I am aware Tor Browser is shipping the actual proprietary Google library but with its functionality disabled. I suggested that Tor Browser should adopt the patches from Fennec F-Droid, for freedom’s sake.
If I can make time, sure. I would also be interested in what connections Fennec F-Droid makes (I have a vague idea but I don’t use Fennec, or indeed Android at all, regularly these days, so my knowledge may be out of date)
So the Tor Browser on F-Droid does have potentially sketchy stuff but it’s still safe to use? Forgive my brainlet level understanding. How Fennec effects F-Droid and how F-Droid effects Tor is just getting slightly confusing. I would post a comment to their blog about changing default library but it will only be ignored. Thank you for what you’ve shown us, anything to make truth accessible and understandable is of benefit to us all.
Edit: From the F-Droid site it says Fennec has telemetry and proprietary bits removed but trackers for Mozilla and Google remain active? Doesn’t sound good.
For further code analysis it’s probably best if we work off the current Tor for Android build as it’s what people are likely to be using.
Why is F-Droid so slow with updating repositories? The latest version they have listed is 10.0.18(89.1.1-release) yet the newest 10.5.3(90.1.1-release) has been out for over a week now? The update includes important security fixes so shouldn’t be ignored.
