W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

Re: System Level APIs draft proposal

From: Niklas Widell <niklas.widell@ericsson.com>
Date: Thu, 3 May 2012 10:30:39 +0200
To: Jonas Sicking <jonas@sicking.cc>
CC: Doug Turner <dougt@mozilla.com>, "Carr, Wayne" <wayne.carr@intel.com>, "Tran, Dzung D" <dzung.d.tran@intel.com>, Robin Berjon <robin@berjon.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <7BD35556-A01F-4D82-A755-BE9D1CB051CC@ericsson.com>

On 3 maj 2012, at 01:44, Jonas Sicking wrote:

> On Wed, May 2, 2012 at 9:31 AM, Doug Turner <dougt@mozilla.com> wrote:
> On May 2, 2012, at 2:33 AM, Niklas Widell wrote:
> ...
> 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.

IMHO "browser-safe" is the least-bad term for at least talking about this, something more strict might be needed for the specs. 

> 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.
> / Jonas

Will there be one such security model or many? Can one such security model seamlessly cover both restricted/controlled/curated environments and wild-web scenarios?
Maybe we should define "threat levels" for each API to indicate how potentially dangerous it is to use, at least in order to somehow clarify the distinctions needed and reduce the confusion about different degrees of threat associated.  For example 

"green"  - harmless, can be exposed without any security arrangement. Maybe a remote chance of fingerprinting. Example would be Battery or Vibration APIs

"orange" - could be bad, but the user is at least probably able to understand the implications of using the API, thus should be able to make a meaningful decision about allowing it. I think geolocation and capture/getUserMedia falls in this category. 

"red" - could be bad, and it cannot be expected that a normal user understands the implications of using the API. The risk is too hard difficult to explain in prompts, so the api should only be used in a restricted environment, for instance in a signed "app" something similar. Many of the system apis would fall in this category, e.g. for background service, more advanced telephony, file system etc. 

By using such a classification the various threats can probably more easily be understood, discussed and managed, and it would also allow keeping the same functionality exposed to different security levels in one spec.


Received on Thursday, 3 May 2012 08:31:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC