Re: [Execution and Security Model] Proposal from Samsung Electronics

On 21/02/13 11:00, Janusz Majnert wrote:
> Another issue I wanted to bring up here is the number of "trust 
> levels" in the specification. Do you think 2 is enough?
> With 2 levels, we would have to put all security and privacy sensitive 
> APIs in the second (trusted) level. It's an all-or-nothing situation. 
> Wouldn't it be better to separate this level into two and allow 
> implementations to configure how the APIs are distributed among them?

Hi Janusz,

Apologies if this is all obvious to everyone else, but for my 
understanding can we just separate out a few things?  When it comes to 
talking about 'trust levels' there are the following concerns:

(a) The knowledge of the integrity and authenticity of the application 
and its content ('trustability' to some)
(b) The belief that the user (or another authority) may have in the 
application's good behaviour ('trustworthiness' to some).
(c) The threat of a malicious application misusing a particular API.
(d) The rules governing which types of applications can access which APIs.

It's worth having levels to classify applications on the grounds of 
(a).  E.g., is the application the one that we think it is?  If it's 
served over HTTP, or in an unsigned package that has never been used 
before, we don't know, so 'untrustable' ought to exist as a level.

If it *is* trustable, then you can begin to categorise it based on (b).  
E.g., does the user have good experiences with the application (or the 
developer) and do they therefore believe it to be a non-malicious 
application?  As well as the user's opinion, the same question can be 
asked of other authorities (anti-virus companies, app stores or 
manufacturers).  These can be expressed as distributor signatures or in 
other ways.  You can therefore imagine a range of levels here, depending 
on how many parties are involved.  Each system might define its own set 
of levels depending on the combination of certain opinions by different 
authorities. WAC has four levels based on concerns (a) and (b) [1].  You 
could also treat every application completely independently.

As an orthogonal issue, there's (c) - the analysis of APIs based on the 
impact of them being misused.  Each API might be considered 
independently, or one might lump applicationsinto two categories - 
'safe' and 'unsafe' or three - 'safe', 'unsafe' and 'dangerous', or any 
other system.  Onemight also define pre-requisite UI flows and 
constraints required to use each API, as I believe Mozilla did with 
their API analysis [2].

Finally, there's (d) - the rules dictating whether a certain API or API 
category should be made accessible to a certain application category.  
Do 'untrustable' applications have any access to the 'unsafe' APIs? And 
so on.  There's overlap with step (c) of course.

You are suggesting that there should be 3 levels to deal with (a) and 
(b), each API should be treated independently for (c) and that (d) 
should be down to the platform implementation.  Right?

In Mounir's proposal, there are 'trusted' and 'untrusted' applications, 
so 2 levels for part (a) and (b).  There's no definition for (c) or (d), 
so presumably these are platform-dependent.

I would like to see at least three levels for (a) and (b) to capture 
applications that are 'untrustable', 'trustable but not considered 
trustworthy' and 'considered trustworthy'.  Then I'd like to see some 
analysis of APIs to define (c) on a per-API basis.  For (d) I'd like to 
see the specification contain recommendations.

I hope that makes sense.

Best wishes,

John

[1] http://specs.wacapps.net/core/#processing-widget-signature
[2] https://wiki.mozilla.org/WebAPI

Received on Thursday, 21 February 2013 13:10:42 UTC