Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T18:30:06Zhttps://gitlab.torproject.org/legacy/trac/-/issues/34322Make BridgeDB's web interface look like torproject.org2020-06-13T18:30:06ZPhilipp Winterphw@torproject.orgMake BridgeDB's web interface look like torproject.orgBridgeDB's web interface at bridges.torproject.org uses bootstrap, with its own look and feel. We should make it look like torproject.org. Antonela suggested that this may be as simple as loading torproject.org's CSS on top of the existi...BridgeDB's web interface at bridges.torproject.org uses bootstrap, with its own look and feel. We should make it look like torproject.org. Antonela suggested that this may be as simple as loading torproject.org's CSS on top of the existing CSS files.https://gitlab.torproject.org/legacy/trac/-/issues/33945Failed assertion breaks BridgeDB's email responder2020-06-13T18:30:02ZPhilipp Winterphw@torproject.orgFailed assertion breaks BridgeDB's email responderBridgeDB's email responder stops working after a while. The issue is probably related to the exception below but I don't know how exactly. As part of our Python 3 port, we [modifed the context manager](https://gitweb.torproject.org/bridg...BridgeDB's email responder stops working after a while. The issue is probably related to the exception below but I don't know how exactly. As part of our Python 3 port, we [modifed the context manager](https://gitweb.torproject.org/bridgedb.git/commit/?id=c1a48d1b568b00fab19a308e6497881f31d17680), which may be a good place to start debugging.
```
Unhandled Error
Traceback (most recent call last):
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/python/log.py", line 103, in callWithLogger
return callWithContext({"system": lp}, func, *args, **kw)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/python/log.py", line 86, in callWithContext
return context.call({ILogContext: newCtx}, func, *args, **kw)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/python/context.py", line 122, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/python/context.py", line 85, in callWithContext
return func(*args,**kw)
--- <exception caught here> ---
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/internet/posixbase.py", line 614, in _doReadOrWrite
why = selectable.doRead()
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/internet/tcp.py", line 243, in doRead
return self._dataReceived(data)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/internet/tcp.py", line 249, in _dataReceived
rval = self.protocol.dataReceived(data)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/protocols/basic.py", line 454, in dataReceived
self.lineReceived(line)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/mail/smtp.py", line 445, in lineReceived
return getattr(self, 'state_' + self.mode)(line)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/mail/smtp.py", line 705, in dataLineReceived
m.eomReceived() for m in self.__messages
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/twisted/mail/smtp.py", line 705, in <listcomp>
m.eomReceived() for m in self.__messages
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/distributors/email/server.py", line 230, in eomReceived
self.responder.reply()
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/distributors/email/autoresponder.py", line 574, in reply
response = self.getMailData()
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/distributors/email/autoresponder.py", line 392, in getMailData
client, lang)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/distributors/email/autoresponder.py", line 101, in createResponseBody
bridges = context.distributor.getBridges(bridgeRequest, interval)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/distributors/email/distributor.py", line 145, in getBridges
with bridgedb.Storage.getDB() as db:
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/Storage.py", line 352, in __enter__
return next(self.gen)
File "/home/bridgedb/virtualenvs/bridgedb/lib/python3.7/site-packages/bridgedb-0.10.0+11.g4cdd6a61.dirty-py3.7.egg/bridgedb/Storage.py", line 472, in getDB
assert _REFCOUNT == 0
builtins.AssertionError:
```Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33835Gmail's quoted response confuses BridgeDB's email autoresponder2020-06-13T18:30:01ZPhilipp Winterphw@torproject.orgGmail's quoted response confuses BridgeDB's email autoresponderWhen replying to a BridgeDB email in Gmail's web interface, one ends up sending an email like this:
```
On Mon, Apr 6, 2020 at 2:12 PM <bridges@torproject.org> wrote:
>
> [This is an automated email. Please do not reply.]
>
> Here are ...When replying to a BridgeDB email in Gmail's web interface, one ends up sending an email like this:
```
On Mon, Apr 6, 2020 at 2:12 PM <bridges@torproject.org> wrote:
>
> [This is an automated email. Please do not reply.]
>
> Here are your bridges:
>
> [redacted]
>
> Add these bridges to your Tor Browser by opening your browser
> preferences, clicking on "Tor", and then adding them to the "Provide a
> bridge" field.
>
> If these bridges are not what you need, reply to this email with one of
> the following commands in the message body:
>
> get bridges (Request unobfuscated Tor bridges.)
> get ipv6 (Request IPv6 bridges.)
> get transport TYPE (Request obfuscated bridges. Replace TYPE with
> 'obfs4'.)
> get key (Get a copy of BridgeDB's public GnuPG key.)
>
>
>
--000000000000dde1a205a2a60f3e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">get transport obfs4<br></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 6, 2020 at 2:12 PM <=
<a href=3D"mailto:bridges@torproject.org">bridges@torproject.org</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
[This is an automated email.=C2=A0 Please do not reply.]<br>
<br>
Here are your bridges:<br>
<br>
=C2=A0 [redacted]<br>
<br>
Add these bridges to your Tor Browser by opening your browser<br>
preferences, clicking on "Tor", and then adding them to the "=
;Provide a<br>
bridge" field.<br>
<br>
If these bridges are not what you need, reply to this email with one of<br>
the following commands in the message body:<br>
<br>
=C2=A0 get bridges=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Request unobfu=
scated Tor bridges.)<br>
=C2=A0 get ipv6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(Requ=
est IPv6 bridges.)<br>
=C2=A0 get transport TYPE=C2=A0 =C2=A0 =C2=A0(Request obfuscated bridges. R=
eplace TYPE with 'obfs4'.)<br>
=C2=A0 get key=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (Get =
a copy of BridgeDB's public GnuPG key.)<br>
<br>
<br>
</blockquote></div>
--000000000000dde1a205a2a60f3e--
```
BridgeDB correctly ignores the commands that start with `>` but it doesn't ignore the commands that are encoded in quoted-printable. BridgeDB's email parser ends up [interpreting each line as command](https://gitweb.torproject.org/bridgedb.git/tree/bridgedb/distributors/email/request.py?h=develop&id=bca64964a255cf959489c7049c66e5eb70b5291c#n87), ending in "get key", which raises an exception, resulting in BridgeDB sending no response at all.
We should make sure that BridgeDB doesn't get confused by Gmail's quoted-printable response.Armin HuremagicArmin Huremagichttps://gitlab.torproject.org/legacy/trac/-/issues/33727Gmail marks emails from BridgeDB as spam2020-06-13T18:30:00ZPhilipp Winterphw@torproject.orgGmail marks emails from BridgeDB as spamI noticed that Gmail now tosses emails from BridgeDB's autoresponder into its spam folder:
![spam.cleaned.png, 100%](uploads/spam.cleaned.png, 100%)
BridgeDB's instructions should mention that users should take a look into their spam f...I noticed that Gmail now tosses emails from BridgeDB's autoresponder into its spam folder:
![spam.cleaned.png, 100%](uploads/spam.cleaned.png, 100%)
BridgeDB's instructions should mention that users should take a look into their spam folder if they didn't get a response. Ideally, we should find a way to prevent this from happening. I clicked the "Report not spam" button of every single BridgeDB email. I hope it will tell Gmail's classifier that this is a false positive.https://gitlab.torproject.org/legacy/trac/-/issues/33299Remove retired pluggable transports from BridgeDB2020-06-13T18:29:57ZPhilipp Winterphw@torproject.orgRemove retired pluggable transports from BridgeDBBridgeDB still hands out obfs3, ScrambleSuit, and FTE bridges. Tor Browser no longer supports FTE (see #29319), so we should remove it. I suggest also removing obfs3 and ScrambleSuit because these transports don't offer anything that obf...BridgeDB still hands out obfs3, ScrambleSuit, and FTE bridges. Tor Browser no longer supports FTE (see #29319), so we should remove it. I suggest also removing obfs3 and ScrambleSuit because these transports don't offer anything that obfs4 doesn't already provide.
As of today, BridgeDB knows about 1,316 bridges. Among these:
* 31 support FTE. 29 of these wouldn't be handed out because they also support obfs4 (see #28655). The remaining two bridges run FTE/obfs3 and ScrambleSuit/obfs3/FTE.
* 34 support ScrambleSuit. 32 of these also support obfs4 and only two don't. Instead, they run obfs3/ScrambleSuit and ScrambleSuit/obfs3/FTE.
* 106 support obfs3. Only seven of these don't support obfs4.
Considering the above, I think it's safe to retire FTE, ScrambleSuit, and obfs3.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32205Implement tor-button changes needed to take advantage of improved bridge info...2020-06-16T01:28:32ZrichardImplement tor-button changes needed to take advantage of improved bridge info query API in torSome changes to tor-button will be needed to properly display the information of user-provided bridges without a fingerprint in the circuit display. Whichever path outlined in #32204 is done, the work needed in Tor Browser is a minimal a...Some changes to tor-button will be needed to properly display the information of user-provided bridges without a fingerprint in the circuit display. Whichever path outlined in #32204 is done, the work needed in Tor Browser is a minimal amount of javascript in tor-button.https://gitlab.torproject.org/legacy/trac/-/issues/32204Create either a query or event-based API to allow controllers (particularly T...2020-06-16T01:28:32ZrichardCreate either a query or event-based API to allow controllers (particularly Tor Browser) to reliably get circuit informationCurrently we can not get the address or type of a bridge by id/fingerprint if the bridge entry in torrc does not have the fingerprint string provided. This info is needed for the circuit display in Tor Browser, which currently just displ...Currently we can not get the address or type of a bridge by id/fingerprint if the bridge entry in torrc does not have the fingerprint string provided. This info is needed for the circuit display in Tor Browser, which currently just displays 'Bridge' without the address or type information.
Tor Browser currently gets the circuit display information by first requesting the circuit for a given first-party domain/nonce pair. This returns an array of fingerprints. We then get the list of bridges stored in the torrc file via `GETCONF bridge`. We compare each bridge's id to each node in the circuit. If a match if sound we know the node is a bridge and we display its information. Otherwise, we assume it is a relay and we query the information from tor via `GETINFO ns/id/$fingerprint`.
With the change in #32125 we now infer that if the GETINFO call fails, it's because the id we've received is actually a Bridge whose info we do not know.
Some possible options:
- Tor updates the torrc with the Bridge's fingerprint once it is known. Tor Browser's logic doesn't change but there will be a window when a user looking at the circuit display will just see 'Bridge' rather than the full set of information.
- Tor adds a new query API that allows us to get Bridge information in a similar fashion to how we currently get relay information. The repeated GETCONF for bridges goes away and we now for each id in the circuit, we just try querying bridge info and if that fails we then query relay info.
- Tor Browser listens for the 'figured out the fingerprint for this bridge event' (which I believe currently just logs?) and maintains some in-memory map/cache of fingerprint to { type, ip, geolocation }. I'd really rather not do this.
- Add a 'verbose' circuit query API, where we just provide the domain/nonce pair and you give us the required data all at once. This would simplify Tor Browser code and would require less back-and-forth between tor and Tor Browser.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32134Request new translation and update i18n instructions2020-06-13T18:29:52ZPhilipp Winterphw@torproject.orgRequest new translation and update i18n instructionsWhile implementing our language switcher (#26543), we added a new string, "Language", that requires translations. We should also update our instructions on how to request new translations.While implementing our language switcher (#26543), we added a new string, "Language", that requires translations. We should also update our instructions on how to request new translations.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/31903Update translations and push translation requests to Transifex2020-06-13T18:29:48ZPhilipp Winterphw@torproject.orgUpdate translations and push translation requests to TransifexIt's time to update BridgeDB's existing translations and to push new translation requests because some of BridgeDB's strings have changed in the meanwhile.It's time to update BridgeDB's existing translations and to push new translation requests because some of BridgeDB's strings have changed in the meanwhile.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://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/31528Get rid of BridgeDB's "chatspeak"2020-06-13T18:29:44ZPhilipp Winterphw@torproject.orgGet rid of BridgeDB's "chatspeak"BridgeDB's UI uses a bunch of obscure "chatspeak" references in its UI. One example is that it responds with "Uh oh, spaghettios!" if there are currently no bridges available. While funny to some, this is difficult to translate and shoul...BridgeDB's UI uses a bunch of obscure "chatspeak" references in its UI. One example is that it responds with "Uh oh, spaghettios!" if there are currently no bridges available. While funny to some, this is difficult to translate and shouldn't be part of software that's used by an international audience. Let's simplify or remove these references.Armin HuremagicArmin Huremagichttps://gitlab.torproject.org/legacy/trac/-/issues/30941Need better instructions for requesting bridges via email2020-06-13T18:29:35ZPili GuerraNeed better instructions for requesting bridges via emailFor bridges obtained via email by emailing bridges@ it's not clear how/where to request bridges via email.
E.g the bridges.tpo website simply says to email bridges@ to get bridges
Emailing that address gives you a number of commands bu...For bridges obtained via email by emailing bridges@ it's not clear how/where to request bridges via email.
E.g the bridges.tpo website simply says to email bridges@ to get bridges
Emailing that address gives you a number of commands but doesn't specify where to send the commands (email subject, body...) I tried both and wasn't able to get it to work.
It also specifies that you can combine commands but it doesn't give any examples or indication of how to do so.
This was raised by a user and I also couldn't figure it out after trying for about 5 minutes :/Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30794Create lightweight censorship analyser for users2020-06-13T18:31:24ZPhilipp Winterphw@torproject.orgCreate lightweight censorship analyser for usersUsers occasionally show up on #tor and wonder why they are unable to connect to the network. We sometimes suspect censorship but it's often difficult to confirm this hypothesis. It would be useful to have a lightweight censorship analysi...Users occasionally show up on #tor and wonder why they are unable to connect to the network. We sometimes suspect censorship but it's often difficult to confirm this hypothesis. It would be useful to have a lightweight censorship analysis tool for users to run. Think of it as a small, specialised OONI: It should be a self-contained executable that tests if the user's computer can do the following:
* Connect to the TCP port of our directory authorities.
* Connect to the TCP port of a handful of relays.
* Connect to the TCP port of our default bridges.
* Resolve critical domains (e.g., bridges.tp.o) correctly.
* Fetch the index page of critical websites (e.g., bridges.tp.o) over HTTPS.
* Establish a TLS connection with a bridge authority and a relay.
* ...
The output of the tool can be a simple text file that the user can then email to us, or paste in a chat window. We originally had this idea several years ago and [documented it in a research paper](https://censorbib.nymity.ch/#Winter2013a) but nobody every followed up. Such a tool could also be useful as part of an anti-censorship rapid response process.
If this sounds like a good idea, then I suggest that we build the tool in Go because 1) we have several talented Go hackers, 2) Go binaries are self-contained, and 3) [since Go 1.5](https://github.com/golang/go/wiki/WindowsCrossCompiling), cross-compiling for Windows seems relatively simple.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/30317Update howto on https://bridges.torproject.org/ to take mobile Tor Browser in...2020-06-13T18:29:31ZGeorg KoppenUpdate howto on https://bridges.torproject.org/ to take mobile Tor Browser into accountTor Browser on Android is a thing and will be even more so shortly when we'll release the first stable release. However, the instructions on https://bridges.torproject.org/howto are desktop-only. We need to adapt the text so that mobile ...Tor Browser on Android is a thing and will be even more so shortly when we'll release the first stable release. However, the instructions on https://bridges.torproject.org/howto are desktop-only. We need to adapt the text so that mobile Tor Browser users need to know as well how they should add bridges obtained to their Tor Browser.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/28531Publish a snapshot of what PTs are needed for successful Tor use in each country2020-06-13T18:29:47ZRoger DingledinePublish a snapshot of what PTs are needed for successful Tor use in each countrySeveral countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic curre...Several countries have deployed censorship that includes trying to block Tor in various ways. And places change their censorship over time. What does the big picture look like today?
We have a scattering of resources on this topic currently, e.g.:
* OONI has "vanilla Tor" measurements in some countries.
* We have anecdotal stories from talking to users in various places.
* There's the censorship wiki: https://trac.torproject.org/projects/tor/wiki/doc/OONI/censorshipwiki (#6149)
* metrics-timeline has something similar: https://trac.torproject.org/projects/tor/wiki/doc/MetricsTimeline
* And the Berkeley folks wrote up their own Tor censorship timeline: https://www.icsi.berkeley.edu/~sadia/tor_timeline.pdf
But what is the situation, this month, in every country? Which ones block the Tor directory authorities, which ones block the public relays, which ones block the default (i.e. included in tor browser) bridges, which ones enumerate bridges from bridges.torproject.org and block them by IP address, which ones use DPI to detect and cut various pluggable transport connections, which ones throttle protocols they don't want, etc?
When Venezuela's CANTV ISP did their IP address based blocking, they also blocked the default obfs4 bridges, which led to confusion and then unfortunate headlines like the one from Access: "Venezuela blocks Tor". (Tor worked fine if you got a fresh bridge, even a vanilla bridge.)
In Taipei I talked to some central asia experts who told me about how Tor only works in a degraded way in Belarus in the default configuration "because a few years ago they blocked all the relay IP addresses, but they haven't updated their block since then".
We need up-to-date information about Tor blocking to provide advice to our users when they ask for support, and also we want it for preemptively including good advice in Tor Launcher's UI. Knowing historical trends will help us prioritize the development of new pluggable transports vs new distribution methods of existing transports.
So, how do we get this information?
One option is that in the glorious future, the standard OONI decks will have all of these tools built-in. But that future is a long way off, and maybe it should never even arrive, since some Tor transports are huge and have no business being bundled into a little mobile testing app.
I think we instead want some combination of the following two plans:
* We have on-the-ground contacts in many countries, and it's often not just individuals but whole NGOs full of Tor enthusiasts. We should pull together our knowledge of who we know in each place, and ask them what they think the current situation is in their country, and talk to them regularly. We can prioritize the various countries that we think were, are, or might be trying to block Tor. Having these on-the-ground experts is going to be necessary no matter what else we add to the plan, and it's why I picked 'community outreach' as the ticket component.
* We should build automated tools to assist people in assessing Tor censorship on their network -- to increase the accuracy of reports that we get, and to make the reports come with actual data that we can compare over time. This idea is #23839.
This ticket is for pulling together one big-picture report. But once we have one, we will want to find ways of keeping ourselves up to date over time.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/26543Provide a language switcher menu on BridgeDB2020-06-13T18:29:16ZteorProvide a language switcher menu on BridgeDB"As a side note, that page always loads in my native language with no way to switch to English -- pages which do this are the worst. In this case it means I can't usefully copy-paste you the exact error messages that I get."
https://lis..."As a side note, that page always loads in my native language with no way to switch to English -- pages which do this are the worst. In this case it means I can't usefully copy-paste you the exact error messages that I get."
https://lists.torproject.org/pipermail/tor-relays/2018-June/015512.htmlPhilipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24607CAPTCHAs on BridgeDB seem to be getting more difficult2020-06-13T18:29:07ZAlison MacrinaCAPTCHAs on BridgeDB seem to be getting more difficultI just tried to solve 12 CAPTCHAs unsuccessfully before I got to one that worked. In each, at least one or two characters was impossible to discern.I just tried to solve 12 CAPTCHAs unsuccessfully before I got to one that worked. In each, at least one or two characters was impossible to discern.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/19839BridgeDB website: In firefox page shows titles in English and text in the lan...2020-06-13T18:28:41ZTracBridgeDB website: In firefox page shows titles in English and text in the language preferred by the userBrowsing to https://bridges.torproject.org/ from Germany using an English Firefox, I am served a page that shows headlines in English, but the rest (as far as I checked) is in German. The German text is not bad but should be improved in ...Browsing to https://bridges.torproject.org/ from Germany using an English Firefox, I am served a page that shows headlines in English, but the rest (as far as I checked) is in German. The German text is not bad but should be improved in some places as it seems too close to the English original with some incorrect translation choices. As a native speaker and also long-standing translator/interpreter for Digitalcourage and the CCC I’d be happy to help. (And since this ticket will apparently be “owned” by Isis, I’d like to add that I’m hugely looking forward to being her interpreter for her upcoming talk at Digitalcourage’s “Public Domain” event. ☺)
**Trac**:
**Username**: sebalistraumschuletraumschulehttps://gitlab.torproject.org/legacy/trac/-/issues/19774bridges.torproject.org could use a favicon2020-06-13T18:28:39ZIsis Lovecruftbridges.torproject.org could use a faviconIt doesn't have one. It could. I don't particularly care what it is, but a little bridge or a little onion might be cute.It doesn't have one. It could. I don't particularly care what it is, but a little bridge or a little onion might be cute.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/17626BridgeDB's email distributor doesn't work if the "get help" text is quoted2020-06-13T18:28:35ZIsis LovecruftBridgeDB's email distributor doesn't work if the "get help" text is quotedLinda and David have been doing studies of user behaviours in laboratory censored environments. One user did:
> 1. Sent "get bridges" in the subject line with a blank body. Didn't
> work because the body was blank. Got a reply with t...Linda and David have been doing studies of user behaviours in laboratory censored environments. One user did:
> 1. Sent "get bridges" in the subject line with a blank body. Didn't
> work because the body was blank. Got a reply with the help message.
> 2. Replied to the help message, typing "get bridges" into the body.
> Didn't work because Gmail quoted the help reply below the "get
> bridges" line.
> 3. Sent a brand new fresh email with a blank subject and "get bridges"
> in the body. It worked that time.
For !#1, I am not sure what to do. The bots which try to scrape BridgeDB usually try use the subject line and have a blank body, and that was the original reason for ignoring the subject line. The second reason is that we require DKIM for the email providers we accept (mail.riseup.net, mail.yahoo.com, gmail.com), and while a provider can configure DKIM signing for the "Subject:" header, it is generally only the case that "From:", "To:", and "CC:" are signed. If we were to use the "Subject:" line when it's not DKIM-signed, we would be allowing any server handling the email en route to modify it, potentially doing things like giving the user a different type of bridges than they actually wanted, or attempting in some way to get the user blocked without them getting any bridges.
For !#2, if this is default Gmail behaviour, then BridgeDB certainly should not be forcing users to learn that they must erase the auto-quoted help text. This part is definitely bad UX and therefor a bug.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.org