Project

General

Profile

Feature #8825

Provide default bridges

Added by sajolida almost 5 years ago. Updated almost 2 years ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Tor configuration
Target version:
-
Start date:
01/30/2015
Due date:
% Done:

0%

Feature Branch:
feature/8825-default-meek-bridges
Type of work:
Research
Blueprint:
Starter:
Affected tool:
Tor Launcher

Description

In Tor Launcher outside of Tails, there is an option to "Connect with provided bridges". But we don't have this in Tails.

This introduces a small chicken'and'egg problem as if you want to use Tails only (you cloned it from a friend) and want to use bridges.

This would also workaround partly the lack of persistence feature for Tor configuration #5461.

The list of Tor Browser built-in bridges is here: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-Data/PTConfigs/bridge_prefs.js


Related issues

Related to Tails - Feature #7437: Consider adding a progress indicator while establishing a connection to Tor Duplicate 06/22/2014
Related to Tails - Feature #8243: Support meek bridges Confirmed 11/08/2014
Related to Tails - Bug #11535: Fail at setting Tor bridge mode when using Unsafe Browser to get bridges Confirmed 06/16/2016
Related to Tails - Feature #11884: Document using Tor bridges to work around missing entry guards Confirmed 10/20/2016
Related to Tails - Bug #15068: How to use bridges in Tails: + not Yes Duplicate 12/15/2017
Related to Tails - Bug #15836: Meek-lite Duplicate 08/24/2018
Duplicated by Tails - Bug #10387: Include some default bridges Duplicate 10/18/2015
Blocked by Tails - Feature #5461: Persistence preset: Tor configuration Confirmed
Blocked by Tails - Feature #15331: Support automatic bridge retrieval in Tor Launcher (Moat) Confirmed 12/12/2017
Blocks Tails - Feature #15397: Document meek bridges Confirmed 03/12/2018

History

#1 Updated by sajolida almost 5 years ago

#2 Updated by sajolida almost 5 years ago

  • Tracker changed from Bug to Feature
  • Assignee set to anonym
  • % Done changed from 10 to 0
  • QA Check set to Info Needed

anonym: do you think that could be a part of bridges support phase 2? #6839. If so please mark it as a subtask.

#3 Updated by intrigeri almost 5 years ago

I don't remember why we've never done that in the past. It might be that there are good (?) reasons to not do that on Tails, that don't apply to Tor Browser. Maybe this requires putting in some thinking before we jump straight to the implementation step.

#4 Updated by anonym almost 5 years ago

  • Assignee deleted (anonym)
  • Type of work changed from Code to Discuss

intrigeri wrote:

I don't remember why we've never done that in the past. It might be that there are good (?) reasons to not do that on Tails, that don't apply to Tor Browser. Maybe this requires putting in some thinking before we jump straight to the implementation step.

Without further warnings, it would endanger users with the "Using Tor is dangerous or considered suspicious" use case (quote from the user docs). They might just pick the default set, and if we (quite reasonably) assume that adversaries are looking at such static configurations of Tails, it's a bad situation.

