intrigeri:
> 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;
Ok.
> * 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.
We probably can't find a design that works for every possible authority
and each of them might require special treatment. In the case of the
microphone and in the context of Tails I wouldn't find it crazy if only
the GNOME configuration interface would be allowed to unmute the
microphone (that would be the privileged helper) while still allowing
applications to modify the microphone level either automatically as they
need (some VoIP applications do that), either providing a graphical
control to the user from their interface.
