Provide default bridges
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
#4 Updated by anonym over 4 years ago
- Assignee deleted (
- Type of work changed from Code to Discuss
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 over 4 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.
#8 Updated by intrigeri over 4 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).
#12 Updated by anonym about 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.
#15 Updated by sajolida almost 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 almost 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.
#22 Updated by anonym over 1 year ago
- Feature Branch set to feature/8825-default-meek-bridges
- 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:
- 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.
- 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).
- 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.