UI security topic: UI for private activities

[Marco Martin]

On Monday 16 January 2012, Fania Bremmer wrote:
> Hi there,
> 
> In the last days we had a lot of discussions about the security topic.
> In my team we already had a look how the UI dialogs could look like and
> in last fridays telco we talked about that as well.
> 
> So here my current findings presented in a flowchart regarding "private"
> (means encrypted) activities:
> http://share.basyskom.com/contour/UIDesign/flowchart_PrivateActivities.pdf

oddly the layout of the slider to lock i pushed in a branch now looks the same 
before i looked at the pdf :p

> Asumptions:
> - Mark Activity as private: toggle Button in "Create new activity" and
> "Activity Configuration" Dialog; details see flowchart
> - Open Private Activity in switcher: after tap a pw dialog appears
> (similar to delete dialog); see validation details again in flowchart;
> currently we still have a resize issue here, see
> https://bugs.kde.org/show_bug.cgi?id=288426

only issue i see how to do a good ui in a safe way (ivan can tell more about 
this)

> - Most discussed topic has been the re-encryption of private activities
> in case of shutdown and lockscreen. My suggestion is the following:
> 1- after changing activity: last private activity encrypts again,
> requires again pw if switched back
> 2- after shut down: all private activities encrypt again, pw needed for
> every private activity

+1

> 3a- after manual or automatical screen lock while private activity is
> running: pw dialog in lockscreen is required to open the current private
> activity. Unlock with normal activity running doesnt require any pw, it
> behaves like Plasma Active currently does.

my only concern is that besides requiring much more logic, i have some 
concerns with that:
* the unlock screen will become quite crowded (there was already the idea of 
adding controls for shut down, so would be yet other stuff on top)

* would require working on screen keyboard there, and is not possible by 
design, no window should ever be able to be on top of the lock screen, 
otherwise i can easily write an application that bypasses it and obtain unlock 
of the device, if the keyboard is able, also others will be (or a copy of the 
keyboard be in the screen locker itself, but this means bumping the memory 
consumption significantly)

maybe there are technical solutions for the last one (if someone know please 
speak) but if there aren't it would actually decrease the security quite a lot

> 3b- there has been the idea that after locking, PA encrypts all private
> activities again and just shows the last "normal" activity as a
> fallback. What I dont like here, that the last normal activity can be
> completly random, so that for the user that wouldnt be a benefit, as he
> has been just working on the private activity.

that's basically the behavior on the desktop when the current activity gets 
stopped/deleted, don't think would look too much weird

technically we would be forced to do that anyways, since when the activty 
would be stopped we have to switch to something else because it can't be none 
running.
just depends if this has to be hidden in some ways or not

> 3c- Another option would be that the uncrypted fallback is always the
> introduction activity, which can therefore be never private and can
> never be deleted. This would assure that we have at least one
> "normal/not private" activity in the system we can always fallback to. I
> dont like this option that much neither, because we would introduce some
> kind of homescreen, that we just wanted to get rid off ;)

could be the easiest to do, but yes, would look weird the fact that there is a 
"special" one

> - With all these passwords coming now into PA, I suggest having a
> security tab in our settings app with these options:
> - device pw after shut down: toggle on/off; on is default (needs then to
> be entered in first introduction activity)
> - edit pw for device pw
> - device pw after lock screen: toggle on/off; off is default
> 

i still think that if there isn't full disk encryption a device password is 
far worse than useless, because it's a false sense of security, if the device 
gets stolen the additional security it gives would be zero

Cheers,
Marco Martin