Cant’ say on an official/legal/organisational perspective (@pavel?), but from a practical/technical perspective nothing has changed on our end. User privacy and anonymity is still our number one concern.
The tldr is basically Mozilla can do whatever it likes, we’ll keep ripping out the bad parts and shipping a private web browser to the best of our ability.
Disabling User-Hostile Functionality
We continue to disable telemetry, experiments, sponsored-links, parental control, content-analysis, and other various user-hostile ‘features’ at build-time if possible and at runtime otherwise. However, I should note this is not always an easy/trivial task; Mozilla the organisation doesn’t really prioritise making doing such things an easy task though the devs are typically amiable to taking fixes upstream when we find and fix problems.
We try very hard to be transparent about what the browser is doing and to ensure that communications/connections are anonymous, any information we collect is strictly and obviously opt-in (e.g the user survey which shipped last week), and that the user can give informed and enthusiastic consent when required.
Fixing Things at Runtime
As an example, over the past year we have re-worked the technical implementation, design and user-communication in the Connection Assist feature in Tor Browser.
The majority of users have probably never seen this feature, as it is designed to only really surface if a user is failing to connect to the Tor network (i.e. if they are on a network which prevents tor access like in Iran or China). Previously, this system would automatically and transparently test your internet connection and fetch settings information from the rdsys backend (maintained by Tor’s anti-censorship team; hi @meskio 
).
This of course was not anonymous as the associated requests went over the clearnet, but it wasn’t ever really communicated to users that this out-of-band connection was happening, even though we knew it was harmless (i.e. there were no logs, the risk to the user was no different than the other initial connections made when bootstrapping, and the information gleaned from said connection was only used to determine what bridge settings were likely to work for the user). Regardless, we fixed it and we got rid of the internet connectivity test entirely and now use your operating systems own local APIs (where available) to determine if you are connected to the ‘internet’ (i.e. your network adapter is enabled and you have an IP). And, when we need to fetch settings using this out-of-band/non-tor connection, the user is informed ahead of time that their location will be used. See this issue for further background, information, and discussion:
Fixing things at Buildtime
We also generally prefer disabling user-hostile functionality at build-time rather than at runtime (e.g. via preference or flag) but this is not always possible.
For example, over this past release we (nearly) stubbed out the entire application-services library used in Firefox Android (and therefore Tor Browser Android). This library does a lot of things related to interacting with Mozilla’s backend (e.g. telemetry, Firefox Accounts/Sync, pocket, etc), but fortunately we were able to develop some tooling which kept the API surface but turned most of its implementation into no-ops (we had to bring some of it back so bookmarks would work; don’t ask, hopefully we can fix this in the future). This saved us a few megabytes in the final APK we ship and just removed entire privacy-hostile subsystems which had previously only been disabled at runtime.
Anyway, you can read more about our design+development philosophy in the Tor Browser design doc:
How you can help!
And a final point here is that we (the apps team) don’t want to collect telemetry, analytics, engagement and other such info about our users and we definitely don’t want to accidentally send data about our users to 3rd parties. But, we are a relatively small team (8 developers plus myself) without the luxury of making our own development timelines (i.e. we’re basically tied to Mozilla at the hip when it comes to releases).
Each (northern hemisphere) summer, we triage all of the issues resolved by Mozilla’s hundreds of engineers since the previous ESR release which represents around 10 to 12 Firefox releases (depending on the year). Each release typically has between 1000 to 1500 issues which we go through and flag for further review to determine if we need to write a patch to disable some feature or modify it to private. Here’s our issue for Firefox 129 for example:
A big way people can help here is to evaluate our Alpha releases ( Tor Project | Download Tor Browser Alpha ) for such problems. Especially during the annual ESR transition while we are working on updating all our patches from the previous ESR to the next, updating our build system, fixing build-reproducibility problems, fixing front-end, fixing regressions in features, etc, etc.
If you find Tor Browser is talking to something it shouldn’t, file a bug and we will prioritise fixing it! We really do actually care about this stuff!
EDIT: there’s actually still some string updates needed in the connect-assist example to fully inform users of what the later stages of connect-assist are doing re the rdsys connection, but the technical/backend work is complete.