W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

Re: Trying to summarise (was Re: DAP and security)

From: Robin Berjon <robin@berjon.com>
Date: Thu, 19 Nov 2009 13:47:42 +0100
Cc: public-device-apis@w3.org, public-webapps WG <public-webapps@w3.org>
Message-Id: <1EC3F381-7749-4F66-92D8-524FE3D400D1@berjon.com>
To: Jeremy Orlow <jorlow@chromium.org>
On Nov 19, 2009, at 13:09 , Jeremy Orlow wrote:
> Is this practical without the major browsers being part of the DAP WG?  (Last time I checked, there were some absences.)

Well, the absences have been vocal in commenting so far; and others have indicated intention to join. We can't wait for every browser vendor to find the resources to join a WG to get it rolling. It took a *long* while to get everyone on WebApps.

> I don't understand.  If security is baked into APIs from the start (as is a requirement for browsers) and the same API should be used in the "different context", then what need is there for a policy model?  The policy model seems to only be applicable when APIs are inherently insecure and trust is required...which is the type of API a browser will not implement.

In a widget context for instance, policy could override the user consent mechanism that an API has baked in. If you have an asynchronous security entry point  la Geo for instance, it could return immediately (or block indefinitely) without ever interacting with the user.

And as I said in the message to which you replied, additional entry points can be made available. To take a totally random example, if the policy grants it you might become able to do navigator.device.gimmeOneFile("/etc/passwd") which would return just what you'd get from the File API.

-- 
Robin Berjon - http://berjon.com/
Received on Thursday, 19 November 2009 12:48:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:01 GMT