[whatwg] Proposal for a web application descriptor

[Ian Hickson]

On Wed, 27 Jul 2011, Mike Hanson wrote:
> 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.
> > 
> > [...] 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.

One way to grant access to the whole database is to have the user drag the 
database into the app. Without knowing more about the concrete use case, 
though, it's hard to say exactly what the right solution is. Can you 
elaborate? What kind of application is this for, and what is the expected 
user interaction?

Going forward, it's possible that the "address book" would actually be 
just in a Web app, and granting access might really consist of dragging a 
MessagePort from the address book app to the other app. This would then 
allow the address book app to grant rights to the other app, including 
potentially bootstrapping a longer-term relationship (e.g. server-side).


On Wed, 27 Jul 2011, Cameron Heavon-Jones wrote:
> 
> The mapping of "tel" and "email" inputs to a contacts list is 
> functional, not systematic. Might this be extended for some other 
> inputs: date(*), url, search etc?
> 
> This functionality may be declared and defined through a new attribute, 
> since autocomplete is already used, something like "autoassist"?
> 
> Maybe this would be able to over-ride the default "file" input behaviour 
> of launching a popup in the case i just want to manually enter a 
> file:///

I'm not sure I really understand what you are describing here.


> > 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).
> 
> This would seems to be ok as long as the contents remain sandboxed until 
> selection is confirmed.

Assuming the photos are server-side, there's no way to do this without 
giving the app essentially full read access to the contacts.


> It would be nice for a page\site\app to still be able to access a full 
> contacts list if desired. Though it would seem to extend the integration 
> into the full Contacts API which is of far larger scope.

There is definitely a question of whether there should be an API for this 
specific case or if there are so many that we need a generic solution.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'