Re: System Level APIs draft proposal

On 04/30/2012 05:28 PM, Robin Berjon wrote:
> Hi all,
> 
> during our last face to face meeting it emerged that there was interest in there being another working group that would work on System Level APIs, of the kind that would be too dangerous to include in a browser but that would be useful if you wanted to build a Web-based OS, be it through "traditional" applications or with some form of browser extension system.
> 
> I looked around the existing landscape and had a variety of chats with people who expressed interest in the topic, and put together a draft charter.
> 
> Please note that this draft is just my personal input, it does not represent the consensus of anyone other than myself, is not endorsed by whoever, etc.
> 
>     http://darobin.github.com/system-level-apis-charter/
> 
> Your feedback is welcome!

I like the idea because that creates a WG that is going to own APIs that
are related to system features. However, I don't think we should insist
too much on the fact that this group should contain only APIs that do
not adhere with browser security model. I don't think this is a good
idea to put that postulate that will put to much limitations on the APIs
and implementations.
For example, it seems correct to me to put "Device Capabilities API" and
"Sensors API" in that WG but I wouldn't be shocked if a browser use a
door hanger security model to ask the user to give permission to the web
site like "This website wants to know some sensitive information about
your device and might fingerprint you, do you agree?".
Also, "Spellcheck API" is something that would make a lot of sense in
regular content like word processors.

Because of that, I think this sentence from the header:
"These APIs are distinct from those produced by the Device APIs Working
Group in that they are not expected to be safe to run in a browser
environment, and therefore do not need to adhere to the browser security
model. "
and this paragraph in "2. Scope":
"Note that this group does not presume of the exact context in which
these APIs will be used, beyond the fact that they will not be available
in security-sensitive settings such as arbitrary Web content. It may be
possible to make use of this functionality in traditional applications,
just as well as it may be exposed for instance to browser extensions. "
should be re-phrased to make it clearer that regular web content could
access those APIs depending on the API and the UA choice/implementation.

Cheers,
--
Mounir

Received on Friday, 4 May 2012 17:26:29 UTC