The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-09-23T13:43:20Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33437Unsuccessful compilation of tor on FreeBSD system with libssl.so.112020-09-23T13:43:20ZTracUnsuccessful compilation of tor on FreeBSD system with libssl.so.11+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files a...+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files are attached.
Notes:
- compilation of **0.4.2.6** with **libssl.so.9** was successful
- compilation of **0.4.2.6** with **libssl.so.11** was unsuccessful
----
**Trac**:
**Username**: stillicideTor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31565static Tor building against openssl-1.1.1 fails: configure unable to find lin...2020-07-29T13:10:29ZTracstatic Tor building against openssl-1.1.1 fails: configure unable to find linkable OpenSSLTrying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4...Trying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4.0.5 and 0.4.1.5. Building against openssl-1.0.2 works.
**Trac**:
**Username**: shredderTor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40262Browser tabs crashing on the new Macbooks with the M1 chip2021-01-16T16:15:29Zchampionquizzerchampionquizzer@torproject.orgBrowser tabs crashing on the new Macbooks with the M1 chipThere are recurring reports from users on the frontdesk that the latest version of Tor Browser (10.0.5) and Tor Browser Alpha (10.5a4) for the MacOS on the new Macbooks with the M1 chip, keeps crashing with the error message "Gah. Your t...There are recurring reports from users on the frontdesk that the latest version of Tor Browser (10.0.5) and Tor Browser Alpha (10.5a4) for the MacOS on the new Macbooks with the M1 chip, keeps crashing with the error message "Gah. Your tab just crashed"Tor Browser: 10.0https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33666Investigate Snowflake proxy failures2022-06-01T19:51:48ZCecylia BocovichInvestigate Snowflake proxy failuresSometimes a client will get a useless proxy from the broker. At times this happens occasionally, and at times more often. It could be a NAT problem.Sometimes a client will get a useless proxy from the broker. At times this happens occasionally, and at times more often. It could be a NAT problem.Snowflake in Tor Browser 10.5Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32868crash: Assertion node->rs->is_possible_guard failed in compute_weighted_band...2020-07-14T22:24:21Ztoralfcrash: Assertion node->rs->is_possible_guard failed in compute_weighted_bandwidths atWith https://github.com/toralf/torutils/blob/f307866d2149bcd3c95df5269b3b48d051f871e9/info.py I monitor the status of my 2 Tor relays. A day before I commented out this section in torrc:
```
#FetchDirInfoEarly 1
#FetchDirInfoExtraEarly 1...With https://github.com/toralf/torutils/blob/f307866d2149bcd3c95df5269b3b48d051f871e9/info.py I monitor the status of my 2 Tor relays. A day before I commented out this section in torrc:
```
#FetchDirInfoEarly 1
#FetchDirInfoExtraEarly 1
#FetchUselessDescriptors 1
#UseMicrodescriptors 0
#DownloadExtraInfo 1
```
Now it took 7 minutes to finish (when those config values were set it was much faster).
But more interesting I realized today I crash of one of both Tor relays:
```
Jan 01 11:12:38.000 [warn] compute_weighted_bandwidths(): Bug: Consensus is missing some bandwidths. Using a naive router selection algorithm (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] tor_assertion_failed_(): Bug: src/feature/nodelist/node_select.c:723: compute_weighted_bandwidths: Assertion node->rs->is_possible_guard failed; aborting. (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: Tor 0.4.2.5: Assertion node->rs->is_possible_guard failed in compute_weighted_bandwidths at src/feature/nodelist/node_select.c:723: . Stack trace: (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(log_backtrace_impl+0x59) [0x55850995e1a9] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x150) [0x5585099593e0] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(+0x12c474) [0x558509896474] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(frac_nodes_with_descriptors+0x73) [0x558509897373] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(+0x12afb2) [0x558509894fb2] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(count_loading_descriptors_progress+0x6c) [0x558509895b2c] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(connection_dir_reached_eof+0x20e0) [0x558509856f30] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(connection_handle_read+0x980) [0x5585097d2760] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(+0x6d97c) [0x5585097d797c] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/lib64/libevent-2.1.so.6(+0x219ca) [0x7ffbba3cb9ca] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/lib64/libevent-2.1.so.6(event_base_loop+0x4ef) [0x7ffbba3cc54f] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(do_main_loop+0xdd) [0x5585097d8b2d] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(tor_run_main+0x10c5) [0x5585097c6855] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(tor_main+0x46) [0x5585097c4076] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(main+0x19) [0x5585097c3c49] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /lib64/libc.so.6(__libc_start_main+0xeb) [0x7ffbb9d19eab] (on Tor 0.4.2.5 )
Jan 01 11:12:38.000 [err] Bug: /usr/bin/tor(_start+0x2a) [0x5585097c3c9a] (on Tor 0.4.2.5 )
```
System is a hardened Gentoo Linux running 2 relays. The second is not affected.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33832For relays that change ip, only the measurements with the last ip are kept2020-12-18T09:41:15ZjugaFor relays that change ip, only the measurements with the last ip are keptwhich makes those relays more likely to don't be "eligible" cause don't have enough results and therefore, sbws voting in less relays.which makes those relays more likely to don't be "eligible" cause don't have enough results and therefore, sbws voting in less relays.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30832Fix tor-browser tbb-tests2022-07-08T23:11:04ZAlex CatarineuFix tor-browser tbb-testsWith current rebased tor-browser ESR68 branch I can only run tbb-tests (with `run-tbb-tests` script) when `pref("network.file.path_blacklist", "/net")` is removed and `pref("extensions.torbutton.use_nontor_proxy", true);` is set, apart f...With current rebased tor-browser ESR68 branch I can only run tbb-tests (with `run-tbb-tests` script) when `pref("network.file.path_blacklist", "/net")` is removed and `pref("extensions.torbutton.use_nontor_proxy", true);` is set, apart from disabling tor-launcher. The second pref disables the domain isolator, which makes sense since it expects SOCKS5 proxies, but mochitests override that. For the other pref, not sure why `network.file.path_blacklist` needs to be unset (at least for Linux).
We could put these prefs in `testing/marionette/prefs/marionette.js` so that tests can be run (unless there is a simpler way to get the tests tor run that I'm missing).Tor Browser: 10.5https://gitlab.torproject.org/tpo/tpa/team/-/issues/40450The old website build is breaking because it does not find the tor repo2021-10-20T13:49:37ZemmapeelThe old website build is breaking because it does not find the tor repoThere is a new error in town, and it is jenkins complaining it cannot build the 'old website':
`[jenkins] website-build-webwml#8911: Still Failing: https://jenkins.torproject.org/job/website-build-webwml/8911/
`
If you open the job you...There is a new error in town, and it is jenkins complaining it cannot build the 'old website':
`[jenkins] website-build-webwml#8911: Still Failing: https://jenkins.torproject.org/job/website-build-webwml/8911/
`
If you open the job you can see that the build breaks because of:
```
15:13:59 > git config remote.origin.url https://git.torproject.org/tor.git # timeout=10
15:13:59 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
15:13:59 Avoid second fetch
15:13:59 > git rev-parse origin/master^{commit} # timeout=10
15:13:59 > git rev-parse master^{commit} # timeout=10
15:13:59 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
```
I am not sure that we need to run it so often, now that it is not having any new content.
But if we do, we should change the reference. Maybe is the move from master to main?Retire Jenkinshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40712Unable to set a primary password on TB112023-11-12T03:48:11ZdonutsUnable to set a primary password on TB11Although the password manager is not officially supported by Tor Browser, I fear we may have inadvertently broken it again. Occurs on all desktop platforms as far as I can tell.
![tb-11-primary-password](/uploads/e40f3b2993253ffac6d8162...Although the password manager is not officially supported by Tor Browser, I fear we may have inadvertently broken it again. Occurs on all desktop platforms as far as I can tell.
![tb-11-primary-password](/uploads/e40f3b2993253ffac6d8162719fe8081/tb-11-primary-password.png)Tor Browser: 11.0 Issues with previous releasehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40544Show tor's bootstrapping percentage and description on about:torconnect2022-05-17T23:09:26ZMatthew FinkelShow tor's bootstrapping percentage and description on about:torconnectIt's written on the label.
Possible backport candidate.It's written on the label.
Possible backport candidate.Tor Browser: 11.0 Issues with previous releaserichardrichardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40383daily abort in tor 0.4.5.7, 0.4.6.1-alpha, and 0.4.6.2-alpha [Assertion end >...2023-01-10T18:36:20ZScott Bennettdaily abort in tor 0.4.5.7, 0.4.6.1-alpha, and 0.4.6.2-alpha [Assertion end > start failed in create_voting_schedule]### Summary
I was running 0.4.5.2-alpha with no problems. After I upgraded tor to 0.4.6.1-alpha,
tor crashed in under 24 hours. After the third such crash, I switched to 0.4.5.7,
naively expecting it to be a "stable" release. That vers...### Summary
I was running 0.4.5.2-alpha with no problems. After I upgraded tor to 0.4.6.1-alpha,
tor crashed in under 24 hours. After the third such crash, I switched to 0.4.5.7,
naively expecting it to be a "stable" release. That version, too, crashes with the
same set of error messages. I have now upgraded to 0.4.6.2-alpha, and the same bug
is present. I am running tor on a FreeBSD 11.4-STABLE system.
### Steps to reproduce:
1. Install one of the afflicted versions of tor onto a FreeBSD 11.4-STABLE system. I do not
know whether later versions of FreeBSD would get a different result, but given the abort
messages, I suspect not.
2. Start tor.
3. Wait until 6 p.m. CDT (2300Z). The abort will occur before 7 p.m. CDT (0000Z).
### What is the current bug behavior?
During startup and operation everything appears to be normal. However, these versions
of tor always abort every day between 6 p.m. and 7 p.m. CDT (2300Z and 0000Z) with the
same group of error messages being written to /var/log/notices.
The startup messages look as follows.
```
May 08 19:21:24.633 [notice] Tor 0.4.6.2-alpha opening log file.
May 08 19:21:24.601 [notice] We compiled with OpenSSL 101010bf: OpenSSL 1.1.1k 25 Mar 2021 and we are running with OpenSSL 101010bf: 1.1.1k. These two versions should be binary compatible.
May 08 19:21:24.604 [notice] Tor 0.4.6.2-alpha running on FreeBSD with Libevent 2.1.12-stable, OpenSSL 1.1.1k, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.9 and Unknown N/A as libc.
May 08 19:21:24.604 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
May 08 19:21:24.604 [notice] This version is not a stable Tor release. Expect more bugs than usual.
May 08 19:21:24.604 [notice] Read configuration file "/usr/local/etc/tor/torrc".
May 08 19:21:24.616 [notice] You configured a non-loopback address '10.1.1.1:9050' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
May 08 19:21:24.616 [notice] Opening Socks listener on 127.0.0.1:9050
May 08 19:21:24.616 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050
May 08 19:21:24.616 [notice] Opening Socks listener on 10.1.1.1:9050
May 08 19:21:24.616 [notice] Opened Socks listener connection (ready) on 10.1.1.1:9050
May 08 19:21:24.616 [notice] Opening Control listener on 127.0.0.1:9051
May 08 19:21:24.616 [notice] Opened Control listener connection (ready) on 127.0.0.1:9051
May 08 19:21:24.616 [notice] Opening OR listener on 0.0.0.0:32323
May 08 19:21:24.616 [notice] Opened OR listener connection (ready) on 0.0.0.0:32323
May 08 19:21:24.616 [notice] Opening Directory listener on 0.0.0.0:32326
May 08 19:21:24.616 [notice] Opened Directory listener connection (ready) on 0.0.0.0:32326
May 08 19:21:24.640 [notice] Not disabling debugger attaching for unprivileged users.
May 08 19:21:25.419 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
May 08 19:21:25.593 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
May 08 19:21:25.756 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
May 08 19:21:25.907 [notice] Your Tor server's identity key fingerprint is 'MYCROFTsOtherChild 0861F4966E199C0BA9DB1D904DB4BC843508F12C'
May 08 19:21:25.907 [notice] Your Tor server's identity key ed25519 fingerprint is 'MYCROFTsOtherChild hYNLQhYYu0FRDfZGPVW3jFPW27tHY6fZm0GiFP2YkPE'
May 08 19:21:25.907 [notice] Bootstrapped 0% (starting): Starting
May 08 19:21:43.556 [notice] Starting with guard context "default"
May 08 19:21:44.605 [notice] Bootstrapped 5% (conn): Connecting to a relay
May 08 19:21:44.718 [notice] Bootstrapped 10% (conn_done): Connected to a relay
May 08 19:21:44.962 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
May 08 19:21:45.447 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
May 08 19:21:45.448 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
May 08 19:21:45.448 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
May 08 19:21:45.448 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
May 08 19:21:48.184 [notice] Bootstrapped 100% (done): Done
May 08 19:21:48.185 [notice] Now checking whether IPv4 ORPort 98.193.69.56:32323 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
May 08 19:21:48.649 [notice] Self-testing indicates your ORPort 98.193.69.56:32323 is reachable from the outside. Excellent. Publishing server descriptor.
May 08 19:39:45.296 [notice] Performing bandwidth self-test...done.
```
The abort messages follow. It does not appear to matter what time of day tor is started.
It always aborts during that hour at the start of the evening, and the exact time seems to be
quasi-random and may coincide with some quasi-hourly event, such as downloading directory
updates or consensus files.
```
May 09 18:21:45.586 [notice] Heartbeat: Tor's uptime is 23:00 hours, with 88 circuits open. I've sent 1.18 GB and received 1.46 GB. I've received 12680 connections on IPv4 and 0 on IPv6. I've made 11044 connections with IPv4 and 0 with IPv6.
May 09 18:21:45.620 [notice] While bootstrapping, fetched this many bytes: 35042 (consensus network-status fetch); 500 (microdescriptor fetch)
May 09 18:21:45.620 [notice] While not bootstrapping, fetched this many bytes: 13502874 (server descriptor fetch); 1080 (server descriptor upload); 1780039 (consensus network-status fetch); 89127 (microdescriptor fetch)
May 09 18:21:45.620 [notice] Circuit handshake stats since last time: 11/11 TAP, 1449/1449 NTor.
May 09 18:21:45.620 [notice] Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and received 511 v4 connections; initiated 10070 and received 11411 v5 connections.
May 09 18:21:45.620 [notice] Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected.
May 09 18:23:46.805 [err] tor_assertion_failed_: Bug: src/feature/dirauth/voting_schedule.c:64: create_voting_schedule: Assertion end > start failed; aborting. (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: Tor 0.4.6.2-alpha: Assertion end > start failed in create_voting_schedule at src/feature/dirauth/voting_schedule.c:64: . Stack trace: (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1107fac <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x11132a2 <tor_assertion_failed_+0x142> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x10e96a6 <dirauth_sched_recalculate_timing+0x1e6> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x109c113 <networkstatus_set_current_consensus+0xed3> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x11d96cc <connection_dir_reached_eof+0x1b6c> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x11acf26 <connection_handle_read+0xbe6> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1090050 <connection_add_impl+0x240> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1c1bada8a <event_base_assert_ok_nolock_+0xc3a> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1c1ba8eec <event_base_loop+0x57c> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.6.2-alpha )
May 09 18:23:46.806 [err] Bug: 0x1092465 <do_main_loop+0x135> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.807 [err] Bug: 0x108d89c <tor_run_main+0x12c> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
May 09 18:23:46.807 [err] Bug: 0x108c22e <tor_main+0x6e> at /usr/local/bin/tor (on Tor 0.4.6.2-alpha )
```
### What is the expected behavior?
I expect tor not to abort and instead to run until either I shut it down or the OS crashes
for any reason.
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
As stated above, the versions I know to be affected are 0.4.5.7, 0.4.6.1-alpha, and
0.4.6.2-alpha.
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10,
Ubuntu Xenial, FreeBSD 12.2, etc.
As stated above, this problem is occurring on FreeBSD 11.4-STABLE. I have added an
entry to /etc/crontab to restart tor every evening at 7:01 p.m. CDT (2301Z), which works,
but does not prevent sudden breakage of about 400 to 2000 connections when tor aborts, and
means that my relay can never get a Stable flag. (The authorities stopped giving it a
HSDir flag months ago for no reason apparent to me, as well, but that appears to be a problem unrelated to the bug reported here.)
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
I installed each version using portmaster(8) to install/upgrade from the FreeBSD
11-STABLE ports tree, so portmaster compiled each version locally. Other than the kinds of
differences that show up when not using a "reproducible build" procedure, they are the same
as if installed by pkg(8).
### Relevant logs and/or screenshots
See above.
### Possible fixesTor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30579Add more STUN servers to the default snowflake configuration in Tor Browser2023-08-02T00:02:28ZCecylia BocovichAdd more STUN servers to the default snowflake configuration in Tor BrowserRight now snowflake blocking in China is happening in the client's connection to the default STUN server (which is set to Google's STUN servers). We should add more STUN servers, including ones that are popular in regions that are trying...Right now snowflake blocking in China is happening in the client's connection to the default STUN server (which is set to Google's STUN servers). We should add more STUN servers, including ones that are popular in regions that are trying to block snowflake so that blocking this stage causes more collateral damage.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41602Designing the User Interface of Conjure in Tor Browser2023-05-30T21:43:51ZrichardDesigning the User Interface of Conjure in Tor BrowserFollowing https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41361 we need to do the UX work for exposing this feature to users.
@cohosh can you reply with a blurb about how conjure works/differs from other bridges, tra...Following https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41361 we need to do the UX work for exposing this feature to users.
@cohosh can you reply with a blurb about how conjure works/differs from other bridges, tradeoffs, etc so we get a string written for the bridge selection UX ( see https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41583#note_2870062 for reference).Sponsor 30 - Objective 2.3https://gitlab.torproject.org/tpo/tpa/team/-/issues/40973gnt-chi cluster retirement2023-10-04T21:04:19Zanarcatgnt-chi cluster retirementonce we have done the mass VM migration from gnt-chi to gnt-dal (#40972), we should retire the old gnt-chi machines that are still around.
for each machine, we need to go through the `retire-a-host` procedure. special care should probab...once we have done the mass VM migration from gnt-chi to gnt-dal (#40972), we should retire the old gnt-chi machines that are still around.
for each machine, we need to go through the `retire-a-host` procedure. special care should probably be taken with the SANs as well.
- [x] chi-node-01 (wiped at 67.84%)
- [x] chi-node-02 (wiped 100%)
- [x] chi-node-03 (wiped 100%)
- [x] chi-node-04 (wiped 100%)
- [x] ~~chi-node-05~~ (already done in #40738)
- [x] chi-node-06 (wiped 100%)
- [x] chi-node-07 (partially wiped)
- [x] chi-node-08 (partially wiped)
- [x] chi-node-09 (wiped 100%)
- [x] chi-node-10 (wiped 100%)
- [x] ~~chi-node-11~~ (already done in #41071)
- [x] chi-node-12 (wiped 100%)
- [x] chi-node-13 (wiped 100%)
- [x] ~~chi-node-14~~ (shipped to dallas, see #40968)
- [x] moly and peninsulare (see #29974)
each server will follow the normal retirement procedure except those steps which will be done in one batch:
* [x] nagios
* [x] power-grep
* [x] remove from tor-passwords
* [x] remove from DNSwl (N/A)
* [x] remove from docs
* [x] remove from reverse DNS
* [x] remove from racks (the wipe is done individually, but the unracking will be issued to cymru all at once) update: rack removal requested from cymru
SAN servers retirement:
- [x] chi-san-01
- [x] chi-san-02
- [x] chi-san-03
- [x] chi-san-04trusted high performance cluster (gnt-dal migration)anarcatanarcat2023-05-11https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41423about:tor semantic and accessibility problems2023-10-03T13:29:51Zhenryabout:tor semantic and accessibility problemsSome issues with the about:tor page:
1. I'm not sure "About Tor" is the best document title. Wouldn't it be "About Tor Browser", or "Tor Browser Ready" or "Tor Browser Home"?
2. The "New to Tor Browser" button (`#onboarding-overlay-butt...Some issues with the about:tor page:
1. I'm not sure "About Tor" is the best document title. Wouldn't it be "About Tor Browser", or "Tor Browser Ready" or "Tor Browser Home"?
2. The "New to Tor Browser" button (`#onboarding-overlay-button`) has an almost invisible "focus-visible" styling. And the color contrast is poor.
3. The search input (`#search-text`) has no "focus-visible" styling.
4. The search button (`#search-button`) has "focus-visible" outline that isn't consistent with the rest of the page: it has thin dotted outline, whilst the links have a thick blue outline.
5. The search label (`#searchlabel`) has no text content (it is just a background image) so does not work as a label for the search input.
6. All the `<img>` elements (`#onboarding-overlay-button-icon`, `#torcontent-logo`, `#bannerImg`, and `#imageStyle`) do not have an `alt=""` attribute.
7. A lot of the link text ends in the "ยป" symbol. I'm not sure why we do this, but it does not read well on a screen reader. So it should be removed or visual only.
8. I feel like the `.heading1` text is meant to act as the page's heading, so should be a `<h1>`.
9. The page uses lots of `<div>`s instead of elements with more structural semantics.Sponsor 131 - Phase 2 - Privacy Browserhenryhenryhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41334Mockup the browser chrome of the privacy browser2023-03-13T16:31:23ZdonutsMockup the browser chrome of the privacy browserThe browser chrome won't be very different from Tor Browser's, save for the omission of Tor Network-specific elements like the circuit display, onion site icons, ".onion site available" pill, etc. However we should check-in on toolbar ic...The browser chrome won't be very different from Tor Browser's, save for the omission of Tor Network-specific elements like the circuit display, onion site icons, ".onion site available" pill, etc. However we should check-in on toolbar icons (specifically new identity), and any extensions that may be bundled in the final privacy browser.Sponsor 131 - Phase 2 - Privacy Browserdonutsdonutshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41331Create horizontal logo lockup for the privacy browser2022-12-17T15:22:42ZdonutsCreate horizontal logo lockup for the privacy browserOnce an application icon has been created in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41168, we'll need to add some logotype reading "Mullvad Browser" to create a full logo lockup. The logotype and rough compos...Once an application icon has been created in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41168, we'll need to add some logotype reading "Mullvad Browser" to create a full logo lockup. The logotype and rough composition should match that used by the Mullvad VPN, i.e.:
- [MullvadVPN_logo_Landscape_RGB_BW_positive](/uploads/83dcc140441b04f3f4eef226ae638ee4/MullvadVPN_logo_Landscape_RGB_BW_positive.png)
SVG and EPS formatted versions of the above logo can be found here: https://mullvad.net/en/press/
The full lockup will likely be used on the successor to `about:tor` (pending its design), the Mullvad website, in release posts and social media/promotional posts. However, we'll need separate assets for the `About > Browser` window, i.e.:
- [about-firefox](/uploads/2859ec3739e389bfe01f7a96df2326f8/about-firefox.png)Sponsor 131 - Phase 2 - Privacy Browserhttps://gitlab.torproject.org/tpo/network-health/metrics/onionperf/-/issues/40015Onionperf ability to configure guard topology and proximity2021-04-01T11:57:16ZGeorge KadianakisOnionperf ability to configure guard topology and proximityIn https://gitlab.torproject.org/tpo/core/tor/-/issues/40157 we've been doing experiments with various guard topologies. In particular we do experiments with guards that are **close** to the onionperf box, and guards that are **far** fro...In https://gitlab.torproject.org/tpo/core/tor/-/issues/40157 we've been doing experiments with various guard topologies. In particular we do experiments with guards that are **close** to the onionperf box, and guards that are **far** from the onionperf box, or with 2 guards where one guard is close and the other is far. We also do experiments with a single guard and two guards.
Right now I'm doing this by specifying a different config file for each of those scenarios. However if we want to run these experiments consistently in the future we might want to automate this in onionperf.
\cc @acute @karsten @mikeperrySponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placeshttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/123Drop in Iranian snowflake users2023-05-29T22:07:57ZHackerNCoderhackerncoder@encryptionin.spaceDrop in Iranian snowflake usershttps://metrics.torproject.org/userstats-bridge-combined.html?start=2022-12-02&end=2023-03-03&country=ir
Recently snowflake usage in Iran has been dropping
A similar graph can be seen in US, https://metrics.torproject.org/userstats-bri...https://metrics.torproject.org/userstats-bridge-combined.html?start=2022-12-02&end=2023-03-03&country=ir
Recently snowflake usage in Iran has been dropping
A similar graph can be seen in US, https://metrics.torproject.org/userstats-bridge-combined.html?start=2022-12-02&end=2023-03-03&country=usSponsor 139: Rapid Response Iranshelikhooshelikhoo2023-05-26https://gitlab.torproject.org/tpo/ux/research/-/issues/100Users find it difficult to differentiate between Tor Browser's various bridge...2023-05-10T21:46:19ZdonutsUsers find it difficult to differentiate between Tor Browser's various bridge optionsDuring usability testing of Connection Settings conducted in tpo/ux/research#52 & tpo/ux/research#78 participants who elected to select a bridge manually tended to try the various options at random.
For the most part, the options are pl...During usability testing of Connection Settings conducted in tpo/ux/research#52 & tpo/ux/research#78 participants who elected to select a bridge manually tended to try the various options at random.
For the most part, the options are placed in the order it's most useful to try them in:
1. Select a built-in bridge
1. obfs4
2. snowflake
3. meek-azure
2. Request a bridge from torproject.org
3. Provide a bridge manually
However we don't communicate that explicitly to the user.
The redesign conducted in https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41080 also attempted to improve the UX by tidying away the inputs into separate dialogues, and by has provided extra space for descriptions to accompany each bridge option within the dialogues themselves. I think it would be worthwhile reviewing the descriptions added for built-in-bridges, looking for potential improvements, and to consider adding similar descriptions to the request a bridge and provide a bridge dialogues.Sponsor 30 - Objective 3.5