The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-01-17T18:59:16Zhttps://gitlab.torproject.org/tpo/operations/team/-/issues/3Claim torproject.com HNS domain2023-01-17T18:59:16ZGusClaim torproject.com HNS domainRecently we've learned that we could claim the `torproject.com` domain on Handshake (HNS) blockchain and we will get 1,195,341 HNS (or USD 304k at the moment). Other projects already claimed their domains, for example, [Brave](https://hn...Recently we've learned that we could claim the `torproject.com` domain on Handshake (HNS) blockchain and we will get 1,195,341 HNS (or USD 304k at the moment). Other projects already claimed their domains, for example, [Brave](https://hnscan.com/tx/e641b6dc9d6664990a10da46c2b9437ab72dd508348d56ec973f6781f6ab54f3) and [Riseup](https://hnscan.com/name/riseup). After clamming the domain, it will take 30 days to move the funds from HNS wallet.
Here's a step by step how to do that: https://gist.github.com/tynes/230f715c9710a089ee190b28585b6596.
Micah Anderson offered his help.al smithal smithhttps://gitlab.torproject.org/tpo/community/outreach/-/issues/40016Tor Project proposals for Mozfest 20232023-01-16T01:15:42ZGusTor Project proposals for Mozfest 2023I'm opening this ticket to coordinate the community team proposals for Mozfest.
Event: 8 to 20 June 2023, Amsterdam
CFP: The deadline to submit your proposal for MozFest 2023 is December 16th 2022. https://www.mozillafestival.org/en/pro...I'm opening this ticket to coordinate the community team proposals for Mozfest.
Event: 8 to 20 June 2023, Amsterdam
CFP: The deadline to submit your proposal for MozFest 2023 is December 16th 2022. https://www.mozillafestival.org/en/proposals/2022-12-15https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/18Use domain fronted connection for registration2023-01-13T16:31:39ZCecylia BocovichUse domain fronted connection for registrationRight now we make a direct connection. This should be just a matter of getting details about the existing domain front set up and configuring the provided torrc file.Right now we make a direct connection. This should be just a matter of getting details about the existing domain front set up and configuring the provided torrc file.Ship Conjure in Alpha versions of Tor BrowserCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/91Scan existing bridges for the obfs4 distinguishability bug (pre-v0.0.12 obfs4...2023-01-10T21:18:55ZDavid Fifielddcf@torproject.orgScan existing bridges for the obfs4 distinguishability bug (pre-v0.0.12 obfs4proxy)tl;dr, this is nothing urgent. It's about a distinguishability bug in obfs4proxy that was fixed at the same time as another bug. The ticket is private because we have an opportunity to scan existing bridges for both bugs simultaneously, ...tl;dr, this is nothing urgent. It's about a distinguishability bug in obfs4proxy that was fixed at the same time as another bug. The ticket is private because we have an opportunity to scan existing bridges for both bugs simultaneously, and we might want to do that before public disclosure.
We have talked about [a bug in a package that obfs4proxy relied on](https://lists.torproject.org/pipermail/anti-censorship-team/2022-January/000213.html) that supposedly made handshakes distinguishable from random, and which, after being fixed in version v0.0.12, caused [probabilistic interoperability problems](tpo/applications/tor-browser#40804) when one side had upgraded and the other had not. I have been making progress at understanding the nature of the bug and the interoperability problems resulting from the fix. It should be possible to write a remote prober (or a passive distinguisher) to detect the bug, though it will require doing some actual elliptic curve math.
Something I have not seen discussed yet, and which I discovered only yesterday, is that old versions of obfs4proxy have another, distinct bug: **the most significant bit (the 255th bit, counting from 0) of Elligator-encoded ephemeral public keys is always 0**. Encoded public keys are 32 bytes long and are stored in little-endian order; therefore bit 255 is the most significant bit of byte 31. This bit is always 0 in any TCP stream produced by a pre-v0.0.12 obfs4proxy, client or server.
To be clear, there are two different bugs. Elligator-encoded keys are 254 bits long; the top 2 bits must be randomized separately, in order to get a uniformly random string of 32 bytes. The [noncanonical representative bug in agl/ed25519](https://github.com/agl/ed25519/issues/27), the bug we knew about, was that the second-most significant bit, bit 254, one of the two bits that encoding is supposed to leave unset, was sometimes set and sometimes not, in a way not statistically independent of the lower-order bits. This bug in obfs4proxy is that it does not randomize the most significant bit, bit 255, which instead remains 0, as it is output by the Elligator encoder. See the [`tweak` parameter](https://gitlab.com/yawning/obfs4/-/commit/393aca86cc3b1a5263018c10f87ece09ac3fd5ed#028a7e0fefce096ef9214e82412a8168b2514b5c_282_288) in the patched v0.0.12 code, and how it is used to [randomize the top 2 bits](https://gitlab.com/yawning/obfs4/-/blob/393aca86cc3b1a5263018c10f87ece09ac3fd5ed/internal/x25519ell2/x25519ell2.go#L133); that part is missing in versions before v0.0.12. Compare with ["It is the caller's responsibility to randomize the 2 high bits of the representative..."](https://github.com/Yawning/libelligator/commit/eeefe989f9ced861cb6239eca0632b511aa498cb#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R26) in libelligator.
The bit that is always 0 makes for an easy distinguisher that doesn't require any math: watch connections to a suspected server, and if the 255th bit is always 0, the server is pre-v0.0.12 obfs4proxy. It works for clients too, because the obfs4 protocol has both [clients](https://gitlab.com/yawning/obfs4/-/blob/obfs4proxy-0.0.13/doc/obfs4-spec.txt#L163) and [servers](https://gitlab.com/yawning/obfs4/-/blob/obfs4proxy-0.0.13/doc/obfs4-spec.txt#L218) send Elligator-encoded ephemeral public keys at the same place in the stream. If you know a server's node ID and public key (which are encoded in the `cert` parameter of the bridge line), you can even actively scan the server to see if it is affected.
The good news is that both bugs were fixed in the [same commit](https://gitlab.com/yawning/obfs4/-/commit/393aca86cc3b1a5263018c10f87ece09ac3fd5ed), which overhauled how Elligator is done in obfs4proxy. Therefore you can remotely scan an obfs4 server, and if it is free of the always-0 bug, it is also free of the noncanonical representative bug. Below is a program to scan for the always-0 bug. You provide it a host:port address and the `cert` parameter from a bridge line. The program connects to the server 20 times, and if bit 255 is 0 all 20 times it outputs "FAIL"; otherwise it outputs "PASS".
```python
#!/usr/bin/env python3
# Usage: obfs4-bug-check 192.95.36.142:443 qUVQ0srL1JI/vO6V6m/24anYXiJD3QP2HgzUKQtQ7GRqqUvs7P+tG43RtAqdhLOALP7DJQ
import base64
import getopt
import hmac
import os
import socket
import re
import sys
import time
NUM_TRIALS = 20 # control with -n option
TIMEOUT = 5 # control with -t option
opts, (addr, cert) = getopt.gnu_getopt(sys.argv[1:], "n:t:")
for o, a in opts:
if o == "-n":
NUM_TRIALS = int(a)
elif o == "-t":
TIMEOUT = float(a)
host, port = re.match(r'^\[?(.*?)\]?:(\d+)$', addr).groups()
port = int(port)
cert = base64.b64decode(cert + "==="[:(4-len(cert)%4)%4])
nodeid = cert[:20]
pubkey = cert[20:]
assert len(nodeid) == 20
assert len(pubkey) == 32
def mac(msg):
return hmac.digest(pubkey + nodeid, msg, "sha256")[0:16]
def trial():
# https://gitlab.com/yawning/obfs4/-/blob/obfs4proxy-0.0.13/doc/obfs4-spec.txt#L156-163
repr = os.urandom(32)
padding = os.urandom(85)
mark = mac(repr)
epoch_hours = str(int(time.time()) // 3600).encode()
s = socket.create_connection((host, port), TIMEOUT)
try:
s.send(repr + padding + mark + mac(repr + padding + mark + epoch_hours))
r = s.recv(32)
return (r[31] & 0x80) != 0
finally:
s.close()
num_ones = 0
err = None
try:
for _ in range(NUM_TRIALS):
if trial():
dot = "1"
num_ones += 1
else:
dot = "."
print(dot, flush = True, end = "")
except Exception as e:
print("X", flush = True, end = "")
err = e
report = ("ERROR", str(err))
else:
report = ("PASS" if num_ones > 0 else "FAIL", f"{num_ones}/{NUM_TRIALS}")
print(*(("", addr) + report))
if err is not None:
sys.exit(2)
elif num_ones == 0:
sys.exit(1)
else:
sys.exit(0)
```
## Tests of existing bridges
I grabbed three bridges from bridges.torproject.org and scanned them. Two of them had not upgraded and had bit 255 stuck at 0.
```
$ perl -an -e '/^obfs4 (\S*) (?:\S+) cert=(\S+)/ && print "$1 $2\n";' bridges.txt | while read addr cert; do ./obfs4-bug-check $addr $cert; done
.................... 185.31.174.60:443 FAIL 0/20
.................... 142.132.237.143:2538 FAIL 0/20
1.111...1...1..11..1 90.127.32.238:42024 PASS 9/20
```
All the default Tor Browser bridges have upgraded:
```
$ perl -an -e '/^obfs4 (\S*) (?:\S+) cert=(\S+)/ && print "$1 $2\n";' tor-browser-build/projects/common/bridges_list.obfs4.txt | while read addr cert; do ./obfs4-bug-check $addr $cert; done
1..111.111.11.1111.. 192.95.36.142:443 PASS 13/20
1.111.111.11..1.1111 38.229.1.78:80 PASS 14/20
1..111.1.1.11....11. 38.229.33.83:80 PASS 10/20
.11111..11.....1..11 37.218.245.14:38224 PASS 10/20
11..111.11....111..1 85.31.186.98:443 PASS 11/20
1111...1.1111.1.111. 85.31.186.26:443 PASS 13/20
1.1.111.1111..1111.. 193.11.166.194:27015 PASS 13/20
11..1.....111.1.1111 193.11.166.194:27020 PASS 11/20
.111.1....11.......1 193.11.166.194:27025 PASS 7/20
...1.....11..111.111 209.148.46.65:443 PASS 9/20
1111....1.1.111..... 146.57.248.225:22 PASS 9/20
1.11.1111.1.1....111 45.145.95.6:27015 PASS 12/20
..11..1...1.11...11. [2a0c:4d80:42:702::1]:27015 PASS 8/20
1.111..1..1111.1..1. 51.222.13.177:80 PASS 11/20
```
## How to reproduce locally
Build a pre-v0.0.12 version of obfs4proxy:
```
$ git clone https://gitlab.com/yawning/obfs4
$ cd obfs4/obfs4proxy
$ git checkout e330d1b7024b4ab04f7d96cc1afc61325744fafc
$ go build
```
Create this torrc file:
```
SocksPort 0
ORPort 127.0.0.1:auto
PublishServerDescriptor 0
BridgeRelay 1
DataDirectory datadir
ServerTransportListenAddr obfs4 127.0.0.1:12345
ServerTransportPlugin obfs4 exec ./obfs4proxy -unsafeLogging -logLevel DEBUG -enableLogging
```
Run tor:
```
$ tor -f torrc
```
Grab the `cert` parameter from datadir/pt_state/obfs4_bridgeline.txt. Run the bug checker script and see "FAIL":
```
$ ./obfs4-bug-check 127.0.0.1:12345 hNzHgvwEUmPV7PhuhRasLGyWx/TjnCIUxYcOQ7fDl2p7EmQ9Tm8EzLmuAtevceE6LoS9Dw
.................... 127.0.0.1:12345 FAIL 0/20
```
Stop the tor process. Build a post-v0.0.12 version of obfs4proxy:
```
$ git checkout 77af0cba934d73c4baeb709560bcfc9a9fbc661c
$ go build
```
Run tor again:
```
$ tor -f torrc
```
Run the bug checker script again and see "PASS":
```
$ ./obfs4-bug-check 127.0.0.1:12345 hNzHgvwEUmPV7PhuhRasLGyWx/TjnCIUxYcOQ7fDl2p7EmQ9Tm8EzLmuAtevceE6LoS9Dw
.1...11...1111111.11 127.0.0.1:12345 PASS 12/20
```meskiomeskio@torproject.orgmeskiomeskio@torproject.org2023-01-09https://gitlab.torproject.org/tpo/tpa/team/-/issues/40966order and ship servers for gnt-dal cluster in new datacenter2023-01-09T22:35:12Zanarcatorder and ship servers for gnt-dal cluster in new datacenteras per [TPA-RFC-43](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-43-cymru-migration-plan)as per [TPA-RFC-43](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-43-cymru-migration-plan)trusted high performance cluster (gnt-dal migration)Jérôme Charaouilavamind@torproject.orgJérôme Charaouilavamind@torproject.org2023-01-07https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/92Prepare for s28 PI and ECP presentations: Oct 31 and Nov 1-2 20222023-01-08T18:03:25ZRoger DingledinePrepare for s28 PI and ECP presentations: Oct 31 and Nov 1-2 2022In the tradition of https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62, we have another PI meeting coming up at the beginning of November, where we will want to present the current state of Tor anti-censorship, the situat...In the tradition of https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62, we have another PI meeting coming up at the beginning of November, where we will want to present the current state of Tor anti-censorship, the situation with deployment and usage of our pluggable transports (obfs4 and snowflake in particular), what we're up to next, etc.
The text from the previous ticket is still a good summary of info I'll be trying to collect and present:
* (0) Did we make any changes to the Snowflake architecture as deployed on Race? Did we find and/or fix any especially interesting Snowflake-on-Race issues? It's fine if the answer here is "no, we did all the hard work last year, this time it was clear sailing".
* (1) Our deployed transports (Snowflake, obfs4, and meek/moat):
* user-evident dev progress (security and obfuscation fixes, new features, performance changes)
* adoption (trends in growth of users or capacity or load; or different countries joining the story)
* (2) Task Area One (censorship analysis) progress. Who is censoring components of the Tor ecosystem, how, when, where, for how long?
* (3) Task Area Two (reputation-based bridge distribution strategies) progress.
* (4) Progress on our anti-censorship roadmap tasks. We don't need to make progress on every one of them, but we should have something impressive on some of them. Here are some highlights from the Q1 roadmap where progress would count as interesting:
* Snowflake performance (especially in Asia)
* Conjure and httpt
* Scale Tor reachability through mobile Snowflakes
* React and steer our response to censorship
* Monitor bridge health
* Improved UX for users getting bridges in practice (e.g. "Make it easier for humans & harder for censors to get bridges from moat distributor.", "Improve automatic censorship detection during bootstrapping in Tor Browser (desktop and Android)")
* (5) Collaborations or interactions with external anti-censorship research groups or NGOs that caused (or that we think will cause) the world to become a better place wrt censorship. This one is broad, and we've been too busy and too small to interact much lately, but I have it on the list here in case we notice something, and because hopefully in future iterations we'll start having some answers.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Roger DingledineRoger Dingledine2022-10-28https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41515Letterboxing can change by a few px unnecessarily when opening find bar.2023-01-05T12:16:53ZhenryLetterboxing can change by a few px unnecessarily when opening find bar.## Steps to reproduce
1. Open a web page.
2. Resize the window so you have some significant letterbox padding at the bottom that can fit the find bar.
3. Open and close the find bar with Ctrl+F and Esc respectively.
## Result
The lett...## Steps to reproduce
1. Open a web page.
2. Resize the window so you have some significant letterbox padding at the bottom that can fit the find bar.
3. Open and close the find bar with Ctrl+F and Esc respectively.
## Result
The letterbox padding jumps up and down by a few pixels during the transition. This is measurable by `window.innerHeight`.
## Expect
The letterbox size should remain the same whilst the find bar is being revealed or closed.
## Cause?
I think this may have something to do with the findbar's CSS `transition` properties. During the transition the findbar is changing in size.ma1ma1https://gitlab.torproject.org/tpo/core/arti/-/issues/210tor-circmgr test "request_retried" is not reliable2023-01-04T13:24:11ZNick Mathewsontor-circmgr test "request_retried" is not reliableAt https://gitlab.torproject.org/nickm/arti/-/jobs/45855 I see:
```
...
thread 'mgr::test::request_retried' panicked at 'called `Result::unwrap()` on an `Err` value: RequestFailed(RetryError { doing: "find or build a circuit", errors: []...At https://gitlab.torproject.org/nickm/arti/-/jobs/45855 I see:
```
...
thread 'mgr::test::request_retried' panicked at 'called `Result::unwrap()` on an `Err` value: RequestFailed(RetryError { doing: "find or build a circuit", errors: [], n_errors: 0 })', crates/tor-circmgr/src/mgr.rs:1575:25
advancing released: circuit builder task 6132487541863617059
failures:
mgr::test::request_retried
```
I couldn't reproduce this just by running this test on its own, but I managed to get it to reoccur by running all of the tor-circmgr tests in a loop:
```
; while cargo test -p tor-circmgr ; do : ; done
...
sleeper made for 59.97s, 64/65
sleeper dropped, incrementing count
sleeper polled, 65/65
setting advance flag
waitfor done!
thread 'mgr::test::request_retried' panicked at 'called `Result::unwrap()` on an `Err` value: RequestFailed(RetryError { doing: "find or build a circuit", errors: [], n_errors: 0 })', crates/tor-circmgr/src/mgr.rs:1575:25
```Arti 1.0.0: Ready for production usehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/17Adjust proxy poll rate to match increased client load2023-01-02T16:53:55ZCecylia BocovichAdjust proxy poll rate to match increased client loadLooking at recent [stats from the broker](https://metrics.torproject.org/collector.html#snowflake-stats), we're starting to get situations where clients are polling for proxies and not getting any available ones. Here's a visualization o...Looking at recent [stats from the broker](https://metrics.torproject.org/collector.html#snowflake-stats), we're starting to get situations where clients are polling for proxies and not getting any available ones. Here's a visualization of data from September and October:
![matches](/uploads/283bec922aaaca4037d7e82a1e189ac9/matches.png)
It looks like the number of proxies has stayed about the same for several months, around 6000:
![proxies](/uploads/2943bf3a7fe5278a97960a4db0128445/proxies.png)
But our client poll rates have gone up substantially.
I suggest decreasing both the `defaultBrokerPollInterval` and the `pollAdjustment`. We might want to get rid of the latter eventually since it didn't seem to help at all with snowflake#33666Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/45Daily number of users helped gone to zero.2023-01-02T16:07:01ZcypherpunksDaily number of users helped gone to zero.Ever since the update to version 0.6.0 of the Webextension, I've stopped seeing active or past connections. I only got a single connected user a few hours ago, several days after I updated to this version. I'm used to seeing around 5-15 ...Ever since the update to version 0.6.0 of the Webextension, I've stopped seeing active or past connections. I only got a single connected user a few hours ago, several days after I updated to this version. I'm used to seeing around 5-15 users helped daily.
Maybe there are practically no users connecting to my snowflake, or they are connecting but aren't being counted properly anymore.
I see "Distributed Snowflake Server Support" in the version release notes. Could this have something to do with this?shelikhooshelikhoohttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40630Update builtin bridges from Circumvention Settings API2022-12-22T11:22:11Zmeskiomeskio@torproject.orgUpdate builtin bridges from Circumvention Settings APIRight now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/m...Right now to update the builtin bridges we need to make a Tor Browser release, it would be nice if TB automatically updates them using [Circumvention Settings API](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/moat.md#circumventionbuiltin).
There are two concerns I have about it:
* Users will not be happy with TB making a call to an external API without giving some consent about it.
* We don't want to make easier for censors to notice you are using Tor because of that.
I think it makes sense to update when we do other connections to moat (Connect Assist, captcha bridges, ...), I assume user has already consent to do a request to the API on those cases and having an extra connection over the domain fronting should not make it more noticeable than it already is. We could store when was the last time we had updated them, and don't update them is they are fresh (maybe 24h is a good freshness).
An extra that would be nice is to ask the user if they want to refresh the builtin bridges when they click on Settings to *Select a Built-In Bridge*. I think we should only ask if bridges hasn't being refreshed for a while (maybe 7days). The confirmation popup could have a check box with 'remember that option' or something like that, so the following times they enable builtin bridges we refresh or not without asking (if the bridges hasn't being refreshed in 7days).Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40504mullvad-browser required tor-browser-build changes2022-12-22T11:20:04Zrichardmullvad-browser required tor-browser-build changesThe mullvad-browser equivalent to the base-browser work from Phase 1 ( https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40498 )The mullvad-browser equivalent to the base-browser work from Phase 1 ( https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40498 )Sponsor 131 - Phase 2 - Privacy Browserboklmboklmhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/19914DMARC causing trouble with Tor lists, From should be munged2022-12-10T03:21:37ZstarlightDMARC causing trouble with Tor lists, From should be mungedTor Project list server does not remove DKIM headers and reliably modifies the Subject: header in such a manner as to produce DKIM validation failures. Beyond adding a prefix which can be anticipated by conscientious senders, spaces are...Tor Project list server does not remove DKIM headers and reliably modifies the Subject: header in such a manner as to produce DKIM validation failures. Beyond adding a prefix which can be anticipated by conscientious senders, spaces are injected at unpredictable offsets. This badly degrades spam-scoring of messages by Google and other ESPs and frequently results in the sending of list messages to spam folders.
My recommendation is that the list server configuration be set to completely strip DKIM headers from forwarded messages.
Possibly if the list server software supports it, a DKIM-signed RFC-7001 Authentication-Results: header might be added though it seems to me the positive effect on spam scoring would be minor, where in comparison not stripping DKIM headers results in a substantial negative impact.anarcatanarcat2021-09-14https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40928Mullvad Browser branding patches in mullvad-browser branch2022-12-09T14:18:20ZrichardMullvad Browser branding patches in mullvad-browser branchWe need to identify all of the branding we have replaced in tor-browser, and make an equivalent branding commit in mullvad-browser that replaces with Mullvad provided icons, colors, etc, etcWe need to identify all of the branding we have replaced in tor-browser, and make an equivalent branding commit in mullvad-browser that replaces with Mullvad provided icons, colors, etc, etcSponsor 131 - Phase 2 - Privacy Browserdonutsdonutshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41434Letterboxing bypass through secondary tab (popup/popunder...)2022-12-08T17:41:30Zma1Letterboxing bypass through secondary tab (popup/popunder...)We should apply letterboxing to about:blank (we currently do not) because any web page can read the DOM of a new window/tab it creates.
And even if we do, current letterboxing implementation seems to have a race condition allowing the op...We should apply letterboxing to about:blank (we currently do not) because any web page can read the DOM of a new window/tab it creates.
And even if we do, current letterboxing implementation seems to have a race condition allowing the opener to bypass letterboxing.
PoC:
https://people.torproject.org/~ma1/bugs/lb/
@richard , @pierovSponsor 131 - Phase 5 - Ongoing Maintenancema1ma1https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40317Tor Browser Icon Too Similar to Apple Podcasts2022-12-08T15:15:31ZrgreenstadtTor Browser Icon Too Similar to Apple Podcasts
Dear Tor UX Team,
Roger told me to file a ticket instead of whining to him that half the time I try to open Tor I open apple podcasts on my mac instead because the icons are very similar (purple with concentric white rings). This is qu...
Dear Tor UX Team,
Roger told me to file a ticket instead of whining to him that half the time I try to open Tor I open apple podcasts on my mac instead because the icons are very similar (purple with concentric white rings). This is quite annoying to me. I don't know if it causes problems for others.
-Rachel
Link to podcast icon (in the launch bar it is also round which adds to the confusion).
https://www.nicepng.com/ourpic/u2q8r5r5q8o0u2e6_itunes-listen-on-apple-podcast-logo-png/donutsdonutshttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/3994Get TorBrowser in Debian2022-12-08T15:15:26ZLunarGet TorBrowser in DebianTorbutton as pure Firefox extension is now deprecated. The project now advocates to use TorBrowserBundle instead.
For users of Debian (and its derivative, Tails being one of them), it would probably be good to offer a more streamlined e...Torbutton as pure Firefox extension is now deprecated. The project now advocates to use TorBrowserBundle instead.
For users of Debian (and its derivative, Tails being one of them), it would probably be good to offer a more streamlined experience and ship TorBrowser as a Debian package.
In order to preserve the anonymity set, this browser should work as close as possible to the one shipped in the TorBrowserBundle.
The Debian policy states that a package should not contain any embedded code copy. So simply shipping the result of TorBrowserBundle build is not an option.
Mike Hommey (maintainer of Iceweasel) and Moritz Muehlenhoff (from the security team) are both ok to create a `iceweasel-src` package that would contain the source files needed to build a patched Firefox. A Debian package could apply specific Tor patches on top of that to build something close to core TorBrowser.
The rest of the features are provided through Firefox extensions. TBB is currently shipped HTTPS-Everywhere, NoScript and Torbutton. All of these extensions are already in Debian.
Having TorBrowser installed system-wide do open a new class of problems, though:
* Profiles should probably be saved in a different directory in user $HOME than Iceweasel or official Firefox.
* The ideal way to deal with system-wide extensions would probably be that: a new profile would start with all system extensions disabled except for the one shipped in TBB. By going through the Add-ons panel, user could re-enable more of them (even those that could lead to anonymity breaches).
Once a tor-browser binary package is in Debian, we can also have it depend on Vidalia and have a TorBrowser icon start the later, like TBB does.
I hope I have not overlooked anything on the various issues involved…https://gitlab.torproject.org/tpo/web/community/-/issues/290[Training] Draft trainer's guide for "Introduction to Onion Services"2022-12-08T13:56:30Zraya[Training] Draft trainer's guide for "Introduction to Onion Services"Since the [training page](/tpo/web/community/-/blob/main/community.torproject.org/training/resources) is going to be [revamped](https://gitlab.torproject.org/tpo/web/community/-/issues/265) to include a trainer's guide for each material ...Since the [training page](/tpo/web/community/-/blob/main/community.torproject.org/training/resources) is going to be [revamped](https://gitlab.torproject.org/tpo/web/community/-/issues/265) to include a trainer's guide for each material created and maintained by the Tor Project, I will be drafting the training guide for "Introduction to Onion Services" as per the following structure:
- [ ] Maintained by
- [ ] Last updated
- [ ] Estimated time
- [ ] Long description
- [ ] Learning objectives
- [ ] Sample slides: list of formats and languages
- [ ] Topic tags
- [ ] Suggested activities
- [ ] Collecting user feedbackrayarayahttps://gitlab.torproject.org/tpo/web/community/-/issues/289[Training] Draft trainer's guide for "Running Tor Bridges"2022-12-08T13:56:16Zraya[Training] Draft trainer's guide for "Running Tor Bridges"Since the [training page](/tpo/web/community/-/blob/main/community.torproject.org/training/resources) is going to be [revamped](https://gitlab.torproject.org/tpo/web/community/-/issues/265) to include a trainer's guide for each material ...Since the [training page](/tpo/web/community/-/blob/main/community.torproject.org/training/resources) is going to be [revamped](https://gitlab.torproject.org/tpo/web/community/-/issues/265) to include a trainer's guide for each material created and maintained by the Tor Project, I will be drafting the training guide for "Running Tor Bridges" as per the following structure:
- [x] Maintained by
- [ ] Last updated
- [x] Estimated time
- [x] Long description
- [x] Learning objectives
- [x] Sample slides: list of formats and languages
- [x] Topic tags
- [ ] Suggested activities
- [ ] Collecting user feedbackrayarayahttps://gitlab.torproject.org/tpo/web/community/-/issues/288[Training] Draft trainer's guide for "The Tor Network"2022-12-08T13:56:10Zraya[Training] Draft trainer's guide for "The Tor Network"Since the [training page](/tpo/web/community/-/blob/main/community.torproject.org/training/resources) is going to be [revamped](https://gitlab.torproject.org/tpo/web/community/-/issues/265) to include a trainer's guide for each material ...Since the [training page](/tpo/web/community/-/blob/main/community.torproject.org/training/resources) is going to be [revamped](https://gitlab.torproject.org/tpo/web/community/-/issues/265) to include a trainer's guide for each material created and maintained by the Tor Project, I will be drafting the training guide for "The Tor Network" as per the following structure:
- [ ] Maintained by
- [ ] Last updated
- [ ] Estimated time
- [ ] Long description
- [ ] Learning objectives
- [ ] Sample slides: list of formats and languages
- [ ] Topic tags
- [ ] Suggested activities
- [ ] Collecting user feedbackrayaraya