W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2010

Re: Updated Features draft

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 15 Sep 2010 14:53:22 +0200
To: Frederick.Hirsch@nokia.com
Cc: public-device-apis@w3.org
Message-ID: <1284555202.2387.2353.camel@localhost>
Le mercredi 15 septembre 2010 à 00:32 +0200, Frederick.Hirsch@nokia.com 
> Thus the architecture simplifies to the following:
> 
> 1. Identified APIs (or all APIs)
> 2. trust domains
> 3. capabilities allowed for each trust domain, either across all APIs or on a  per-API basis

I’m not convinced that we even need (3) at this point; I’m not quite
sure what this would buy us, especially as I don’t think any browser
currently deployed use that sub-level framework, and that W3C Widgets
don’t refer to them either.

> This  corresponds to the Nokia contribution.

Looking at Nokia’s security framework for widget runtime engines:
http://wiki.forum.nokia.com/index.php/Widget_Platform_Security
it looks like the capabilities are very coarse (e.g. lumping together
any kind of “user data”), which wouldn’t match what we have currently
defined in our APIs, and would in fact go against our minimalization
approach.

I think that this defect is likely to happen for any sub-API granularity
(which I understand capabilities are).

> So, I'm ok with the simplification of not referring to features and
> focusing on trust domains + capabilities + API naming (method + class
> name I assume).
> 
> I'd be interested whether Paddy and Laura agree.
> 
> It would be great in my opinion if you can take another pass.

I’ll take a stab it (hopefully this week), but be warned that
capabilities may be a casualty in that process :)

Dom 
Received on Wednesday, 15 September 2010 12:53:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:13 GMT