W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2011

[whatwg] Proposal for a web application descriptor

From: Mike Hanson <mhanson@mozilla.com>
Date: Wed, 27 Jul 2011 09:30:26 -0700
Message-ID: <43DCE7F1-AD1A-4587-A0BA-E61B9F2AA291@mozilla.com>
On Jul 26, 2011, at 2:44 PM, Ian Hickson wrote:

> On Fri, 29 Apr 2011, Simon Heckmann wrote:
>> 
>> I have read a lot in the last month about the future of html and web 
>> applications and I am very impressed by the progress this makes. 
>> However, I have come across some thing that annoys me: Permissions. I 
>> know they are important and I know they are needed but currently I find 
>> this quite inconvenient. And with more and more permissions coming up 
>> this might get worse so I spent some time thinking about it.
> 
> <snip>
> In short, the better solution isn't to ask for permissions up-front, but 
> to ask for fewer permissions. The ideal solution is to not ask for any 
> permission but to base the permission on a natural user gesture. For 
> example, drag-and-drop of files to a site doesn't require permissions, but 
> it is an implicit permission grant. Same with <input type=file>. With 
> getUserMedia() we are doing something similar: instead of asking for 
> permission, the user is asked for a specific input to be selected.
> <snip>
> Indeed. The system shouldn't ask for any permissions. For example instead 
> of reading contact data, it could cause the OS to pop up a contacts list 
> from which you can pick a contact to give access to it to the app.

The challenging use case, and one that we had trouble with when we prototyped the Contacts API, is for ongoing or persistent access.  The best approach we have right now is to use explicit markup to "sandbox" the permissions grant away from untrusted code.

In the Contacts case, for example, autocomplete of email addresses, names, and phone numbers was a desired use case.  A naive approach is to let the web app read the entire database and perform autocompletion in content.  The safe approach, which was harder and less flexible, is to attach autocomplete behavior to input type="tel" and "email", and to set the autocompleted value only when the user has selected it.

There are definite UX limitations to that approach - the content can't provide visual hinting during the autocomplete, for example (it would be nice if a photo gallery could trim down the set of photos from my friends as I narrow in on the name).  The limitations create an incentive for content to try to get the full set of data anyway, through some other channel.  As Roc commented, finding a way to be comfortable with a higher-level permissions grant that persisted over a longer span could be one way to address that.
--
Michael Hanson, Mozilla Labs
Received on Wednesday, 27 July 2011 09:30:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:35 UTC