The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-09T14:30:21Zhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/226Is optimistic data allowed on onion services? And should it be?2023-11-09T14:30:21ZNick MathewsonIs optimistic data allowed on onion services? And should it be?While working on Arti, I've noticed that optimistic data on onion services might or might not be officially allowed. On the one hand, it will improve performance, since the client won't have to wait for a `CONNECTED` in order to send da...While working on Arti, I've noticed that optimistic data on onion services might or might not be officially allowed. On the one hand, it will improve performance, since the client won't have to wait for a `CONNECTED` in order to send data. On the other hand, it smells like a possible side channel vector (q.v. proposal 344) if the client chooses a `BEGIN` message that they know will provoke an `END` but not cause the circuit to close.
cc @mikeperry: what do you think?Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/community/l10n/-/issues/40123Retire HTTPS_Everywhere translations2023-12-11T11:23:32ZemmapeelRetire HTTPS_Everywhere translationsFrom their website:
##Update on HTTPS Everywhere
⚠️This project is no longer being maintained or updated. Please uninstall and direct users to the advice below to switch to HTTPS by default natively.
You no longer need HTTPS Everywhe...From their website:
##Update on HTTPS Everywhere
⚠️This project is no longer being maintained or updated. Please uninstall and direct users to the advice below to switch to HTTPS by default natively.
You no longer need HTTPS Everywhere to set HTTPS by default! Major browsers now offer native support for an HTTPS only mode. Find out how to turn it on here.
This extension will be sunset by January 2023.
We need to retire the component, and we can use the opportunity to update the Howto retire a translation: https://gitlab.torproject.org/tpo/community/l10n/-/wikis/L10n-Coordinator#how-to-retire-a-localization-resourceemmapeelemmapeelhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40184Create new Debian backports release 1.9.02024-02-05T09:03:05ZjugaCreate new Debian backports release 1.9.0sbws: 1.9.x-finaljugajugahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42180The circuit display is not shown when the bridge line doesn't contain the nod...2023-10-17T16:14:17ZPier Angelo VendrameThe circuit display is not shown when the bridge line doesn't contain the node fingerprintAs a sort of known bug, we cannot do much to associate fingerprints to bridges.
As a workaround, we use the bridge line to associate the address to the fingerprint.
But if the user don't supply it, we cannot recognize they're using a br...As a sort of known bug, we cannot do much to associate fingerprints to bridges.
As a workaround, we use the bridge line to associate the address to the fingerprint.
But if the user don't supply it, we cannot recognize they're using a bridge and query the control port for the IP address as it was a normal relay.
The control port answers with an error that as ultimate consequence makes the circuit display disappear for that page.
This is easily checkable by requesting a vanilla bridge on https://bridges.torproject.org/, and then copying only the IP address and port without the fingerprint.
I discovered that we can at least get bridge fingerprints with `GETINFO downloads/bridge/bridges`. E.g.:
```
GETINFO downloads/bridge/bridges
250+downloads/bridge/bridges=
8838024498816A039FCBBAB14E6F40A0843051FA
2B280B23E1107BB62ABFC40DDCC8824814F80A72
.
250 OK
GETINFO downloads/bridge/bridges
551 We don't seem to be using bridges
```
That would be helpful, because at least we'd have a way to be sure we are dealing with a bridge. I'd say creating a set of bridges would be quite cheap to do every time in the query for the information about a node.
In some cases we can also get IP addresses with `GETINFO ns/purpose/bridge`, in a format similar to the one for normal relays, e.g.:
```
r Unnamed fingerprint-in-base64 something-else some-date ipv4 port 0
a ipv6:port
s Running
w Bandwidth=...
p reject 1-65535
```
However, this includes many bridges, there isn't a way to filter only on the fingerprint we want to know ~~, but what's worse is that it might not contain all (e.g., Snowflake wasn't included in my tests)~~ (Snowflake isn't working in my dev build for some reason :shrug:).
Anyway, I wonder if we should add an "Unknown" item in the circuit display when we cannot get the information in any way, and display the other nodes.
The problem was spotted by [NoOp21](https://forum.torproject.org/t/new-release-tor-browser-13-0/9703/18) in the 13.0 release thread.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42178New Tor circuit for this site (hamburger menu) is always visible/clickable2023-10-16T21:16:11ZPier Angelo VendrameNew Tor circuit for this site (hamburger menu) is always visible/clickableWe always show the "New Tor circuit for this site" in the hamburger menu.
Would it make sense to hide it for things such as about pages?
Before taking a decision, we should consider that maybe it's the only way to change the catchall c...We always show the "New Tor circuit for this site" in the hamburger menu.
Would it make sense to hide it for things such as about pages?
Before taking a decision, we should consider that maybe it's the only way to change the catchall circuit.https://gitlab.torproject.org/tpo/core/torspec/-/issues/225Overlap in `dir-spec` grammar2023-10-16T16:21:22ZEmil EnglerOverlap in `dir-spec` grammarHave a look at the following lines in the dir-spec grammar:
```
KeywordLine ::= Keyword (WS Argument)* NL
Argument := ArgumentChar+
ArgumentChar ::= any graphical printing ASCII character.
```
The `WS` token in `KeywordLine` seems to be...Have a look at the following lines in the dir-spec grammar:
```
KeywordLine ::= Keyword (WS Argument)* NL
Argument := ArgumentChar+
ArgumentChar ::= any graphical printing ASCII character.
```
The `WS` token in `KeywordLine` seems to be wrong considering that `ArgumentChar` may contain `WS` as well (ASCII space is usually considered a printable character). This confuses parsers following this particular grammar.https://gitlab.torproject.org/tpo/core/arti/-/issues/1060Against precise imports and unused imports warnings2024-03-04T16:33:17ZIan Jacksoniwj@torproject.orgAgainst precise imports and unused imports warningsI am frequently troubled by unused imports warnings. Often while developing I add temporary commits that add `#![allow(dead_code)] // XXXX` to random other crates. (Most recently for the one fixed in 399d4c8d27f1da600851d10fb1a8482b818...I am frequently troubled by unused imports warnings. Often while developing I add temporary commits that add `#![allow(dead_code)] // XXXX` to random other crates. (Most recently for the one fixed in 399d4c8d27f1da600851d10fb1a8482b818b0fbd and another in `tor-proto`.)
In general, it is a lot of effort to maintain the property that every element of every `use` statement is properly decorated with precisely the right set of `cfg` options. I think this is makework.
The only benefit of this approach is that we save very small amounts of compiler time: the compiler doesn't need to add the unused entries to its symbol tables.
Also, more generally, we are spending too much time editing (and sometimes fixing up conflicts in) imports lists. Maintaining precise import lists leads to churn as code develops.
### Option 1. Preludes
My preferred solution is that we should have an internal prelude for (approximately) each crate. Every module in the crate would `use crate::prelude::*`. The prelude would have an allow for unused imports.
The advantage would be that every module in a crate would have the same namespace (or, at least, a very similar one). There would be less `use` overall. When elements did need to be conditional because they're only available in certain configurations, the `cfg` stuff would appear once in each crate rather than once in each module.
The downside is that the automatic `use`-adding suggestions would be wrong, since they would add the imports to the individual modules, not the prelude. In !622 I volunteered to do the necessary cleanup myself on an ad-hoc as-and-when basis.
I don't think this is a particularly novel approach (even in the Rust community, despite the lack of formal tooling support).
CC @nickm @gabi-250, and @ahf since this was very controversial last time and I think the discussion might benefit from some oversight.
### Option 2. `allow`
If crate-specific preludes remain too controversial, I propose that we `#![allow(unused_imports)]` everywhere.
We wouldn't want ever-growing import lists that just accumulated cruft, but we could periodically (a few times a year) run a `cargo check --all-* --workspace` to identify unused imports and prune them.
### Option 3. Conditional `allow`
If even that is too controversial, I suggest we use a `cfg_attr(allow)` which disables the unused imports warnings unless *all* the crate's features are enabled.Ian Jacksoniwj@torproject.orgIan Jacksoniwj@torproject.orghttps://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/247fixup New (Private) Window2024-01-10T07:30:30ZThorinfixup New (Private) Windowsee https://github.com/mullvad/mullvad-browser/issues/162#issuecomment-1759281972
> - MB shouldn't have `New Identity` (menubar or hamburger)
> - MB at least on mac has `New Private Window` (menubar) instead of `New Window`
> - MB on ...see https://github.com/mullvad/mullvad-browser/issues/162#issuecomment-1759281972
> - MB shouldn't have `New Identity` (menubar or hamburger)
> - MB at least on mac has `New Private Window` (menubar) instead of `New Window`
> - MB on windows has neither (menubar is default off on windows anyway)
> - can we check mac's hamburger menu
We should check TB is correct as wellma1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42168Crash on Debian Sid2023-11-08T20:06:01ZrichardCrash on Debian SidFrom IRC:
```
<peace_peace> How would you stop version 12.5.6 of TOR Browser from failing with...
<peace_peace> Bail out! Gtk:ERROR:../../../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon:
assertion failed (error == NULL): Failed to
l...From IRC:
```
<peace_peace> How would you stop version 12.5.6 of TOR Browser from failing with...
<peace_peace> Bail out! Gtk:ERROR:../../../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon:
assertion failed (error == NULL): Failed to
load /usr/share/icons/Adwaita/scalable/status/image-missing.svg: Unable to load image-loading
module: /usr/lib/i386-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: ./TorBrowser/Tor/libstdc++/libstdc++.so.6:
version `GLIBCXX_3.4.30' not found (required by /usr/lib/i386-linux-gnu/libicuuc.so.72)
<peace_peace> (gdk-pixbuf-error-quark, 5)
<peace_peace> ... when you ...
<peace_peace> 1.) right click on an image and
<peace_peace> 2.) scroll down the pop up menu to "Save Image As"
<peace_peace> ?
<richard> weird
<richard> looks like you need to update your glibcxx
<peace_peace> Yes, but, which Linux package contains glibcxx?
<peace_peace> Should the directory...
<peace_peace> .local/share/torbrowser/tbb/i686/tor-browser_en-US/Browser/
<peace_peace> have TWO copies of libstdc++.so.6 ?
<peace_peace> One in...
<peace_peace>
~/.local/share/torbrowser/tbb/i686/tor-browser_en-US/Browser/TorBrowser/Tor/libstdc++/libstdc++.so.6
<peace_peace> and a newer one in...
<richard> why do you have a .local/share/torbrowser folder?
<peace_peace> ~.local/share/torbrowser/tbb/i686/tor-browser_en-US/Browser/libstdc++/libstdc++.so.6
<peace_peace> richard, I'll check...
<peace_peace> richard, The folder ".local/share/torbrowser" is referred to by a package
named "torbrowser-launcher".
<richard> ah geez
<peace_peace> Please expound on "geez".
<richard> torbrowser-launcher
<richard> what version of debian are you on
<richard> fwiw the issue doesn't repro for me
<richard> in 12.5.6
<richard> so it sounds like your system libraries need to be update
<peace_peace> Franken-SID.
<peace_peace> A newer version of "torbrowser-launcher" is available.
<richard> that wouldn' matter
<richard> it's just a wrapper around downloading/deploying the browesr bundle
<richard> franken sid?
<richard> oh interesting
<richard> i think i get what's happening
<richard> well maybe
<richard> so we build+ship our own libstdc++ to handle running on older platforms
<richard> but it seems since your own sid (testing/unstable right?) gtk is pulling in libicuuc which
requires a *newer* version of libstdc++ than what we ship
<richard> which is def a weird one
<peace_peace> Thanks.
<richard> looks like we're building 3.4.28
<peace_peace> The computer has version 72.1-3 of the package named "libicu72".
<richard> can you open a bug on our gitlab
<richard> gitlab.torproject.org/tpo/applications/tor-browser
<richard> or something like that
<peace_peace> I searched /usr/lib/i386-linux-gnu/libicuuc.so.72* for version strings.
<peace_peace> I found...
<peace_peace> GLIBCXX_3.4, GLIBCXX_3.4.11 and GLIBCXX_3.4.30.
<richard> yeah that makes sense
<peace_peace> But no 3.4.28.
<richard> right our shipped libstdc++ has a max version string of 3.4.28
<richard> and libicuuc seems to require 3.4.30
<richard> so the browser loads our libraries and gtk, gtk uses our libstdc++, it loads libicuuc and
it tries to use functionality for a newer version of libstdc++
<peace_peace> Here's how I found the version strings...
<peace_peace> $ strings /usr/lib/i386-linux-gnu/libicuuc.so.72* | egrep GLIBCXX
<peace_peace> richard, Thank you for your thoughts.
<peace_peace> I need to go.
<richard> peace_peace: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
<richard> looks like we would need to upgrade to at least gcc 12.1.0
```
So from what I can surmise, GTK is loading a library that depends on a newer version of libstdc++ than we ship, resulting in a crash.
Can we upgrade the version of gcc we use since we ship libstdc++ with the browser?https://gitlab.torproject.org/tpo/core/onionmasq/-/issues/73Deal with failures to bootstrap more gracefully / introduce a timeout2024-03-27T17:31:10ZetaDeal with failures to bootstrap more gracefully / introduce a timeout@kwadronaut raises the example of seeing 'connecting' forever when trying to use snowflake (or another unsupported PT). We should definitely fail faster in this sort of case, given we'll be getting failures to build circuits etc. (in fac...@kwadronaut raises the example of seeing 'connecting' forever when trying to use snowflake (or another unsupported PT). We should definitely fail faster in this sort of case, given we'll be getting failures to build circuits etc. (in fact this is an arti bug), and we should probably have some form of overall timeout.VPN pre-alpha 06Micah Elizabeth ScottMicah Elizabeth Scotthttps://gitlab.torproject.org/tpo/core/torspec/-/issues/224spec says "pr" must appear exactly once in microdesc, but it does not appear ...2023-10-10T15:46:47Ztrinity-1686aspec says "pr" must appear exactly once in microdesc, but it does not appear in recent microdescs in collectorthe [dir-auth spec](https://gitlab.torproject.org/tpo/core/torspec/-/blob/0f16f7fc156a6354e86d529b31af483fb45f0b20/dir-spec.txt#L1806-1812) says:
```
"pr" SP Entries NL
[Exactly once.]
The "proto" element as specif...the [dir-auth spec](https://gitlab.torproject.org/tpo/core/torspec/-/blob/0f16f7fc156a6354e86d529b31af483fb45f0b20/dir-spec.txt#L1806-1812) says:
```
"pr" SP Entries NL
[Exactly once.]
The "proto" element as specified in section 2.1.1.
[Before Tor 0.4.5.1-alpha, this field was optional.]
```
but recent microdecriptors seems to all lack this value.
The router status entries only mark this field as `At most once`https://gitlab.torproject.org/tpo/community/l10n/-/issues/40119Update torlauncher translation setup2024-01-31T14:43:58ZemmapeelUpdate torlauncher translation setupTorlauncher's setup needs to be updated. The repository is now https://gitlab.torproject.org/tpo/applications/torbrowser-launcher and we need to add it to weblate.
We also need to know if we still need this other tor-launcher branches: ...Torlauncher's setup needs to be updated. The repository is now https://gitlab.torproject.org/tpo/applications/torbrowser-launcher and we need to add it to weblate.
We also need to know if we still need this other tor-launcher branches: https://gitlab.torproject.org/tpo/translation/-/branches?state=all&sort=updated_asc&search=launcher and if not, move them to the attic.emmapeelemmapeelhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42145System tor users won't be notified if the connection to the control port fails2023-10-11T21:15:41ZPier Angelo VendrameSystem tor users won't be notified if the connection to the control port failsIn #42129 we removed the "restart Tor" prompt when the browser doesn't start the Tor process.
In !812 we're adding a warning to use check.tpo in that case, which is independent from the control port connection.
A case remains uncovered...In #42129 we removed the "restart Tor" prompt when the browser doesn't start the Tor process.
In !812 we're adding a warning to use check.tpo in that case, which is independent from the control port connection.
A case remains uncovered: a user set the address of their system tor correctly, but they haven't set the proper settings for the control port.
An idea is adding another blocking prompt, just like the restart Tor one, but with another message (basically: "We couldn't connect to the control port. Please check your settings. Your proxy settings might be still valid, but you won't have the circuit display") and just the "OK" button (we can't do anything in that case).
However, some users might get annoyed by this, but I don't like the idea of adding a checkbox to ignore this error.
Another idea could be a non-blocking notification, like the one for the language.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42137Review UX of "Tor Browser Support" link in about:preferences.2023-09-29T19:59:27ZhenryReview UX of "Tor Browser Support" link in about:preferences.Copied from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41910#note_2941435
Currently, we have one link in "about:preferences" shown as
```
{ -brand-short-name } Support
```
in the bottom left corner of "about:p...Copied from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41910#note_2941435
Currently, we have one link in "about:preferences" shown as
```
{ -brand-short-name } Support
```
in the bottom left corner of "about:preferences". I.e. "Firefox Support" and "Tor Browser Support".
In firefox, the link goes to https://support.mozilla.org/en-US/kb/firefox-options-preferences-and-settings. I.e. SUMO page for "about:preferences".
In tor browser, the link goes to https://support.torproject.org/tbb/. I.e. the tor browser FAQs. See https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/32092.
In mullvad browser, the link goes to https://mullvad.net/en/help/tag/mullvad-browser/. See https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/177.
In addition, there is another link in "about:preferences" that goes to the same page for firefox, shown when you have an empty search result as
```
Sorry! There are no results in Settings for “some search term”.
Need help? Visit <a>{ -brand-short-name } Support</a>
```
However, I'm not sure `https://support.torproject.org/tbb/` is the best redirect for these contexts. I feel like the initial decisions in the linked issues were responding to the wording "Tor Browser Support" rather than the surrounding context or the original firefox SUMO page. In particular:
1. The tor project page doesn't help with understanding "about:preferences" like firefox does. Same applies to mullvad.
2. Depending on what the user is doing, or if they haven't bootstrapped yet, "about:manual" might be more useful.
So I wonder if it might make more sense to just design something more specific that works for tor browser (and mullvad browser), rather than just hijacking an existing firefox link.
/cc @donuts for some UX inputhttps://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/26Keep tags across family members in sync2024-01-16T13:50:05ZGeorg KoppenKeep tags across family members in syncWe got families included in our tagging process in #20, but we should make sure that the families stay in sync tag-wise. That is: between different tagging sessions family members might not be the same. If the family loses members then t...We got families included in our tagging process in #20, but we should make sure that the families stay in sync tag-wise. That is: between different tagging sessions family members might not be the same. If the family loses members then that's not a big deal. However, newly added relays should have all the tags their other family members have once I resume tagging relays at a later time.TagTor is completed for its scope in Sponsor 112https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42136Consider stripping `utm` parameters from mozilla links.2023-09-28T17:16:36ZhenryConsider stripping `utm` parameters from mozilla links.Split from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41910
Currently some mozilla links within base browser add some parameters to the url: "utm_source", "utm_medium" and "utm_content". See https://searchfox.or...Split from https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41910
Currently some mozilla links within base browser add some parameters to the url: "utm_source", "utm_medium" and "utm_content". See https://searchfox.org/mozilla-esr115/search?q=utm_content&path=&case=false®exp=false
In particular, this came up in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41910 because `moz-support-link` has a [mechanism to add these](https://searchfox.org/mozilla-esr115/rev/853578e651edd1a6be0400e9124ae735d8e7213c/toolkit/content/widgets/moz-support-link/moz-support-link.mjs#91,107-125).
A lot of these links are outside the tor browser UI (e.g. newtab and pocket). The only exceptions I found were in "about:addons", like the search url and the recommended badge link.
/cc @richard @pierovhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40964Create new Tor Browser gpg subkey2023-10-16T21:20:23ZboklmCreate new Tor Browser gpg subkeyAfter being extended by 5 months in #40957, the current Tor Browser gpg subkey will be expiring in some months. We should generate a new subkey and switch to it while the old one is still valid for a few months.After being extended by 5 months in #40957, the current Tor Browser gpg subkey will be expiring in some months. We should generate a new subkey and switch to it while the old one is still valid for a few months.boklmboklm2023-11-13https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/176run some experiments with CAPTCHAs2023-12-18T18:28:37Zmeskiomeskio@torproject.orgrun some experiments with CAPTCHAsAs we are planning to phase out CAPTCHAs (#173), can we run some experiments and see if they can be still effective?
We could either use the existing moat CAPTCHA API as we have some months until clients stop using it, or we could do it...As we are planning to phase out CAPTCHAs (#173), can we run some experiments and see if they can be still effective?
We could either use the existing moat CAPTCHA API as we have some months until clients stop using it, or we could do it in the HTTPS distributor as soon as we have migrated it to rdsys (#2).
There was a thread in the mailing list some years ago about this:
https://lists.torproject.org/pipermail/tor-dev/2021-July/014604.html
We should explore the space and see what better options for CAPTCHAs exist now a days.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42117Tor Bootstrap Log on Android becomes small2023-09-27T21:31:12ZPier Angelo VendrameTor Bootstrap Log on Android becomes smallI'm not sure of the STR, I think swiping left and right could help.
<details><summary>Screenshot</summary>
![Screenshot_20230920-173414](/uploads/5a11ba7505f431aa12c0d4bbee989b7e/Screenshot_20230920-173414.png)
</details>I'm not sure of the STR, I think swiping left and right could help.
<details><summary>Screenshot</summary>
![Screenshot_20230920-173414](/uploads/5a11ba7505f431aa12c0d4bbee989b7e/Screenshot_20230920-173414.png)
</details>https://gitlab.torproject.org/tpo/network-health/metrics/tagtor/-/issues/25Add filtering options for relays one is interested in2024-01-16T13:50:05ZGeorg KoppenAdd filtering options for relays one is interested inFor bad-relay work or general tagging help it would be nice if we could filter relays, eg. wrt AS, uptime, first_seen dates etc.For bad-relay work or general tagging help it would be nice if we could filter relays, eg. wrt AS, uptime, first_seen dates etc.TagTor is completed for its scope in Sponsor 112