[Tails-ux] Security by designation and Tor Browser

Hi,

>
> sajolida:
>
> This week-end I read an interesting UX article by Ka-Ping Yee.
> 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).
>

Ping is a smart dude, sans the long Google employment term, and his
insights are to be seriously considered. His personal projects[0] are
sweet, too :)

>
> 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.
>
> 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.
>

I like the general idea, as it aligns with Tails' Security by Usability
approach. I specifically like the enhanced user control in the example
given. The issue I have is with the increased decision making, at least
in our context.

For example, if setting up Cherry Music or Mail Pile at some point
requires a decision on the destination of all relevant files, no
worries, as that is preferable to the iTunes approach which results in
extra system designated folders. However, if the system (technically)
needs the decision made sooner than the first Tor Browser launch, like
at boot, it adds to the confusion of getting started.

>
> 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.
>

It isn't clear to me from documentation (on their part) what App Armor
does (there is a verbose account of how it works, though), but it sounds
like it has similar functionality to Privacy Guard [1], just more
complicated, yeah? If so, managing sandbox-like permissions at any
point in the system operation should be no issue (and would make my
above concern unnecessary).

>
> 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.
>

I am for this. I am even more for a mechanical switch for the
microphone, since removing the electron path is best, though that is up
to the man(ufacturers) :)

Thanks for sharing this!

Wordlife,
Spencer

[0]: http://zesty.ca/
[1]: privacyguard.png