RE: Request to make one proposal for execution model and security model

Hi Jonas and all,

Please see comments inline.

Suggestion - new Table of Contents (ToC):
1. Introduction
2. Terminology or Definitions
3. (System or Web) Application Management
---Manifest
---(System or Web) Application Origin
---Packaged applications or Packaging
---Delivery
---Installation
---Uninstallation
---Updates
---Interface (APIs)
4. Runtime Browsing Context
5. Execution Model
---Execution Lifecycle: States and Events
---Launching
---Service Request Handling or System Messages
---Pause and Resume
---Terminate
---Consequences of visibility
---Interface (APIs)
6. Security Model
---Threat model
---Application Trust Model
---Browsing Context Trust Model and Navigation
---Content and Network Security
---API Security or Permissions
---Data isolation or Private Storage


Jungkee

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> 
> Comparing the Samsung and Mozilla specifications, the main differences
> seem to be:
> 
> * The Samsung specification doesn't define a delivery format, but rather
> leaves that up to other specifications.

As you suggested, we can deal with the topic within the scope of this
deliverable until it matures and is agreed to be a separate deliverable. I
kept it in the suggested ToC.

> * The APIs for installing/uninstalling/updating apps are different.
> The feature set of the Mozilla API appears to be a superset of the feature
> set of the Samsung API. For example it supports more fine-grained control
> over updates.

Agreed. In terms of this part of APIs (what we called RuntimeInstaller
interface), the feature set of Mozilla would be superset. I suggest we sort
out the namespace and interface definition issue in the interface section
of #3 in the suggested ToC.

> * The Samsung API for Application objects supports managing application
> visibility and has a few more events for application life cycle
> (launch/pause/resume).

Yes, we would like to deal with pause and resume of the applications.

> * The Mozilla API for Application objects has more support for delivery
> format integration, for example though the manifest property.

I think we can come to a better interface adding pause/resume from Samsung
for example based on the list discussion.

> * The security model in both drafts are very vaguely defined :-)
> Especially defining the details around signing is missing from both
> specifications.

Right. Either #3 or #6 of the suggested ToC should specify it. Any
suggestion?


> * The Mozilla specification contains System Messages.
> * The Samsung specification contains service pages (which I've yet to
> fully read up on, but they seem to serve a similar goal to system
> messages)

Yes they do. I put the topic as "Service Request Handling or System
Messages" in the suggested ToC, but we can create an independent section if
it would look more natural.


> While I think we could use write the delivery format as a separate
> specification, I think we need to have a defined delivery format. Both
> because having an interoperable delivery format is required in order to
> have interoperable implementations, and because the different delivery
> formats have different capabilities and so affects what features we design
> for the runtime. For example, only the Mozilla delivery formats support
> system messages, and so it doesn't make sense to define system messages in
> the runtime if the delivery format doesn't support them.
>
> So I'm happy to explore breaking out the delivery mechanism out of the
> runtime spec, but only once we have an agreed upon delivery mechanism and
> published working draft for it.

I agree.

> 
> Would it be acceptable to you to add the features from the Samsung
> specification that are missing in the Mozilla specification and use that
> as basis for FPWD? In particular we'd need to add:

Indeed, I agree both Mozilla and Samsung proposals deal with almost the
same scope though we have topics to work on as listed in this email.
However, I would like to suggest we organize the contents in a better
shape. For example, manifest, packaging, delivery can be put under an
application management section, and data isolation, threat model,
permissions can go in a security section. I've tried to organize the
suggested ToC in a manner that it meets all the topics in Mozilla proposal
and Samsung proposal as well as threat model.

It would be nice of you to review the ToC.


> * Events for application life cycle. These would likely have to be added
> to the ApplicationManagement interface in the mozilla draft since the
> Application object is accessible to other sites than the application
> itself.
> * API for managing showing/hiding an application.
> 
> This would leave figuring out service pages vs. system messages, but that
> might not need to hold up the FPWD? I think Google has something similar
> to service pages too in their runtime so it's something I'm happy to look
> into more.
> 
> > In addition, concerning to security model, we had proposal from John
> > Lyle of Oxford. So I think it would be great if this is harmonized
> > with security part of merged one. What do you think?
> 
> The document from John Lyle seems more like a requirements document, than
> an actual specification for a security model. So I think it's fine to keep
> as a separate document that we can develop separately and use to evaluate
> the security model of the various drafts for the security model as we go.

Even though I tried to put thread model in #6. Security Model section
above, but it sounds it's fine if it goes as a separate deliverable.


> / Jonas

Received on Wednesday, 30 January 2013 06:03:38 UTC