Re: System Level APIs draft proposal

De: Jonas Sicking <jonas@sicking.cc<mailto:jonas@sicking.cc>>
Fecha: Thu, 3 May 2012 01:44:41 +0200
Para: Doug Turner <dougt@mozilla.com<mailto:dougt@mozilla.com>>
CC: Niklas Widell <niklas.widell@ericsson.com<mailto:niklas.widell@ericsson.com>>, "Carr, Wayne" <wayne.carr@intel.com<mailto:wayne.carr@intel.com>>, "Tran, Dzung D" <dzung.d.tran@intel.com<mailto:dzung.d.tran@intel.com>>, Robin Berjon <robin@berjon.com<mailto:robin@berjon.com>>, "public-device-apis@w3.org<mailto:public-device-apis@w3.org> public-device-apis@w3.org<mailto:public-device-apis@w3.org>" <public-device-apis@w3.org<mailto:public-device-apis@w3.org>>
Asunto: Re: System Level APIs draft proposal

On Wed, May 2, 2012 at 9:31 AM, Doug Turner <dougt@mozilla.com<mailto:dougt@mozilla.com>> wrote:
On May 2, 2012, at 2:33 AM, Niklas Widell wrote:

> I would prefer to have browser-safe and non-browser-safe APIs in one WG.
> Potentially two specs (or two different sections in spec or something) per
> API depending on security solution, but I think the work will only end up
> in confusion with two Wgs doing very similar things.

I agree.  I think it should be left up to the UA to figure out how to express what is browser-safe and what is non-browser-safe.  We should have non-normative language that expresses that certain api need security and privacy considerations.  However, I think the WG should steer away from mandating what APIs are really 'browser-safe'.

I'm not a big fan of the term "browser-safe" since it highly depends on the definition of what a browser is. So in that sense I agree.

However I think that for all APIs that we come up with, we need to define a security model along with the API. I suspect that in many cases it large parts will still be left up to the decision of the implementation, for example what various UI look like. However I think in all cases will we need to figure out a credible security model.

When we are defining that security model that will likely determine what browser implementers will feel comfortable exposing to the pages that they render.

>> JMCF: Yes, I think this the way to go and as a result it could make sense to concentrate all API efforts under a unique, fresh new WG. And for that WG I would personally prefer the "WebApps WG way of working" i.e. distributed, lightweight and very focused on the work items, based on implementation experience. Having many deliverables is not a problem provided there are editors and people willing to do the spec work, probably based on existing implementations, and implementors supporting such a work


/ Jonas

________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx