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/
