> cc'ing gnome-keyring-list gnome org> > [...]
>
> On 03/26/2014 10:56 AM, Dodier-Lazaro, Steve wrote:
> > Hello,
> >
> >My bad, I can't forget I forgot to mention it. I also notice now that there's
>
> Great article (erm...I mean paper)!
>
> I strongly urge you to watch Stef Walter's talk from this past summer's
> GUADEC:
> http://www.superlectures.com/guadec2013/more-secure-with-less-security
much of a communication mishap on the role of permission prompts in my view. Of
course, it's intended that these prompts should be exceedingly rare (but you cannot
kill *all* the prompts). Here's the pipeline for setting permissions:
1) Default settings: each major DE and distributor can endorse their favourite
apps in a settings file, so users have screenshooting apps, vkeyboard, clipboard
managers, etc. by default
2) User-Driven permissions: some widgets/controllers in an app's GUI are managed
by a third-party daemon and the compositor draws them with the app, but they
are hidden from the app and have specific labels e.g., "Copy", "Paste", etc.
When the user interacts with them, the system then authorises a one-time use of
a restricted interface for a tiny time window (see http://goo.gl/CaHtrK for paper,
unfortunately there's a patent http://www.google.com/patents/US20130117840, I
don't know what that'd imply in terms of implementing the idea though). A system
could restrict this interface to only packaged apps, or apps with known, identified
authors citizens of a country where the distributor could act in case of abuse, etc.
3) Prompts: for when apps that are both incompatible with UD-permissions and too
dubious for default settings. Users can also give them permanent permissions in
their own default settings, but I don't think it's a good UX practice to just let
the app fail silently (so there's not a single prompt, yay) and the user figure out
that they have to go to their permissions settings and authorise the app themselves
(whoops!). Sometimes prompts are good, because they give the user the ability to
act upon something that poses them a problem in their given context
That's where I start to disagree a bit with Stef: the main factor of users' "failure"
> Stef is the author of gnome-keyring (the secure storage daemon), gcr (a
> set of reusable widgets to present various security-related things), and
> seahorse aka "Passwords & Keys".
>
> For one, I believe your designs rely too heavily on standard (though
> well-designed & thought-out) dialogs since, as you acknowledged, that
> users often have difficulty understanding context, let alone being able
> to make proper security decisions.
to respond to security dialogs does not *only* have to do with lack of understanding
of why prompts exists (that was 49% of UAC users), but also they just can't be
bothered to be pestered with all day long by their OS (which gives us 20% users
taking the time to learn how to disable UAC, knowing that the majority of lay PC
users do not normally modify default settings). People just don't care! There's
plenty of academic evidence for it, and economic models that explain why they don't
care (see "The Compliance Budget" from... my employer :) and "The Security Cost
of Cheap User Interactions" for instance). Now the bad news is that their behaviour
is most likely very rational since most allowed prompts do not turn into economic
penalties for them.
My goal is not to stun the user with prompts, or "put them back in control" in the
sense of making them aware of their responsibility and then run away. It's also known
that users have misconceptions about how malware operates, how many things are
dangerous, how much big companies love to track them and re-sell their data, etc.
Users also have specific attitudes, many thinking that "nobody cares about [them],
[they] have nothing valuable on [their] computer", or that "anyway, hackers will
get in if they want to so there's no point in protecting [themselves]".
That means we need to provide the astonishing majority of the security logic that
is to protect users, and then just inform them of the tensions between their primary
tasks and the risks they're exposed to, in *the most unobstrusive way possibly
achievable*. In this sense these last-resort prompts still need a lot of love :)
I'm more alluding to work from Rode, Dourish, Redmiles et al. (http://douri.sh/publications/2006/soups06-seeing-further.pdf)
> I believe that the solution to better security understanding lies in
> innovative UI interactivity. Stef talks about this more in depth in his
> talk, and you seem to allude to it:
>
> > In an utopian world, the user knows which data can be affected by an authorisation (e.g., whether their bank website currently on screen will appear on a screenshot, which files’ content can be leaked to an app, etc.) so s/he can make a `blink of an eye’ decision; the effects of authorisations should be tangible
where users actually have tangibility (with the famous HCI example of the car driver,
cant seem to find a ref now though). It's not about understanding but rather
about feeling the security level achieved depending on the settings you picked.
This is rarely achievable though, and not for all types of security experiences.
Well, I figured apps may have different interactions for the user to define the
> But as an example, if an app would like to capture screen contents
> outside its borders, it would express this desire to privilege moderator
> (e.g. the wayland compositor?), which would then offer controls to the
> user so that they may define the area permitted to the app.
screenshot area, so in my view every app should be able to take a screenshot of its
own window (covers the closed-source game screenshot use case, typically, and most
needs), and then an app can get a permission to take one full-screen screenshot
and use that permission for a smaller area if they want to. I think that should
suffice and yet keep the API clea.
>This idea is brilliant! Password store access definitely needs protection from
> Additionally, there should probably be one more requirement added to
> http://mupuf.org/blog/2014/03/18/managing-auth-ui-in-linux/#5-security-requirements
> This being the ability for a non-privileged application to access stored
> secrets (e.g. passwords stored in a password manager).
> To provide another example of how to actively integrate the user into
> this security-granting action, the app (say, a web browser) would issue
> a call to, e.g., the compositor which would somehow present the list of
> the user's saved passwords, and the user would actively have to double
> click the password for the particular username/website (in addition,
> perhaps the app could tell the compositor the desired username/website,
> and the compositor would scroll the presented list to the suggested
> password for username/website combo).
abuse... by other apps and oneself (if malware kicks in). However I hadn't dared
to ask users to click on a permission prompt for every login. Is it still better
than a SSO authentication? Your 'somehow' and the GTK 3.12 ChangeLog make me
think that GtkPopovers could be used when hovering a password field for which
there is a stored password (e.g., the browser always reports to the keyring and
the keyring presents the popover the UDAC way; browser can't see it). That would
make the password re-use a one-click interaction without intrusive dialogs!
> Also, you say:Yes, there is an API, but before I write one that covers all possible use cases I
> > Hopefully others will agree with me and I will be able to take a FreeDesktop spec out of this article
>
> I'm unsure what kind of spec you had in mind. To me, what seems most
> useful would be a standard API for a finite number of security
> requirements (as in section 5 of your paper), with concrete interfaces,
> AND suggested guidelines / reference implementation (gosh, that sounds
> like wayland/weston...) for each of the interactive security widgets for
> the requirements.
>
> Again, thanks for the email, the article, and all this research!
could think of, I'd like to get the requirements right. A specification/blueprint
of the possible interactions that should be implementable within the scope of a
cross-desktop API is what I had in mind.
Thanks to you for your reply!
gnome-shell-list mailing list
--
Steve Dodier-Lazaro
PhD student in Information Security
University College London
Dept. of Computer Science
Malet Place Engineering, 6.07
Gower Street, London WC1E 6BT
OpenPGP : 1B6B1670
_______________________________________________
gnome-shell-list gnome org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list