Hi,
(Disclaimer: I've not read the paper yet.)
sajolida wrote (21 Sep 2015 09:52:17 GMT) :
> Another example that came to my mind for this strategy would be #10113
> (Greeter option to enable microphone), the microphone should be disabled
> until the user asks to use it by raising it's volume from zero. to
> something else.
The way I understand this family of security/UX designs, sadly they
don't fix all problems, and to be safe one needs at least one of:
* privileged *apps* that have fine-grained permissions (e.g. my VoIP
software would be allowed to control microphone volume levels); in
this case it means that every piece of the desktop that allows the
user to control the microphone volume would need to be itself
allowed to do that; that's essentially the Android model; and
technically speaking, it works best with 1 app = 1 UID, doesn't
match how current Linux distros and desktop environments work, and
doesn't cut it for strongly integrated bits of UI that need to all
run under a single UID such as widgets integrated in the GNOME top
bar;
* a privileged helper, that once invoked by the application (e.g.
after the user clicked "Save link as"), itself calls back to the
user to ask them what they really want to do (e.g. in some
graphical file chooser); this works fine for processes that are
inherently two-step ones, such as opening or saving files; however,
this seems not that good for things the user would typically expect
to be one-step actions, such as changing some mixer level: not sure
the UX would be great for this scenario:
Given I am running Tails
When I unmute the microphone volume in any application
[note that said application is *not* allowed to do that itself]
Then I am asked for confirmation
[by the privileged helper]
... in this case, asking for confirmation feels quite backwards
wrt. the initial goal of letting the user indicate what they wish
to see happen, and then, well, make it happen without additional
security-specific nagging they'll click through anyway.
Cheers,
--
intrigeri
