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

Hi Mounir, Jonas and all,

I've tried to prepare a merged single document out of the proposals. (The
editors were put in alphabetical order):
http://jungkees.github.com/sysapps/proposals/Runtime/Overview.html
(Pull request has been made on the original repo.)

The threat model section has not been inserted as it seems the consensus is
to put it in a separate deliverable.

I've used the ToC that I proposed having tried to not miss any part of the
text from both proposals. The exceptions lie in the system message and
interface definition parts. 

Regarding the system message, I left Samsung's service request handling as
it is but it was due to the difficulties to put Mozilla's content in a
proper way. We would be perfectly fine if Mozilla sorted out the system
message part in accordance with the other part of the text.

In terms of the interface definition part, I left Samsung's proposal as the
simple merge would not work. It would be fine to replace it with refined
version based on discussion. (Mozilla's interfaces would be good if it will
turn out to be better to go with). From Samsung's proposal, the points are:

- The division of interfaces, RutimeInstaller and RuntimeExecutionManager,
would be sort of a self-explanatory in terms of the functionalities and
also easier to put in places separately.

- Application authors can access the application object through runtime
object, runtime.application; the applications can utilize the event
handlers for application lifecycle events e.g., launch, pause, resume,
terminate as well as hide() or exit() itself. Also, they can define
additional event handlers for the other runtime defined system events, in
any.

- It would be useful to query the applications with the ApplicationState
option; e.g., runtime.getApplication("paused", appList);

If we stay with Samsung's proposal, the attributes and methods for
application update from Mozilla's proposal should be merged.

As of now, since the two texts have been merged it would not be as
consistent as they used to be on their own. However, it should have been
ready with more topics which are necessary to discuss. I believe we can
refine it together! ;)

I'm wondering if this merged document would be acceptable as a base
document that we will work on toward FPWD.


Jungkee

> -----Original Message-----
> From: ¼ÛÁ¤±â [mailto:jungkee.song@samsung.com]
> Sent: Wednesday, January 30, 2013 3:03 PM
> To: 'Jonas Sicking'; 'Wonsuk Lee'
> Cc: public-sysapps@w3.org
> Subject: 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, 6 February 2013 12:26:52 UTC