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

Hi. Jungkee, Mounir, Jonas and all.

Jungkee, thanks a lot for your proposal.

Mounir and Jonas, for going forward, the WG have to get your feedback!! I
hope to get your opinions soon.

Best regards,
Wonsuk.

> -----Original Message-----
> From: Jungkee Song [mailto:jungkee.song@samsung.com]
> Sent: Wednesday, February 06, 2013 9:26 PM
> To: 'Jonas Sicking'; mounir@lamouri.fr
> Cc: public-sysapps@w3.org; 'Wonsuk Lee'; ming79.jin@samsung.com;
> j.majnert@samsung.com
> Subject: 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, 13 February 2013 14:08:56 UTC