[Putting tails-dev in copy once as I'd like to have technical insights.]
Hi,
This week-end I read an interesting UX article by Ka-Ping Yee [1].
He describes in it a design strategy he calls "security by designation"
(page 13) which means using the user interaction and workflow to infer
the adequate security authorities (for example, the minimal but needed
permissions to access a given resource). It made me think a lot of the
problems we had when introducing AppArmor in Tor Browser and the fact
that the browser is now limited to access two folders and that's a pain.
[1]:
http://labs.toolness.com/temp/sid/ch13yee.pdf
So let me tell you a bit more. Even if from a technical point of view
that might be completely unrealistic with the current architecture of
GNOME, AppArmor, or Unix I find the UX reflection behind it making a lot
of sense and changing paradigm interestingly. He also himself applies
this principle to securing file access (page 18).
Currently we have static security authorities on the files accessible by
Tor Browser that are defined by the system (AppArmor + Unix
permissions). In other contexts we also have authorities configurable by
the user (for example, in Tails you can set an administration password
in Greeter) or accessible through security warnings, what he calls
admonition, (for example, in Tails you can browse the web without Tor by
opening the Unsafe Browser and going through scary things).
What would be better in terms of UX (and possibly better in terms of
security as well) would be to have Tor Browser with strictly no access
to personal files by default (not even these two folders) and infer from
the user interactions (where to download, what to upload) on which files
or folders to grant read or write permissions.
What underlying technical limitations prevent us from doing something
like this? Would this imply a major change in the way GNOME interacts
with application regarding browsing file? Would this imply having
dynamic AppArmor rules? Is that possible at all? See also the image in
attachment.
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. Of course, I'm not taking any technical limitation into
account here.
