Opened 5 years ago

Closed 5 years ago

#12895 closed defect (fixed)

add @riseup.net to Bridge Relay Help

Reported by: mcs Owned by: mcs
Priority: Medium Milestone:
Component: Applications/Tor Launcher Version:
Severity: Keywords: TorBrowserTeam201408
Cc: brade, isis, mikeperry, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We need to mention @riseup.net on Tor Launcher's Bridge Relay Help screen. In #11139, Mike said:

I think this is a good idea, but if we're going to change the Tor Launcher strings, we should try to future proof it, especially if stuff like #11140 is on the table (though I would prefer limiting the yahoo bridge pool instead of completely removing it), or we want to add new providers later.

Here's the two entities I think we should use instead of the current single entity:

<!ENTITY torsettings.bridgeHelp3.emailDesc "Send email to bridges@torproject.org with the line 'get bridges' by itself in the body of the message.&#160; However, to make it harder for an attacker to learn a lot of bridge addresses, you must send this request from one of the following email address providers (listed in order of preference):">
<!ENTITY torsettings.bridgeHelp3.emailList "https://www.riseup.net, https://mail.google.com, or https://mail.yahoo.com">

This will produce:

Send email to bridges@torproject.org with the line 'get bridges' by itself 
in the body of the message. However, to make it harder for an attacker to 
learn a lot of bridge addresses, you must send this request from one of 
the following email address providers (listed in order of preference):
https://mail.riseup.net, https://mail.google.com, or https://mail.yahoo.com

How is that? Can we make the differing expense of crawling these three any more clear with different (yet concise) text?

Child Tickets

Change History (6)

comment:1 Changed 5 years ago by mcs

I like Mike's proposal to split the text into two entities. I am a little concerned that using the web addresses for the email providers may be confusing, at least in the case of Gmail. Here is an alternative proposal:

Send email to bridges@torproject.org with the line 'get bridges' by itself in the
body of the message.  However, to make it harder for an attacker to learn a lot
of bridge addresses, you must use an email address that ends with one of the
following to send your request (listed in order of preference):
   @riseup.net, @gmail.com, or @yahoo.com

So which is better? Listing things by @email.domain or using the web addresses? Any other ideas?

comment:2 Changed 5 years ago by mcs

Keywords: TorBrowserTeam201408 added

comment:3 in reply to:  1 ; Changed 5 years ago by isis

Status: newneeds_information

Replying to mcs:

I like Mike's proposal to split the text into two entities. I am a little concerned that using the web addresses for the email providers may be confusing, at least in the case of Gmail. Here is an alternative proposal:

Send email to bridges@torproject.org with the line 'get bridges' by itself in the
body of the message.  However, to make it harder for an attacker to learn a lot
of bridge addresses, you must use an email address that ends with one of the
following to send your request (listed in order of preference):
   @riseup.net, @gmail.com, or @yahoo.com

So which is better? Listing things by @email.domain or using the web addresses? Any other ideas?


Saying that users need an address ending in @riseup.net, @gmail.com, or @yahoo.com is bit more of an untruth than saying that they need to use one of those providers, because BridgeDB will canonicalise the sender's address on an incoming email and it is currently configured to accept alternate domains (i.e. @googlemail.com).

Is it not possible to do URL links within a XUL <!ENTITY>? Because then we could say Riseup with a link to https://mail.riseup.net, etc., as how BridgeDB does it.

comment:4 in reply to:  3 ; Changed 5 years ago by mcs

Replying to isis:

Saying that users need an address ending in @riseup.net, @gmail.com, or @yahoo.com is bit more of an untruth than saying that they need to use one of those providers, because BridgeDB will canonicalise the sender's address on an incoming email and it is currently configured to accept alternate domains (i.e. @googlemail.com).

Thanks for your insight. In that case, listing the web addresses is better – we will use Mike's text.

Is it not possible to do URL links within a XUL <!ENTITY>? Because then we could say Riseup with a link to https://mail.riseup.net, etc., as how BridgeDB does it.

While it is possible to provide clickable links, they would only work if tor has already finished bootstrapping... which will not always be true (and it will never be true during Tor Launcher's initial wizard-based configuration).

comment:5 in reply to:  4 Changed 5 years ago by isis

Replying to mcs:

Replying to isis:

Saying that users need an address ending in @riseup.net, @gmail.com, or @yahoo.com is bit more of an untruth than saying that they need to use one of those providers, because BridgeDB will canonicalise the sender's address on an incoming email and it is currently configured to accept alternate domains (i.e. @googlemail.com).

Thanks for your insight. In that case, listing the web addresses is better – we will use Mike's text.

Is it not possible to do URL links within a XUL <!ENTITY>? Because then we could say Riseup with a link to https://mail.riseup.net, etc., as how BridgeDB does it.

While it is possible to provide clickable links, they would only work if tor has already finished bootstrapping... which will not always be true (and it will never be true during Tor Launcher's initial wizard-based configuration).


Oh, right. I'm sorry, I'd forgotten that problem. I'm not sure how to proceed with the linking then, perhaps someone else has a better idea.

comment:6 Changed 5 years ago by mcs

Resolution: fixed
Status: needs_informationclosed

Fix committed:
https://gitweb.torproject.org/tor-launcher.git/commit/c1a09372770adb8a3f7085f69eca2fecae7c1107

We can always revisit the idea of adding clickable links again in the future, but we want to commit this ASAP so translators have time to work on the new strings.

Note: See TracTickets for help on using tickets.