Peter N. Glaskowsky:
>> u <u@??? <mailto:u@451f.org>> wrote:
I already sent an answer on that a few minutes ago. For some reason this
answer of yours Peter broke the thread and I didn't see it. I'm trying
to bring it back to the original thread. Let's try to stick to it (Peter
do "Reply" on this thread).
> 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.
Agreed. Note that:
- "Dotfiles" is generic and we can't really know what people do with it.
Still, we are in the process of considering local networking as unsafe
in general. See:
https://labs.riseup.net/code/issues/5340
https://labs.riseup.net/code/issues/7976
So the two topics might overlap.
- "Additional software packages": this does APT through Tor, so I don't
think that it's problematic.
So for me, we're left with #7165 and the Printer stuff. Regarding
Printers we should check how serious the issue is. Asking this on
tails-dev would be a first step.
> 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.
We're currently heading to considering LAN as untrusted by default and
enforcing this quite strongly. See
https://mailman.boum.org/pipermail/tails-dev/2014-November/007314.html
In this thread we are also considering having an option to allow more or
less LAN activity, either in the Greeter or during the session.
> 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.
On problem I see here is that people might put to much trust in their
home LAN for example. At least in the places where your ISP provides you
with a DSL and WiFi route most of the time they are in direct control of
that small computer which is is a central position of your LAN.
> 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.
--
sajolida
