On Fri, Mar 28, 2014 at 10:39 AM, Dodier-Lazaro, Steve < s.dodier-lazaro...@ucl.ac.uk> wrote:
> > cc'ing gnome-keyring-list@gnome.org > > > > On 03/26/2014 10:56 AM, Dodier-Lazaro, Steve wrote: > > > Hello, > > > > > > [...] > > > > > > > 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 > > > My bad, I can't forget I forgot to mention it. I also notice now that > there's > 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/CaHtrKfor > 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 > > > > > 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. > > > That's where I start to disagree a bit with Stef: the main factor of > users' "failure" > 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 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 > > I'm more alluding to work from Rode, Dourish, Redmiles et al. ( > http://douri.sh/publications/2006/soups06-seeing-further.pdf) > 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. > > > > > > 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. > > > Well, I figured apps may have different interactions for the user to > define the > 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. > Applications own the entire surface that they send to the compositor, so it's very easy to take a screenshot of their own window: dump the surface contents that they sent to the compositor out to disk. > > > > 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). > > This idea is brilliant! Password store access definitely needs protection > from > 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! > These sort of ideas are what I mean by designing the security systems and desktop together. These are the sort of ideas that we need to be thinking in terms of: rather than a protocol with accept/deny/prompt responses, think about it in terms of the entire user flow. Instead of asking "is it OK for this application to access the keyring?" where the compositor really can only reply with yes/no, we need to instead think of redesigning the entire flow. No, it's really bad for an application to access the entire keyring. Give them discriminated access to the password the user wants the browser to access. That's why I'm deathly afraid of a generic accept/deny/prompt protocol. It reeks of prompts like "do you want to accept this HTTP certificate" showing up, without any way of 1) digging for more information, 2) knowing what will break if the user chooses either option, 3) changing the decision at some point in the future if the user chose the wrong one. > Also, you say: > > > 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! > > Yes, there is an API, but before I write one that covers all possible use > cases I > 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! > > -- > 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 mailing list > gnome-shell-l...@gnome.org > https://mail.gnome.org/mailman/listinfo/gnome-shell-list > -- Jasper
_______________________________________________ gnome-keyring-list mailing list gnome-keyring-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-keyring-list
