Tails

#1 Updated by mercedes508 2018-06-11 17:51:38

• Assignee set to Gaff

Hi,

in the 2 cases you talk about I don’t get a few things:

• lock the screen: it just avoid you the pain of manually locking it when going away?
• shut it down: what is the threat model excatly? Isn’t it already covered by the emergency shutdown feature?

#5 Updated by mercedes508 2018-06-14 11:26:33

• Assignee changed from Gaff to intrigeri

> * User is arrested while at the computer
> * User voluntarily leaves computer but forgets to lock the screen
> * Laptop equipment is snatched from user while in operation

At least to me it really looks like corner cases that are alsmot completely covered by the emergency shutdown feature.
Like you could simply physically attach the usb to your wrist, so if the laptop is taken it triggers the emergengy shutdown.

> The obvious downside is that it exposes Tails to any security risks associated with Bluetooth. I can’t claim expertise here but I guess there’s a bunch of proximity related metadata that can be exposed this way.

Yes and as far as I know it would seriously requires auditing before implementing this.

Could you try first experiemental testing of this feature?

I’m assigning to someone that could give a better technical/desig pov.

#6 Updated by intrigeri 2018-06-14 14:55:30

• blocked by Feature #10801: Make bluetooth opt-in in the Greeter added

#7 Updated by intrigeri 2018-06-14 15:05:21

• Assignee deleted (intrigeri)

Regarding the expected benefits:

• I agree that this is only useful is rare corner cases: wrt. locking the screen there’s already a timeout so the time window during which such a feature would help is small; wrt. shutting down, indeed we have the “unplug the Tails USB stick => boom” feature and the trick described by mercedes508 works for extreme use cases that require this level of safety (not to say it’s pleasant for everyone to work with their wrist attached to the computer, but well).
• Historically we’ve cared about such threat models a fair bit (once we’re done with our personas + strategic planning process we’ll know better how much we care now), so let’s take a look.

First of all this is blocked by Feature #10801 i.e. some way to enable Bluetooth, which is disabled by default on Tails. Then, assuming Feature #10801 is implemented, this requires a suitable implementation of such a Blueproximity-type system, that can be configured (what device should trigger this?) in ways that integrate nicely with GNOME and with Tails persistence. The original Blueproximity is 10 years old and relies on obsolete technologies so it’s clearly not an option. Finally, once all this is done correctly, any user could install this software via Additional Software Packages and be done with it.

So it’s lots of work for little benefit. I would be delighted if Tails users who want this had the option to enable Bluetooth and install such software but AFAIU the Tails part of the work is already tracked (Feature #10801) and everything else is a new software project, that Tails hasn’t the resources to tackle.

=> Let’s reopen this ticket if the two major blockers are resolved and someone is ready to do the integration work.

#8 Updated by intrigeri 2018-06-14 15:06:03

• blocks deleted (Feature #10801: Make bluetooth opt-in in the Greeter)

#9 Updated by intrigeri 2018-06-14 15:06:05

• related to Feature #10801: Make bluetooth opt-in in the Greeter added

#10 Updated by intrigeri 2018-06-14 15:06:33

• Status changed from New to Rejected

#11 Updated by Gaff 2018-06-14 15:17:36

• Assignee set to Gaff

intrigeri wrote:
> => Let’s reopen this ticket if the two major blockers are resolved and someone is ready to do the integration work.

Ok fine - If I get the chance I’ll have a look at reimplementing blueproximity with a modern API. But you make a fair point that this need not be part of Tails itself since it is generally useful. Better would be to package this for debian and have tails include it.

#12 Updated by Gaff 2018-06-14 15:38:55

• Tracker changed from Bug to Feature