Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2021-04-02T04:49:03Zhttps://gitlab.torproject.org/legacy/trac/-/issues/16650Set up domain fronting for BridgeDB2021-04-02T04:49:03ZIsis LovecruftSet up domain fronting for BridgeDBWe've been [discussing setting up domain fronting for BridgeDB](https://lists.torproject.org/pipermail/tor-dev/2015-May/008793.html) for a while now.
Benefits include better reachability (to BridgeDB) for clients in censored regions. So...We've been [discussing setting up domain fronting for BridgeDB](https://lists.torproject.org/pipermail/tor-dev/2015-May/008793.html) for a while now.
Benefits include better reachability (to BridgeDB) for clients in censored regions. Solving the problem of clients not being able to reach BridgeDB would allow for Tor Browser to do smarter things w.r.t. helping clients get bridges, helping them get the right kind of bridges, helping clients determine which kind of bridge is the right kind, and helping BridgeDB know more about which (types of) bridges are blocked (in specific regions, possibly). This will also allow Tor Browser to recommend to meek users to obtain a different type of working bridges, which will allow us to hopefully start reducing meek's costs without losing bridge users (and hopefully, without decreasing usability).
This shouldn't be too difficult to set up, however, some open questions include:
* What changes, if any, will we need to make to meek-server to reuse David's work?
* What changes will we need to make to BridgeDB?
* Who will maintain the CDN accounts? Who will pay for them?
* How can we ensure that the traffic to/from BridgeDB is end-to-end TLS encrypted? Can we do this and yet still get the client's real IP address (which BridgeDB currently uses for some necessary rate-limiting logic)?
* How many, and which, CDNs do we want to set up?Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/27239TB team feedback on jump-to-80% work2020-06-16T00:49:21ZIsabela FernandesTB team feedback on jump-to-80% workHello TB team,
we would like your feedback on this work, and let us know if there is anything we need to know regarding this on Tor Browser side.Hello TB team,
we would like your feedback on this work, and let us know if there is anything we need to know regarding this on Tor Browser side.Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15607Tor log dates imprecise2020-06-15T23:32:36ZDamian JohnsonTor log dates impreciseHi Nick. Tor's log file uses the local timezone and lacks the year in its log file entries...
```
Apr 06 11:03:39.000 [notice] Tor 0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) opening new log file.
Apr 06 11:03:39.832 [notice] Tor v0.2.7.0-...Hi Nick. Tor's log file uses the local timezone and lacks the year in its log file entries...
```
Apr 06 11:03:39.000 [notice] Tor 0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) opening new log file.
Apr 06 11:03:39.832 [notice] Tor v0.2.7.0-alpha-dev (git-4247ce99e5d9b7b2) running on Linux with Libevent 2.0.16-stable, OpenSSL 1.0.1 and Zlib 1.2.3.4.
Apr 06 11:03:39.832 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
```
This is fine, but has meant some hacks for arm which reads the log file to prepopulate that information. For instance, arm pretends the year is always 2012 to ensure log files made on leap years are readable (otherwise February 29th isn't a thing, see #5265).
Feel free to close this as 'no plan to fix' if you'd like. Just thought I'd run this by you to see if iso8601 timestamps or something more complete would be preferable.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/16899Hide or otherwise disable "Restart with Add-ons Disabled..."2020-06-15T23:29:06ZYawning AngelHide or otherwise disable "Restart with Add-ons Disabled..."Tor Browser still has the vanilla Firefox `Restart with Add-ons Disabled...` menu item under the `Help` menu. While this functionality is extremly useful for debugging vanilla Firefox Add-on/Extension issues, this should probably be hid...Tor Browser still has the vanilla Firefox `Restart with Add-ons Disabled...` menu item under the `Help` menu. While this functionality is extremly useful for debugging vanilla Firefox Add-on/Extension issues, this should probably be hidden/disabled for Tor Browser since it is a giant "Make Tor Browser Not Work" button.
I suspect miniscule fraction of the userbase will complain if it goes missing, so perhaps it should only be hidden via a pref that controls this behavior.https://gitlab.torproject.org/legacy/trac/-/issues/16578make the default "new tab" page related to Tor stuff2020-06-15T23:27:37ZNima Fatemimake the default "new tab" page related to Tor stuffThe default 'new tab' page, is all about Firefox stuff. We should try to change it to Tor related stuff.
![https://trac.torproject.org/projects/tor/raw-attachment/ticket/16578/new-tab.jpg](https://trac.torproject.org/projects/tor/raw-at...The default 'new tab' page, is all about Firefox stuff. We should try to change it to Tor related stuff.
![https://trac.torproject.org/projects/tor/raw-attachment/ticket/16578/new-tab.jpg](https://trac.torproject.org/projects/tor/raw-attachment/ticket/16578/new-tab.jpg)https://gitlab.torproject.org/legacy/trac/-/issues/13407Transition smoothly away from Erinn's signing key for the coming releases2020-06-15T23:23:41ZGeorg KoppenTransition smoothly away from Erinn's signing key for the coming releasesWe should find a good transition away from Erinn's signing key. There are already different proposals on the table with different kinds of efforts involved:
1) Move on to a different key of one of the Tor people.
2) Move away from singl...We should find a good transition away from Erinn's signing key. There are already different proposals on the table with different kinds of efforts involved:
1) Move on to a different key of one of the Tor people.
2) Move away from single points of failure and use the sha256sums verification we already describe on https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification
3) Create a role key for signing the bundles to be not dependent on single people available signing the release.
...Erinn ClarkErinn Clarkhttps://gitlab.torproject.org/legacy/trac/-/issues/13873hard lock tails/torbrowser2020-06-15T23:22:29ZJacob Appelbaumhard lock tails/torbrowserI was looking at some of the fantastic fuzzing research from lcamtuf and I made the mistake of looking at the autogenerated test cases:
http://lcamtuf.coredump.cx/afl/demo/gif_im/full/
It locked my machine (on Tails) because the brows...I was looking at some of the fantastic fuzzing research from lcamtuf and I made the mistake of looking at the autogenerated test cases:
http://lcamtuf.coredump.cx/afl/demo/gif_im/full/
It locked my machine (on Tails) because the browser began to consume every possible resource. I would consider this a Tails issue as the load was around ~20 after a minute or three but not Tails alone. On the one hand, I think Tails should probably compartmentalize the browser and set reasonable rlimits. On the other hand, why doesn't Tor Browser do that? The fact that the entire machine locked up is clearly a Tails-doesn't-confine-the-browser very-well. The fact that Tor Browser can do that is clearly a Tor Browser doesn't set limits issue. I don't think this is just a matter of "not sandboxing" but rather this is a matter of trying to use every bit of juice a machine has available.
How could we do this on a sane platform? In an ideal world, we can load any page and it should not lock the machine. In an ideal world, we could load any page and it shouldn't even lock the browser for other tabs. The latter is obviously something that comes with sandboxing but only if the whole machine isn't thrashing, right?
Anyway, we may also want to use lcamtuf's awesome fuzzing work to crash Tor Browser in interesting ways.https://gitlab.torproject.org/legacy/trac/-/issues/9864Make it easier for users to do file verification2020-06-15T23:16:40ZMatt PaganMake it easier for users to do file verificationVerifying the contents of the Tor Browser Bundle seems to be one of the most confusing things that we ask users to do. The help desk often gets requests from users seeking guidance on verifying bundles.
The website documentation on fil...Verifying the contents of the Tor Browser Bundle seems to be one of the most confusing things that we ask users to do. The help desk often gets requests from users seeking guidance on verifying bundles.
The website documentation on file signature verification we have can be found at https://www.torproject.org/docs/verifying-signatures.html.en. Multiple users have reported that these inctructions are confusing. I don't think this entirely the fault of the page's author.
There are several issues here to consider:
1) On the file verification page we tell Windows users to download Gpg4win so they can download the bundles. Unfortunately there's no verification tool for gpg4win.
2) The signature verification page will be out-of-date once TBB 3 becomes stable. Verifying TBB 3 requires users to verify a signed text file of sha256sums, and then take the sha256sum of the package and see if it matches what's in the signed text file. Currently there is no way to take the sha256sum of anything on Windows unles you compile a program to do it yourself or download and run an unverified .exe file from any number of http-only websites that show up on a google search.
3) Command line interface is intimidating for many people. There are no instructions on our website for using GUI GnuPG frontends.SheriefSheriefhttps://gitlab.torproject.org/legacy/trac/-/issues/31870Do an informal usability study on the "get bridges" process2020-06-13T18:36:23ZPhilipp Winterphw@torproject.orgDo an informal usability study on the "get bridges" processSee [this mailing list post](https://lists.torproject.org/pipermail/ux/2019-May/000448.html) from May 2019. We would like to:
1. Give a user a device with a censored Tor Browser / Tor Browser Android
2. Ask the user to figure out how to...See [this mailing list post](https://lists.torproject.org/pipermail/ux/2019-May/000448.html) from May 2019. We would like to:
1. Give a user a device with a censored Tor Browser / Tor Browser Android
2. Ask the user to figure out how to connect to Tor
3. Observe what issues the user runs into
We may be able to do another iteration of this experiment at the OTF summit in Taipei.https://gitlab.torproject.org/legacy/trac/-/issues/16895allow Tor to parse bridge information copied and pasted verbatim from bridges...2020-06-13T18:35:16Zproperallow Tor to parse bridge information copied and pasted verbatim from bridges.torproject.orgCurrently bridges.torproject.org returns replies for copy and paste in the following form.
```
obfs4 ip:port fingerprint
```
This is easy for copied into tor-launcher. But one who wanted to copy this into its `/etc/tor/torrc` would hav...Currently bridges.torproject.org returns replies for copy and paste in the following form.
```
obfs4 ip:port fingerprint
```
This is easy for copied into tor-launcher. But one who wanted to copy this into its `/etc/tor/torrc` would have to modify it to.
```
Bridge obfs4 ip:port fingerprint
```
This is a usability issue. Therefore, could you make for example `/etc/tor/torrc` config option `obfs4` a shortcut to `Bridge obfs4` etc.?
Ideally, pluggable transports once they plugged into Tor using `ClientTransportPlugin` would be responsible for running the code for setting up these shortcuts themselves so you don't have to maintain a static/outdated list of shortcuts within the Tor core.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/9678"Select Language" button on bridges.tpo2020-06-13T18:27:08ZNima Fatemi"Select Language" button on bridges.tpoSince we're serving this page in many different languages, it would be nice to have a "select language" button somewhere at the top or bottom of the page.
In case a user wants or need to change it manually.Since we're serving this page in many different languages, it would be nice to have a "select language" button somewhere at the top or bottom of the page.
In case a user wants or need to change it manually.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/9156BridgeDB: Users try to add obfsbridges to their normal TBB2020-06-13T18:26:44ZGeorge KadianakisBridgeDB: Users try to add obfsbridges to their normal TBBPhoul told me today that some users get bridges from the new BridgeDB page, and then try to add them to a normal Tor Browser Bundle (that doesn't understand PTs).
This means that those users completely ignored 'Step 1: Get the Pluggable...Phoul told me today that some users get bridges from the new BridgeDB page, and then try to add them to a normal Tor Browser Bundle (that doesn't understand PTs).
This means that those users completely ignored 'Step 1: Get the Pluggable Transports Tor Browser Bundle'. Can we help those users out somehow?
We could **force** users to download the bundle by making BridgeDB a wizard that actually requires you to do step 1 before proceeding to step 2. I'm not sure if this is a good idea though. It might infuriate users who know what they are doing.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/16884Extend "Relays by relay flags" graph to display flag combinations2020-06-13T18:13:27ZNima FatemiExtend "Relays by relay flags" graph to display flag combinationsWhen I select 'Running', 'Exit', and 'Fast' flags on [this graph](https://metrics.torproject.org/relayflags.html?graph=relayflags&start=2015-03-12&end=2015-06-10&flag=Running&flag=Exit&flag=Fast), I'm assuming it should return the number...When I select 'Running', 'Exit', and 'Fast' flags on [this graph](https://metrics.torproject.org/relayflags.html?graph=relayflags&start=2015-03-12&end=2015-06-10&flag=Running&flag=Exit&flag=Fast), I'm assuming it should return the number of "fast and currently running exit nodes" but instead of showing me a mix of all those things, it shows me the list of those flags separately. Hence it's unclear whether the list of exits that I'm seeing are all running or not.
Maybe we should have an <AND>/<OR> kind of filtering here?https://gitlab.torproject.org/legacy/trac/-/issues/29744Streams sometimes stall for up to 1 hour without making any progress2020-06-13T18:03:57ZKarsten LoesingStreams sometimes stall for up to 1 hour without making any progressWe're measuring Tor performance using our OnionPerf tool by regularly downloading 5 MiB files over Tor. Some of these measurements run longer than 1 hour, after which a timeout in OnionPerf aborts them, or run for up to 30 minutes until ...We're measuring Tor performance using our OnionPerf tool by regularly downloading 5 MiB files over Tor. Some of these measurements run longer than 1 hour, after which a timeout in OnionPerf aborts them, or run for up to 30 minutes until they complete. (For comparison, 99% of successful runs complete within roughly two minutes.)
I noticed one particular source of slowness which I think is the reason for the application timeouts after 1 hour and for some of the 1% slowest successful runs: streams stall for seconds or minutes and would even stall for hours if we let them, without making any progress; and suddenly they make progress until they complete or stall again.
I'm attaching four graphs showing this problem. All these graphs show download progress over time with time on x and progress on y. Each gray bar is one measurement. The black line starts at the bottom of its gray bar and goes up to the top of that bar as more data is received. The number on the right is the stream ID.
The first two graphs show application timeouts, the last two show the slowest 1% of successful runs. First and third show downloads from a public server, second and fourth from an onion server.
Note that not all runs have this problem of stalling as described above. Some of the more obvious cases are:
- Page 3, stream ID 436971: that stream basically does nothing for over half an hour and then completes within seconds.
- Page 3, stream ID 436986: same as before, just with a shorter stalling period.
Other cases have different issues. For example, stream ID 34117 on page 3 is rather slow for most of the time and then suddenly gets faster at the end. However, it does not stall.
I do have tor logs and tor controller event logs for these cases. Here's a log containing many relevant STREAM and STREAM_BW events: https://people.torproject.org/~karsten/volatile/streams-2019-02-18.log.xz (61.1K)
These measurements have been made using tor versions 0.2.9.11-dev and 0.3.0.7-dev.
I can provide more data. But rather than uploading everything, please let me know what data would be most useful, and I'll provide just that.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29743Long-running tor instances fail to keep up-to-date directory information2020-06-13T18:03:57ZKarsten LoesingLong-running tor instances fail to keep up-to-date directory informationWe have a small number of long-running tor instances as part of our OnionPerf setups that are running 24/7. In the past, some of these tor instances got into a state where their directory information was no longer up-to-date enough to bu...We have a small number of long-running tor instances as part of our OnionPerf setups that are running 24/7. In the past, some of these tor instances got into a state where their directory information was no longer up-to-date enough to build circuits. In some cases they recovered after hours, days, or even weeks, but in some cases we had to restart the tor processes.
I'm attaching a graph that shows the number of open circuits as reported in heartbeat log messages. That number is relatively stable most of the time, depending on whether we're using the tor instance for making requests or for providing an onion service. But in some cases the number drops to zero, which coincides with the log message:
```
[notice] Our directory information is no longer up-to-date enough to build circuits: [...]
```
The graph also shows that sometimes the number magically goes up again. Those times coincide with the following log message:
```
[notice] We now have enough directory information to build circuits.
```
The purple dashed lines show when we restarted tor processes manually. Some of these restarts are unrelated to the number of open circuits. But some restarts happened explicitly because the tor instance was not working anymore for our measurements.
By the way, the op-nl instance shown in the middle was running 0.2.9.11-dev, whereas the op-us and op-hk instances were running 0.3.0.7-dev. It may be coincidence, but the older op-nl did not run out of up-to-date directory information, whereas the newer op-us and op-hk did. Was this issue maybe introduced in 0.3.0.x?
I have tor logs available for all these tor instances. I can easily provide them, either as a big tarball or for specific days and instances as a smaller tarball. Just let me know.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/13084globe gets read/written backwards in its bandwidth graphs2020-06-13T17:55:44ZRoger Dingledineglobe gets read/written backwards in its bandwidth graphshttps://atlas.torproject.org/#details/7552CA84FB125059DC2959A6BE01A6A8107B3523
shows a big jump in bandwidth, especially read bytes.
whereas
https://globe.torproject.org/#/relay/7552CA84FB125059DC2959A6BE01A6A8107B3523
shows a big jump ...https://atlas.torproject.org/#details/7552CA84FB125059DC2959A6BE01A6A8107B3523
shows a big jump in bandwidth, especially read bytes.
whereas
https://globe.torproject.org/#/relay/7552CA84FB125059DC2959A6BE01A6A8107B3523
shows a big jump in bandwidth, but especially written bytes.
Examination of the extrainfo descriptor for the relay in question shows that it's read-history, not write-history, that has the big numbers.
So I think globe has its labels mixed up?Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/27167track "first" OR_CONN2020-06-13T17:44:18ZTaylor Yutrack "first" OR_CONNRight now the first stages of the "first" OR_CONN get reported as `BOOTSTRAP_STATUS_CONN_DIR` and `BOOTSTRAP_STATUS_HANDSHAKE` (the latter is a special bootstrap phase that gets translated into `BOOTSTRAP_STATUS_HANDSHAKE_DIR` or `BOOTST...Right now the first stages of the "first" OR_CONN get reported as `BOOTSTRAP_STATUS_CONN_DIR` and `BOOTSTRAP_STATUS_HANDSHAKE` (the latter is a special bootstrap phase that gets translated into `BOOTSTRAP_STATUS_HANDSHAKE_DIR` or `BOOTSTRAP_STATUS_HANDSHAKE_OR` depending on how much progress was previously reported. The logic in functions that report these events should be moved up to a new abstraction so lower level code has to track less high-level state.
This also eliminates some logic in `control_event_bootstrap()` that tries to figure out whether a given handshake attempt corresponds to a directory connection or an application circuit connection.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/22266gather info on jump-to-80% issues2020-06-13T17:43:43ZTaylor Yugather info on jump-to-80% issuesThis ticket is now for gathering additional info and feedback about the category of jump-to-80% bootstrap reporting problems.
background:
If enough existing directory information is available, the bootstrap progress as reported to the ...This ticket is now for gathering additional info and feedback about the category of jump-to-80% bootstrap reporting problems.
background:
If enough existing directory information is available, the bootstrap progress as reported to the logs and the control connection jumps from 0% to 80% almost immediately. This is misleading and causes user frustration, as reported by Linda's study.
When bootstrapping with existing directory information, we should rescale the progress numbers so they advance on something resembling a linear time scale, which is probably closer to what users expect to see.Tor: 0.4.0.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/22232gather info on how Tor Launcher uses bootstrap status messages2020-06-13T17:43:35ZTaylor Yugather info on how Tor Launcher uses bootstrap status messagesAs part of the effort to improve the user experience during Tor Launcher bootstrap (#21951), it would be helpful to know some details of how Tor Launcher currently uses bootstrap status messages (`STATUS_CLIENT BOOTSTRAP` asynchronous me...As part of the effort to improve the user experience during Tor Launcher bootstrap (#21951), it would be helpful to know some details of how Tor Launcher currently uses bootstrap status messages (`STATUS_CLIENT BOOTSTRAP` asynchronous messages from the control protocol). Among other things, it could help Core Tor make short-term incremental changes to vastly improve the user experience.
* Does the progress bar currently map phase numbers directly into percent-done on the bar?
* Does it do anything with `TAG=` keywords in the BOOTSTRAP messages?
* Does it do anything with `SUMMARY=` strings other than displaying them in the dialog box?
* How does it know when to display the "copy logs" button with the warning icon?
* Which other of the `BOOTSTRAP` keywords does it use and how?
* Does it use any other asynchronous control protocol messages?Kathleen BradeKathleen Bradehttps://gitlab.torproject.org/legacy/trac/-/issues/10610Tor Browser users don't know if their network is free of obstacles or not2020-06-13T17:42:34ZMatt PaganTor Browser users don't know if their network is free of obstacles or notUsers who used to be able to connect to Tor without any problem are emailing the help desk to ask if their network is free of obstacles. I suggest the tor-launcher interface be reworded to indicate that most users will not have to config...Users who used to be able to connect to Tor without any problem are emailing the help desk to ask if their network is free of obstacles. I suggest the tor-launcher interface be reworded to indicate that most users will not have to configure anything, or the option to configure bridges be offered later in the interface.