So we'd need warnings inside Tor Launcher, at the point where these bridges can be selected. Looking at existing facilities for that, there's always the entry name in Tor Launcher's drop-down list of provided/default bridges. We'd be limited to a very short warnings (like... 30 character?), so I doubt it's sufficient. What remains is to patch Tor Launcher's wizard, which we even could when using the bundled Tor Launcher from Tor Browser (done in #8925), but they couldn't be translated. Urgh. What remains is to running a Tor Launcher more or less like we do now, i.e. packaged from a forked source tree. I'm not sure I like this.

I'm not sure how important provided bridges are from a usability PoV vs. this use case mismatch issue it also would enable, and I'd rather be very sure that we need this than starting to move away already from the elegant solution in #8925. I'm marking this ticket "Discuss" for that reason.

#5 Updated by sajolida almost 5 years ago

The first thing that comes to my mind is that if default bridges are provided by TBB, what security argument would make us take a different decision?

The argument that you provide is sound. It's bad for users where "using Tor is dangerous or considered suspicious". But then why does TBB does that? I'm sure they had this discussion already.

#6 Updated by intrigeri almost 5 years ago

  • Related to deleted (Feature #5462: Persistence preset: Tor state)

#7 Updated by intrigeri almost 5 years ago

  • Related to Feature #5461: Persistence preset: Tor configuration added

#8 Updated by intrigeri almost 5 years ago

But the why does TBB does that?

I bet that they're simply rating "censorship circumvention usable out of the box" higher than "being careful wrt. using Tor is dangerous or considered suspicious".

I'm sure they had this discussion already.

Probably, but maybe not in a publicly archived place. E.g. I wasn't even able to find where the default bridges feature is documented in the TBB's ChangeLog.txt.

Related tickets I could find:

In any case, if we decide to provide the same set of default bridges as Tor Browser and to warn users about it, I fully agree with anonym: let's please not keep a forked Tor Launcher, and let's instead upstream whatever changes we need first (possibly guarded by a pref if the Tor Browser folks don't want to display the same warnings as we do).

#9 Updated by BitingBird over 4 years ago

  • QA Check deleted (Info Needed)

#10 Updated by anonym over 4 years ago

  • Related to deleted (Feature #5461: Persistence preset: Tor configuration)

#11 Updated by anonym over 4 years ago

  • Blocked by Feature #5461: Persistence preset: Tor configuration added

#12 Updated by anonym over 4 years ago

  • Type of work changed from Discuss to Code

This was discussed during the June 2015 meeting.

It was agreed that in the context of Tails, until we have Tor config persistence, (too?) many people will use default bridges because it's too painful to input bridges addresses manually each time you boot. It was decided to postpone this until we have such persistence.

Also, since no user has requested this feature to knowledge of those attending, it doesn't seem very high-priority.

If someone cares, it could be interesting to ask what the Tor Browser people think about the conflicting use case, i.e. "use bridges to hide that you are using Tor (or Tails)", and not only for circumvention, which they were originally made for. if so, they too have this problem and may solve it for us some how.

#13 Updated by anonym over 4 years ago

  • Type of work changed from Code to Discuss

#14 Updated by emmapeel over 4 years ago

But you can have the bridges on a text file, and copy&paste to the Tor connect menu...

#15 Updated by sajolida over 4 years ago

  • Type of work changed from Discuss to Research

I don't think there's more discussion to have on this one. We need to either wait until we have persistent Tor state or discuss this further with Tor people.

Also, for the record, I think that the one we talked to me about this feature is Isis from Tor who's maintaining BridgeDB.

#16 Updated by intrigeri about 4 years ago

Note that when seeing the first window displayed by Tor Launcher in the context of Tails for bridges users ("Tor Bridges Configuration"), a user has no way from inside Tails to get bridges. The documented ways to do that require using a non-Tails OS at this point.

#17 Updated by intrigeri about 4 years ago

  • Related to Feature #7437: Consider adding a progress indicator while establishing a connection to Tor added

#18 Updated by sajolida about 4 years ago

  • Duplicated by Bug #10387: Include some default bridges added

#19 Updated by intrigeri almost 4 years ago

  • Description updated (diff)

#20 Updated by intrigeri almost 2 years ago

#21 Updated by u almost 2 years ago

  • Related to Bug #11535: Fail at setting Tor bridge mode when using Unsafe Browser to get bridges added

#22 Updated by anonym almost 2 years ago

  • Feature Branch set to feature/8825-default-meek-bridges

From #8243#note-28

intrigeri wrote:

intrigeri wrote:

anonym wrote:

  • commit:33d9d3b425a7f270502b5ef87a0d606734846959 enables Tor's default Meek bridges in our Tor Launcher. My understanding is that it is the stealthiest pluggable transport (in practice, among the ones we support at least) despite requiring no user input, so it feels sane to ship them since users otherwise will be manually inputting the same text any way (and probably screwing up the "meek*_lite*" part). In fact, AFAIK there is no user-friendly way to learn about meek bridges. OTOH, my worry is that Tails might overload the meek bridges, since it is the only type of bridge we support. Thoughts?

I have no idea how Tor Launcher looks like when only 1 type of default bridges is enabled => in order to understand if and how this is related to our reasoning and decision on #8825, I'll need to see this thing in action => I'll build an ISO and will try it out.

I've tried it and ouch, that's a tough one. I think I agree with your description of the problem. I'm not sure about what conclusion we can/should draw and how. To make sure we're on the same page let me phrase how I see things using my own words:

  • On the one hand, the reasoning that lead us (#8825) to not propose default Tor bridges applies here even stronger: back then we were considering proposing all default bridges from TBB, which would have spread the load somewhat. So I don't think we (you and I) can dismiss that alone and implement something that's totally against something we've decided at the project scale.
  • On the other hand, your UX argument makes sense: it would feel stupid to say "we now support meek but to use them, you need to locate the corresponding bridge addresses in the Tor Browser Git repo or some hidden wiki page; and then every time you start Tails, you'll need to type them correctly and of course, don't forget to replace "meek" with "meek_lite"; what, wasn't that obvious?".

So I propose we do this:

  1. Once the other known issues are resolved, merge this without the default meek bridges. Don't announce this as a new feature except in changelog. Rationale: the code is basically ready, let's not let it bitrot. It might even be useful to have this code around, merged and tested for moat support, even without the default set of bridges; we'll see, I have no idea how moat support will look like.
  2. Wait for moat support in Tor Launcher to be ready for us to test it. Rationale: it might make this discussion moot (I wonder if the default bridges will still be a thing in TB once moat is there; and even if they're not a thing anymore, for Tails users the benefits of having default bridges available becomes almost null once there's a nice UI that lets them fetch their own bridges automatically).
  3. If moat integration in Tor Launcher does not magically make this problem disappear, go back to the drawing board (i.e. reopen the project-wide discussion on #8825 and/or seek advice from UX people).

I think this plan only makes sense if we are strongly committed to make step 2 real. It might be that we have to (and then it's FT core work), it might be that we don't have to (and then we need to do it as volunteers). Either way, count me in but not alone.

Let's continue this discussion here.

#23 Updated by intrigeri almost 2 years ago

  • Related to Feature #15331: Support automatic bridge retrieval in Tor Launcher (Moat) added

#24 Updated by intrigeri almost 2 years ago

  • Related to deleted (Feature #15331: Support automatic bridge retrieval in Tor Launcher (Moat))

#25 Updated by intrigeri almost 2 years ago

  • Blocked by Feature #15331: Support automatic bridge retrieval in Tor Launcher (Moat) added

#26 Updated by sajolida almost 2 years ago

#27 Updated by u over 1 year ago

  • Related to Feature #11884: Document using Tor bridges to work around missing entry guards added

#28 Updated by u over 1 year ago

  • Related to Bug #15068: How to use bridges in Tails: + not Yes added

#29 Updated by u over 1 year ago

Also available in: Atom PDF