The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-12-15T18:18:46Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40253`extensions.allowPrivateBrowsingByDefault` will be removed2021-12-15T18:18:46Zemyb`extensions.allowPrivateBrowsingByDefault` will be removedThe Mozilla team is going to remove `extensions.allowPrivateBrowsingByDefault`. This setting is `true` in Tor Browser and `false` in vanilla Firefox.
Will this cause problems? 💣
See [Mozilla's issue](https://bugzilla.mozilla.org/show_b...The Mozilla team is going to remove `extensions.allowPrivateBrowsingByDefault`. This setting is `true` in Tor Browser and `false` in vanilla Firefox.
Will this cause problems? 💣
See [Mozilla's issue](https://bugzilla.mozilla.org/show_bug.cgi?id=1661517).Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/40009Update Signing section of ReleaseProcess documentation2022-01-14T17:03:36ZMatthew FinkelUpdate Signing section of ReleaseProcess documentationLike #40007, except for the signing parts.Like #40007, except for the signing parts.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40221Adapt nightly update URL2022-07-09T03:56:21ZGeorg KoppenAdapt nightly update URLWe patch the nightly update URL in `tor-browser-build` ad-hoc but we should move that out of `tor-browser-build` into a proper `tor-browser` patch.We patch the nightly update URL in `tor-browser-build` ad-hoc but we should move that out of `tor-browser-build` into a proper `tor-browser` patch.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40220Make sure tracker cookie purging is disabled2022-11-23T16:28:54ZAlex CatarineuMake sure tracker cookie purging is disabledThis was enabled in 84, and uplifted to 83 (https://bugzilla.mozilla.org/show_bug.cgi?id=1675596). We should probably disable that pref, even though in `GeckoView` we may be setting it to `false` already via `ContentBlocking.java`.This was enabled in 84, and uplifted to 83 (https://bugzilla.mozilla.org/show_bug.cgi?id=1675596). We should probably disable that pref, even though in `GeckoView` we may be setting it to `false` already via `ContentBlocking.java`.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40191Language not spoofed for en-CA and en-UK2021-08-04T19:46:37ZAlex CatarineuLanguage not spoofed for en-CA and en-UKIf a user installs an en-US tor-browser and then changes it to `English (Canada)` or `English (United Kingdom)` then neither the "locale spoofing prompt" is shown nor `Accept-Language` is spoofed (e.g. for Canada it's `en-CA,en-US;q=0.7,...If a user installs an en-US tor-browser and then changes it to `English (Canada)` or `English (United Kingdom)` then neither the "locale spoofing prompt" is shown nor `Accept-Language` is spoofed (e.g. for Canada it's `en-CA,en-US;q=0.7,en;q=0.3`). The prompt is not shown because of https://searchfox.org/mozilla-central/source/toolkit/components/resistfingerprinting/RFPHelper.jsm#196. Besides, given `javascript.use_us_english_locale=true` will not be set, I guess the non-spoofed locale will also be accessible via some JS APIs.
I'm not sure about the right solution, though. Should we show the spoofing prompt for these cases too? Or should we always spoof these two cases by default?Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40184Consider setting pref widget.disable-native-theme-for-content = true2023-05-22T12:02:39ZAlex CatarineuConsider setting pref widget.disable-native-theme-for-content = trueI have not done a lot of testing, but this may help solving issues like #22137.I have not done a lot of testing, but this may help solving issues like #22137.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40170Decide how we should notify users that their OS won't be supported in the nea...2021-12-07T10:14:55ZMatthew FinkelDecide how we should notify users that their OS won't be supported in the near futureImmediately, we have:
- [x] #40049
- [x] #40136
We'll have more in the future, so we could create a more general plan now.Immediately, we have:
- [x] #40049
- [x] #40136
We'll have more in the future, so we could create a more general plan now.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40159Drop plugin support2021-11-02T20:44:09ZPassword is "Cypherpunks Write Code" without quotescypherpunks@mailinator.comDrop plugin supportNot a duplicate of #19508, just drop plugin support.
Flash will die in the end of 2020 but it because it reveals user IP, it should never be used on Tor Browser.
Other plugins are already dead.Not a duplicate of #19508, just drop plugin support.
Flash will die in the end of 2020 but it because it reveals user IP, it should never be used on Tor Browser.
Other plugins are already dead.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40136Think about ways to inform CentOS 6 users about incompatible 10.5 update2021-12-07T10:13:26ZGeorg KoppenThink about ways to inform CentOS 6 users about incompatible 10.5 updateThe 10.0 series is the last one with support for CentOS 6 as this is EOL
Nov 2020. We should think about ways to not just break Tor Browser for
CentOS 6 users that would get the auto-update to 10.5. I am not sure
whether that's possible ...The 10.0 series is the last one with support for CentOS 6 as this is EOL
Nov 2020. We should think about ways to not just break Tor Browser for
CentOS 6 users that would get the auto-update to 10.5. I am not sure
whether that's possible at all, but if so that would be preferable than
to just leave them with an unusable Tor Browser.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40070Use Tor Browser 10.5 as a watershed update2021-12-07T10:15:37ZMatthew FinkelUse Tor Browser 10.5 as a watershed updateIn #40042 @mcs raised the question about whether we need a watershed update before migrating to 78esr. We decided that wasn't needed, but we may want a watershed update for Tor Browser that would allow simplifying some of our implementat...In #40042 @mcs raised the question about whether we need a watershed update before migrating to 78esr. We decided that wasn't needed, but we may want a watershed update for Tor Browser that would allow simplifying some of our implementations.
Some of the code areas that could be simplified described in that ticket. Let's continue investigating it here, and we should create individual tickets for each component that needs changes.
- [x] #40042
- [x] tor-launcher#28044
- [x] #40137
(I'm not sure how we can best document this, so I'm beginning with ticket numbers)Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/33521Check if RecommendedTBBVersions is still used2022-02-11T08:01:03ZboklmCheck if RecommendedTBBVersions is still usedAs part of the release process, we are updating RecommendedTBBVersions to put the new versions in it.
However according to GeKo, at least in the alpha, RecommendedTBBVersions is not used anymore. If that is not used in the stable relea...As part of the release process, we are updating RecommendedTBBVersions to put the new versions in it.
However according to GeKo, at least in the alpha, RecommendedTBBVersions is not used anymore. If that is not used in the stable release too, then we should remove that step from the release process.Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/android-components/-/issues/34324Must Audit Components for ESR91 Tor Browser2022-06-27T21:07:56ZMatthew FinkelMust Audit Components for ESR91 Tor BrowserComponents we must audit.
- [ ] [Audit mozilla_browser_icons](android-components#34323)
- [ ] [Audit mozilla_browser_state](android-components#34325)
- [ ] [Audit mozilla_browser_storage_sync](android-components#34326)
- [ ] [Audi...Components we must audit.
- [ ] [Audit mozilla_browser_icons](android-components#34323)
- [ ] [Audit mozilla_browser_state](android-components#34325)
- [ ] [Audit mozilla_browser_storage_sync](android-components#34326)
- [ ] [Audit mozilla_concept_sync](android-components#34327)
- [ ] [Audit mozilla_feature_qr](android-components#34328)
- [ ] [Audit mozilla_feature_app_links](android-components#34329)
- [ ] [Audit mozilla_feature_intent](android-components#34330)
- [ ] [Audit mozilla_feature_share](android-components#34331)
- [ ] [Audit mozilla_feature_accounts_push](android-components#34332)
- [ ] [Audit mozilla_feature_pwa](android-components#34333)
- [ ] [Audit mozilla_feature_webcompat](android-components#34334)
- [ ] [Audit mozilla_service_sync_logins](android-components#34335)
- [ ] [Audit mozilla_service_firefox_accounts](android-components#34336)
- [ ] [Audit mozilla_service_location](android-components#34337)
- [ ] [Audit mozilla_support_migration](android-components#34339)
- [ ] [Audit mozilla_lib_push_firebase](android-components#34340)
- [ ] [Audit mozilla_lib_dataprotect](android-components#34341)
- [ ] [Audit androidx_biometric](android-components#34342)
See:
https://gitlab.torproject.org/tpo/applications/fenix/-/issues/33939#note_2605622Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/network-health/metrics/onionoo/-/issues/13562Add more detailed logging to backend and frontend components2021-12-17T18:08:56ZiwakehAdd more detailed logging to backend and frontend componentsDerive new log messages (warning/error/info) from the current statistics log statements.
This entails adding new log statements to 'ResourceServlet' and 'core.Main'
(see parent issue comment 7 for details).Derive new log messages (warning/error/info) from the current statistics log statements.
This entails adding new log statements to 'ResourceServlet' and 'core.Main'
(see parent issue comment 7 for details).Metrics OKRs 2021https://gitlab.torproject.org/tpo/network-health/metrics/library/-/issues/16225Unify exception/error handling in metrics-lib2021-12-17T19:10:50ZKarsten LoesingUnify exception/error handling in metrics-libThere are now four different descriptor sources in metrics-lib: `DescriptorParser`, `DescriptorReader`, `DescriptorCollector`, and `DescriptorDownloader`.
We should think about unifying how we're handling exceptions and errors and telli...There are now four different descriptor sources in metrics-lib: `DescriptorParser`, `DescriptorReader`, `DescriptorCollector`, and `DescriptorDownloader`.
We should think about unifying how we're handling exceptions and errors and telling the user about them. These thoughts should include whether or not to log exceptions and errors, though just doing that is probably not sufficient.
Let's go through the interfaces one by one:
```
public interface DescriptorParser {
public List<Descriptor> parseDescriptors(byte[] rawDescriptorBytes,
String fileName, boolean failUnrecognizedDescriptorLines)
throws DescriptorParseException;
}
```
The (slightly modified, as compared to current master) `parseDescriptors` method handles a single file and throws an exception whenever something goes wrong. That works quite well, because that method blocks the caller, so they can easily wrap the call inside a `try/catch` block.
That's somewhat different in the next interface:
```
public interface DescriptorCollector {
public void collectRemoteFiles(String collecTorBaseUrl,
String[] remoteDirectories, long minLastModified,
File localDirectory, boolean deleteExtraneousLocalFiles);
}
```
This method (which we should have called `collectDescriptors`, in retrospect) blocks the caller, too, but it's unclear whether it should abort its operation when it hits the first exception. Right now it's rather silent about problems and only prints stack traces to `System.err`. But that doesn't enable the caller to handle problems, neither. At least the method makes sure that it doesn't delete extraneous local files that might still exist remotely in case of an error.
The next interface is trickier:
```
public interface DescriptorReader {
public Iterator<Descriptor> readDescriptors(File[] directories,
File[] tarballs, SortedMap<String, Long> excludeFiles,
boolean failUnrecognizedDescriptorLines, int maxDescriptorsInQueue);
}
```
Note that this interface does not yet exist, but it's what I could imagine doing to simplify the current interface and make it more similar to the `DescriptorCollector` interface. I could also imagine overloading this method.
The idea here is that the map passed in `excludeFiles` would be updated while reading descriptors, so that the caller could use that to update a local history file. (This would be documented, of course.)
However, it's unclear how we would handle problems at all here. What we _could_ do is extend the implementation of the returned `Iterator<Descriptor>` to return a (runtime) exception whenever there was a problem reading the next descriptor that would be added next. Or maybe we should write our own `Iterator`-like interface for returning descriptors and have its `hasNextDescriptor()` and `nextDescriptor()` methods throw `DescriptorParseException`.
By the way, the current `DescriptorReader` interface has a `getExceptions()` method in the additional `DescriptorFile` interface that is returned instead of `Descriptor`. But that's something I'd like to get rid of, too. I also don't expect many users to look at those exceptions.
The last interface is the mostly dysfunctional `DescriptorDownloader` interface. I could imagine that we handle exceptions/errors there similar to `DescriptorReader`. Or we throw out that class, because it's only used by CollecTor, and generalizing its functionality might take more effort than writing it cleanly as part of CollecTor.
Thinking about the future, we might want to add another interface `DescriptorWriter`, and we should think about ways to handle exceptions/errors there, too.
There, I mostly sketched out the problem here, without having good solutions. But maybe we can come up with good answers in this discussion?Metrics OKRs 2021https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40623change terminology on bridges2023-02-06T15:13:28ZGabagaba@torproject.orgchange terminology on bridgesChange the terminology for bridges anywhere in the UI:
- [ ] default bridges -> built-in bridges
- [ ] private bridges -> secret bridges
- [ ] public bridges -> distributed bridgesChange the terminology for bridges anywhere in the UI:
- [ ] default bridges -> built-in bridges
- [ ] private bridges -> secret bridges
- [ ] public bridges -> distributed bridgesSponsor 30 - Objective 2.2https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34345"Don't Bootstrap" Startup Mode2021-10-21T17:39:13ZMatthew Finkel"Don't Bootstrap" Startup ModeTor Browser needs a better user experience at start-up, and automatically bootstrapping and doing "Smart Things" in the background is the next stage in Tor Browser's evolution. But users should be able to launch Tor Browser and tell it n...Tor Browser needs a better user experience at start-up, and automatically bootstrapping and doing "Smart Things" in the background is the next stage in Tor Browser's evolution. But users should be able to launch Tor Browser and tell it not to bootstrap (before it starts bootstrapping).
Roger and I had some ideas including:
- Add a context menu option for launching but not bootstrap
- Add a key combination (like pressing spacebar) and Tor Browser what that means
- Tor Browser always waits 5 seconds before bootstrapping, and provides a "cancel" button
None of these are really good options, but maybe use this as a starting point and find a better option.
At the root of this is trying to solve three problems:
1. Tor Browser usability depends on tor bootstrapping seamlessly and hiding this detail from users
1. The current configuration may be dangerous after moving into a new environment
1. Tor Browser should have a start-up mode where Tor Browser doesn't send a single packet on the network before the user has the option of configuring tor
(Most likely) 99.9% of users only need (1), but we shouldn't ignore (2) and (3).Sponsor 30 - Objective 3.3richardrichardhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31875BridgeDB should consider a user's location2021-09-09T14:18:39ZPhilipp Winterphw@torproject.orgBridgeDB should consider a user's locationbridges.torproject.org knows the user's physical location and should consider it when returning bridges. For example, if somebody in country X asks for an obfsN bridge but BridgeDB knows that only obfsN+1 works in X (e.g., by consulting ...bridges.torproject.org knows the user's physical location and should consider it when returning bridges. For example, if somebody in country X asks for an obfsN bridge but BridgeDB knows that only obfsN+1 works in X (e.g., by consulting the result of tpo/community/outreach#28531), it should return obfsN+1.
Ideally, we would do this for all of BridgeDB's distribution mechanisms. We could also do it for email – if the user emailed bridges+CC@bridges.torproject.org. As I understand it, we cannot do it for moat because BridgeDB doesn't get to see the user's IP address in this case.Sponsor 30 - Objective 3.3meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/core/arti/-/issues/325Make CircMap:open_ent_count O(1)2022-02-17T16:31:08ZNick MathewsonMake CircMap:open_ent_count O(1)In open_ent_count in circmgr.rs, we have:
```
// TODO: We want to change this from O(n) back to O(1).
// Maybe we should have the CircMap keep track of
// the open-or-opening entries count.
```
On !273, @lyuyuan ...In open_ent_count in circmgr.rs, we have:
```
// TODO: We want to change this from O(n) back to O(1).
// Maybe we should have the CircMap keep track of
// the open-or-opening entries count.
```
On !273, @lyuyuan noted:
> While working on resolving this, I noticed the `CircMap::get_mut` method.
>
> ```
> pub(super) fn get_mut(&mut self, id: CircId) -> Option<&mut CircEnt>
> ```
> I figured to keep track of the open circs counter in all other methods but this one is a bit tricky. I guess one can change an entry from open/opening to destroy-sent (or vice versa) with the mutable reference returned, and the counter will be out of sync.
In order to fix that issue, we'll either need to remove `get_mut` and replace its users with specific transition functions, or we'll need to have it return some kind of a smart pointer which, on drop, updates the count.Arti 0.1.0 release: Okay for experimental embeddinghttps://gitlab.torproject.org/tpo/core/arti/-/issues/324Use an atomic for the value of channels' unused-since timestamps2022-02-09T15:04:42ZNick MathewsonUse an atomic for the value of channels' unused-since timestampsSee discussion on !273: We'd like to have the `unused_since` field in `ChannelDetails` be atomic, or implemented in terms of an atomic.
On that MR I suggested:
> I'd define a new `OptTimestamp` type, based on Timestamp, except with t...See discussion on !273: We'd like to have the `unused_since` field in `ChannelDetails` be atomic, or implemented in terms of an atomic.
On that MR I suggested:
> I'd define a new `OptTimestamp` type, based on Timestamp, except with the value 0 representing None. It would behave semantically like `Option<Timestamp>`, but internally it would just be an AtomicU64. Then I'd give it both `update()` and `clear()` functions to change its state, along with the other accessors that the functions `update_disused_since` and `duration_unused` would need.Arti 0.1.0 release: Okay for experimental embeddingyuanyuanhttps://gitlab.torproject.org/tpo/core/arti/-/issues/320Drop for TorClient flushes state too frequently.2022-02-16T13:59:39ZNick MathewsonDrop for TorClient flushes state too frequently.Try making a connection through arti as a proxy. Every time you do so, you'll see:
```
2022-02-03T18:49:51.418608Z INFO arti_client::client: Flushed persistent state at exit.
```
This is happening because of how we've refactored our c...Try making a connection through arti as a proxy. Every time you do so, you'll see:
```
2022-02-03T18:49:51.418608Z INFO arti_client::client: Flushed persistent state at exit.
```
This is happening because of how we've refactored our code. Long ago, we handed out Arc<TorClient> instances, and dropping a TorClient instance only happened when we were closing it completely. But now that we have `isolated_client` and `clone_with_prefs`, we're using `TorClient` as handle object, and dropping them all the time.
We should change the code so that we only trigger this kind of flush for the persistent state when the last shared part of the TorClient is getting dropped.Arti 0.1.0 release: Okay for experimental embedding