Project

General

Profile

Feature #17085

Allow to disable the Unsafe Browser in the Greeter

Added by segfault about 2 months ago. Updated about 1 month ago.

Status:
Needs Validation
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
bugfix/17085-allow-to-disable-unsafe-browser
Type of work:
Code
Blueprint:
Starter:
Affected tool:
Greeter

Description

The Unsafe Browser can be used by attackers which are able to execute code as amnesia to deanonymize the user by retrieving the public IP address (#15635).

This is a low effort solution to allow users who are concerned about this to protect themselves, without hurting UX for other users.


Related issues

Related to Tails - Bug #15635: The Unsafe Browser allows to retrieve the public IP address by a compromised amnesia user with no user interaction Confirmed 06/04/2018

Associated revisions

Revision 04d9c222 (diff)
Added by segfault about 2 months ago

Add Greeter option to disable the Unsafe Browser (refs: #17085)

History

#1 Updated by segfault about 2 months ago

  • Feature Branch set to bugfix/17085-allow-to-disable-unsafe-browser

#2 Updated by segfault about 2 months ago

  • Related to Bug #15635: The Unsafe Browser allows to retrieve the public IP address by a compromised amnesia user with no user interaction added

#3 Updated by segfault about 2 months ago

  • Status changed from Confirmed to In Progress

#4 Updated by segfault about 2 months ago

  • Assignee set to segfault

I built the branch and tested that:

  • The Unsafe Browser doesn't start if it was disabled in the Greeter
  • The Unsafe Browser does start if it wasn't disabled in the Greeter

@sajolida, @intrigeri: I had some time while traveling so I went ahead and implemented this, even though we didn't conclude on #15635 that this is the solution we want. As I wrote on #15635, it's meant as a low effort solution for concerned users, until we decided on a better solution to solve #15635. Please tell me what you think about it.

#5 Updated by segfault about 2 months ago

  • Status changed from In Progress to Needs Validation

#6 Updated by intrigeri about 2 months ago

Hi,

(I'm lagging behind on #15635, please forgive me if I'm missing something important from there.)

This is a low effort solution to allow users who are concerned about this to protect themselves, without hurting UX for other users.

I like the idea of doing something for users who:

  • are particularly concerned about this;
  • either know they will never need the Unsafe Browser (e.g. in a VM) or are fine with restarting Tails if they do.

I appreciate you've been working on it.

However, at first glance, I'm not a big fan of adding this option in the Greeter:

  • Like every extra advanced option we expose to regular users, it hurts UX: users who need to enable options in the Greeter may notice this option and wonder whether they should use it.
  • I'm slightly worried it will make it a bit harder to decide something on #15635: while we may think of this as a temporary stop-gap today, past experience suggests that as time will pass, we'll be more and more concerned about dropping this new option, even if it was always meant to be temporary or not really supported. In other words, if #15635 is still not solved in 6-12 months, I suspect some folks will raise "this is a regression vs. the status quo" as an argument against any solution that does not provide the exact same functionality as what you're proposing here. I'm saying slightly worried as I'm aware I'm a bit traumatized in this respect, so I'm taking my own feelings with a grain of salt :)

What about instead adding a kernel command line option instead? I suspect the power users who'll use it will be equally fine with this option. These folks might even prefer it to the Greeter way, because they can hard-code it in their syslinux config (and re-add it after every Tails upgrade). It would not hurt UX for anyone else and would limit the risk of seeing the status quo argument restrict our options later on.

#7 Updated by moonmoonmoon about 2 months ago

@segfault Thank you for actually doing something about this issue! It has not been addressed for way too long.

@intrigeri I don't understand how you can be working on Tails and think that "Adding an option that might make a regular user accidentally enable something that makes using Tails more safe" is something bad?

I believe a greeter option is the right way to go, but with the default being that the unsafe browser is disabled, because it makes absolutely no sense to expose 99% of Tails users to this extreme risk the unsafe browser causes, while only 1% of Tails users likely ever need it. I understand you don't have statistics on that, but it's probably fair to say that everyone who actually needs the unsafe browser knows exactly that they need it, while people who don't need the unsafe browser likely don't know that it even exists, and also don't know what huge risk it is to have it enabled. And really, if someone accidentally disables the unsafe browser while he needs it, he will get the error message that segfault added when trying to start the unsafe browser, and it tells you exactly what is required to make it work (a reboot and not disabling it). So even in that case, it just takes a few minutes longer for that user to connect, and it will only happen once to anyone since after that the user has learned that he needs to enable it. While everyone else who doesn't need to unsafe browser is way safer. Seems like a complete no-brainer for me.

A greeter option, even with the bad default of the unsafe browser being enabled, is way better than no greeter options at all of course. And it's easy to later change it to the good default of the unsafe browser being disabled. At least having the option shows new users that this is something to worry about. That is good. If you hide it behind kernel command line options, you don't make anyone aware of the unsafe browser being a risk. And it's super inconvenient to enter command line options every time you start tails. And at least I don't know what a "syslinux config" is and how to create it, so I would want this option to be easily accessible in the greeter.

#8 Updated by segfault about 2 months ago

moonmoonmoon wrote:

@intrigeri I don't understand how you can be working on Tails and think that "Adding an option that might make a regular user accidentally enable something that makes using Tails more safe" is something bad?

The goal of Tails is to provide a secure system that is usable for everyone. So yes, we have to consider the impact on UX of each change made to Tails.

intrigeri wrote:

Like every extra advanced option we expose to regular users, it hurts UX: users who need to enable options in the Greeter may notice this option and wonder whether they should use it.

Ideally, the option should have a description which makes it easy for users to decide whether they should use the option or not. Maybe sajolida can improve the description I wrote. And if the user knows that they don't need the Unsafe Browser, then IMO it is good that it's easy for them to disable it.

#9 Updated by op_mb about 1 month ago

@segfault: i was wondering, if it would be easier to just compile 2 versions of Tails - one with unsafe browser and one without. if it was easier to do just 2 different images, that would give you more time (and not rushed) to figure out how to do it right

just putting it out there :)

#10 Updated by segfault about 1 month ago

op_mb wrote:

@segfault: i was wondering, if it would be easier to just compile 2 versions of Tails - one with unsafe browser and one without. if it was easier to do just 2 different images, that would give you more time (and not rushed) to figure out how to do it right

That would definitely not be easier. And it would be a hard choice for many users to choose one of the images to install.

#11 Updated by op_mb about 1 month ago

ok, sweet, makes sence

#12 Updated by intrigeri about 1 month ago

  • Target version changed from Tails_4.0 to Tails_4.1

4.0 is now frozen so I'm postponing this ticket.

#13 Updated by mgerstack about 1 month ago

(I sent an email to Tails-UX mailing list three weeks ago about that ticket and got no feedback if it was published or if it is still stucking in moderation so i will add the important parts here.)

I dont know how urgent the risk of a compromised amnesia user really is so i need to assume that its a urgent risk.

I think enabling the unsafe browser by default IF there is a risk is somehow inconsequent to the rest of Tails behavior.

Normally Tails in its default settings is safe but now the user need to do an extra interaction to be safe.
The Tails Greeter even say "Normally the default settings are safe in most situations." but thats not true then anymore because now the average user need to do an extra step to be safe again.

With enabling the unsafe browser by default you put ALL users under risk even these user who need to connect to a captive portal and expect ALL users to weighten the risk of using the default settings or disabling the unsafe browser.
And ALL of them need to remember that they are under risk as long as the unsafe browser is enabled.

I dont really agree with the #15635#note-18.
Its pretty likely that you will mostly interview people who already needed to login into a captive portal because these are the people who travel.
Its less likely that you will interview people who use Tails only at home and therefore will never need to login into a captive portal.
I agree with #15635#note-20 that probably 1% is more close to reality but as long as there are no safe numbers these are all guesses.

I think most of the time its pretty obvious before you boot Tails if you need to login into a captive portal.

But with the decision to enable the unsafe browser by default you put these users at risk who forgot to disable the unsafe browser, you put these users at risk who dont know that they should disable the unsafe browser and that decision is not a real benefit for these users who would remember to enable the unsafe browser before booting Tails because you save these users only two clicks.

The only group you support are these users who would forget to enable the unsafe browser but for those group the worst thing what could happen is that they need to reboot.

Lets compare that with how you handle bridges right now.
Because of UX reasons Tails decided to directly connect to Tor by default.

So there you put all users under risk who live in a country where using Tor can lead to punishment and these users need to care for themself to remember to edit the default settings.
This group is perhaps very small if even existing so i think that decision is the right one.
If someone now choosed the wrong settings and actually wanted to connect to Tor with a bridge than the worst thing what could happen is that he need to reboot.

But if someone acidentially choosed the wrong settings about the unsafe browser then he is under risk!

So with that decision you put ALL users under a potentially risk for only saving a reboot for that small userbase who forgot to enable the unsafe browser in the Greeter and who did not realized early enough that he will need to login into a captive portal later.

And i think that group is not much bigger than the userbase who would have a benefit of changing the default Tails behavior to using a bridge by default.

So that decision seems inconsequent to how Tails is for example handling bridges setup and inconsistent with the statement "The default settings are safe in most situations."

So i think the unsafe browser should be disabled by default.

Also available in: Atom PDF