Tails

#6 Updated by intrigeri 2019-09-30 13:03:14

Hi,

(I’m lagging behind on Bug #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 Bug #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 Bug #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 2019-09-30 21:04:56

@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 2019-09-30 22:09:42

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 2019-10-06 07:40:36

@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 2019-10-06 10:06:55

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 2019-10-07 04:05:56

ok, sweet, makes sence

#13 Updated by Anonymous 2019-10-15 06:31:04

(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 Bug #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 Bug #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.

#15 Updated by moonmoonmoon 2020-01-07 00:31:07

I agree with what “Anonymous” wrote above, it doesn’t fit the rest of tails philosophy to have the unsafe option that only few users benefit from as the default.

But no matter what the default is, any progress on this is obviously good, even if the default is the unsafe option. Is this greeter option sure to be in 4.2 now?

#18 Updated by moonmoonmoon 2020-02-27 23:09:53

Will this finally be in 4.4 or will the target version get changed again? What has caused this to get moved to the next version so often? The implementation is fully done I believe, and it just needs to get merged?