Tails

#1 Updated by sajolida 2015-01-30 09:28:19

• related to Feature #5462: Persistence preset: Tor state added

#2 Updated by sajolida 2015-01-30 09:29:43

• 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? Feature #6839. If so please mark it as a subtask.

#4 Updated by anonym 2015-03-13 02:55:07

• 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 Feature #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 Feature #8925. I’m marking this ticket “Discuss” for that reason.

#6 Updated by intrigeri 2015-03-15 10:32:04

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

#7 Updated by intrigeri 2015-03-15 10:32:24

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

#9 Updated by BitingBird 2015-04-10 16:57:18

• QA Check deleted (Info Needed)

#10 Updated by anonym 2015-06-03 20:44:54

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

#11 Updated by anonym 2015-06-03 20:45:06

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

#12 Updated by anonym 2015-06-03 20:52:18

• 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 2015-06-03 20:56:41

• Type of work changed from Code to Discuss

#15 Updated by sajolida 2015-08-31 09:05:32

• 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.

#17 Updated by intrigeri 2015-10-01 09:45:34

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

#18 Updated by sajolida 2015-10-20 08:16:42

• has duplicate Bug #10387: Include some default bridges added

#19 Updated by intrigeri 2016-01-20 11:02:11

• Description updated

#20 Updated by intrigeri 2018-01-19 11:09:11

• related to Feature #8243: Support meek bridges added

#21 Updated by Anonymous 2018-01-19 16:33:48

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

#22 Updated by anonym 2018-01-26 11:27:40

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

From Feature #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 Feature #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 (Feature #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 Feature #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 2018-02-20 08:23:34

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

#24 Updated by intrigeri 2018-02-26 11:38:11

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

#25 Updated by intrigeri 2018-02-26 11:38:19

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

#26 Updated by sajolida 2018-03-12 17:49:54

• blocks Feature #15397: Document meek bridges added

#27 Updated by Anonymous 2018-08-18 12:39:20

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

#28 Updated by Anonymous 2018-08-18 12:39:42

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

#29 Updated by Anonymous 2018-09-03 08:10:18

• related to Bug #15836: Meek-lite added