Re: [Tails-ux] Prompt before compromise

Borrar esta mensaxe

Responder a esta mensaxe
Autor: Peter N. Glaskowsky
Data:  
Para: tails-ux
Asunto: Re: [Tails-ux] Prompt before compromise
> u <u@??? <mailto:u@451f.org>> wrote:
>
>> It would be interesting to design the system so that before it takes actions that are known to create a risk of leaking information about the user, the user gets a prompt. For example, add dialogs that say “Join known Wi-Fi network <SSID>?” or “Install apps AAA, BBB, and CCC?” or “Connect to printer <NAME>?”
>>
>> This would still be much more convenient than configuring Wi-Fi access (or performing other tasks) on every reboot, while allowing the user to maintain a higher degree of privacy than the current implementation of persistence does.
>>
>> Thoughts? Has this been previously proposed? (I don’t see this anywhere, but I might be missing something.)
>
> This sounds like a great and important idea!
>
> Although, that would mean that on every boot, I will have many little
> windows or notifications which i need to click on. This might be very
> annoying, especially if you use Tails on a daily basis.


There would be only one prompt for each persistence feature that might tend to leak user-specific information onto the local network— and even of those, only the ones that were enabled when persistence was set up and are actually used.

I think most persistence features aren’t a problem. From the list here:

https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html <https://tails.boum.org/doc/first_steps/persistence/configure/index.en.html>

I think “Personal Data” (local file storage), GnuPG, SSH Client, Pidgen, Claws Mail, GNOME Keyring, APT Packages, APT Lists, and Browser Bookmarks are all intrinsically safe.

That leaves Network Connections, Printers, Dotfiles, and the experimental “Additional software packages” feature.

My thinking is that generating TOR traffic is safe since it’s unidentifiable on the LAN (at least it better be!), but any particular pattern of LAN traffic is at least potentially identifiable. As far as I can tell, only those four features are able to generate LAN traffic. Of course if I’m wrong, or if there’s a deeper analysis of this somewhere, I’d like to know.

> So I would rather imagine some kind of unique screen. Or try to
> implement this as an option into the greeter:
> When you have persistence and you enter your persistence password on
> boot, propose "persistence settings". By default, you will connect to
> all those items. But you can disable them, one by one.
>
> What do you think?


Yes, I think you’re right that a simpler UI for the most common use case would be a good thing.

It seems to me that the fundamental issue is whether the user believes the local network is reasonably safe, so we should ask that question directly. I suggest adding a question in the Greeter along the lines of “Trust this location?” with options Yes (the default), No, and Prompt.

The affirmative answer would allow all the previously enabled persistence features to work normally. Selecting No would disable all Persistence features that might tend to compromise the user, and of course Prompt would basically be my proposal from yesterday, to show a prompt before activating each potentially risky feature. If the feature hasn’t been enabled in the persistence configuration, or it isn’t actually used, there wouldn’t be a prompt for it.

The Yes option should be the most common choice by far, since most people will either have reasonable confidence in the safety of their current location or will disable persistence entirely.

The No option can be usefully better than disabling persistence entirely, since the information relevant to the disabled features would still be available in the persistent volume. While we’d prevent the system from automatically connecting to known SSIDs, the user could run a quick Wi-Fi scan to make sure there’s nothing suspicious going on, then manually connect using the saved password. Similarly, advanced users could manually access dotfiles or manually install software that otherwise would have been automatically installed.

Your proposal seems to boil down to replacing “Prompt” with “Settings”, which would display individual checkboxes for each of the sensitive persistence features, and I think that’s also a good way to go. I’d support either method. Prompt would expose a little more information by informing the user when a possible threat exists, for example by presenting a prompt when a known SSID appears; Settings would be less disruptive to the user experience.

I think the “Trust this location?” selection should be made globally available through an API so apps can make appropriate choices— a simple example of how the Tails project can drive the development of privacy-sensitive APIs that could find their ways back into Linux and other operating systems.

.                  png