- From: Robin Berjon <robin@berjon.com>
- Date: Thu, 19 Nov 2009 13:47:42 +0100
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: public-device-apis@w3.org, public-webapps WG <public-webapps@w3.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 UTC