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

Hi John,

Thank you very much for your comments in detail.
Sorry for not replying to every comment at this moment. Once we are ready
with merged document, I'll bring those comments in the related part of the
content.

Best regards,
Jungkee

> -----Original Message-----
> From: John Lyle [mailto:john.lyle@cs.ox.ac.uk]
> Sent: Thursday, February 14, 2013 12:28 AM
> To: Wonsuk Lee
> Cc: 'Jungkee Song'; 'Jonas Sicking'; mounir@lamouri.fr; public-
> sysapps@w3.org; ming79.jin@samsung.com; j.majnert@samsung.com
> Subject: Re: Request to make one proposal for execution model and security
> model
> 
> Dear all,
> 
> This document looks like a really good base for a FPWD.
> 
> I have some comments (yes, another long list - sorry!)
> 
> Best wishes,
> 
> John
> 
> ---
> 
> Abstract
> 
> * It would be helpful to try and point to a definition of the browser
> security model (although I'm aware than no such thing really exists) -
> This might help highlight differences later on in the document.
> * Nitpick: Can I suggest you avoid using the word 'traditional'? I think
> it can be removed almost everywhere, as 'traditional' websites and
> browser-based execution models are still valid today.
> 
> Status
> 
> * The sentence "This paragraph is here to demonstrate that it is possible
> to add a completely custom piece of HTML inside the SotD."
> could be removed.
> 
> Introduction
> 
> * I'm not sure that this proposal does define "core requirements" - it
> reads more like a specification, which I'm guessing is the intention?
> Based on email discussion, there appears to be a desire to specify exact
> formats and grammars for manifests, so probably this is more than "core
> requirements".
> 
> Terminology
> 
> * By "Installable" it sounds like you mean "can be installed" rather than
> "must be installed". Is that what you intend? I think it would be worth
> having "application MUST be installed before they may be executed"
> somewhere in the document to clarify this, possibly in section 3.5.
> 
> System Application Management
> 
> * 3.1.1.1 - is there any need to state that new specifications can add new
> properties to the manifest? I suggest this is replaced with
> "Implementations MUST include the basic properties described below and MAY
> contain additional features".
> * On a similar note, as far as I know, there's no standard way of doing
> namespacing with JSON, so it's probably not worth talking about extensions
> as they will certainly contain namespace clashes.
> * Also - would it be worth having a property indicating the specification
> that this manifest is conformant with (e.g., "SysApps v0.1", or "SysApps
> v0.1 + B2G extensions", ... )?
> * 3.1.1.2 - is there any reason why it is "Usage of an API without a
> corresponding entry in the manifest SHOULD fail." rather that "MUST fail"
?
> * It might be worth having a table of permissions and access types, as for
> some APIs the current set may not make much sense. I also wonder whether
> this would be better as an array rather than four strings (['read',
> 'write', 'create'])
> * 3.2.1 - is the 'uniqueID' unique to the system application or to the
> _instance_ of the system application? I'm guessing you mean to the system
> application, and that two instances of the same application would have the
> same uniqueId.
> * 3.2.2 - You mention in step (3) that system applications are assigned
> uniqueIds (and then checked against the URI during dereferencing). When
> and how does the assignment happen? I don't see an 'id' field in the
> manifest - is it generated by the runtime? Or does it refer to the
> dereferencing of a URI given within the runtime execution of a system
> application which already has an origin and therefore a uniqueId?
> * You mention that any attempt to access system application package
> content through the 'file://' scheme should fail. Just to clarify: this is
> not supposed to affect normal websites, presumably? They can still access
> file content that is part of a system application like any other file on a
> filesystem?
> * 3.3 - Just to clarify: a packaged application has content both inside
> and potentially outside the container, whereas a hosted application has
> all of its content served from the web (or the local file system?)
> including the manifest.
> * 3.3.2 - Again, I'd recommend reusing some of the terminology and details
> from the widget packaging specifications for the package format section.
> Their spec is almost embarassingly detailed and thorough.
> * 3.3.4 - as per previous discussions, I'd suggest renaming this manifest
> to something different, just to clarify the different purpose and content
> of the external package manifest and the internal manifest.
> * 3.5 - There needs to be a definition of how system applications would be
> signed, and how to identify and verify said signatures.
> * 3.6 - It might be worth clarifying what a system application's "private
> data" actually means. I can also imagine situations where this isn't
ideal.
> Perhaps this should be a "should" not a "must"?
> * 3.7 - Could you clarify what is mean by "the application manifest inside
> the package should always be checked to make sure the update (or the
> install) is genuine." - perhaps this could be expanded to identify why the
> update would _not_ be genuine?
> * 3.10 - What use case do you have for the RuntimeInstaller interface?
> I'm sure this is quite straightforward, but I'm not clear what you have in
> mind. Are there some UI expectations on calling 'install' or 'uninstall' ?
> I have essentially the same question with the RuntimeExecutionManager's
> 'getApplications' method (5.7)
> 
> Security Model
> 
> * 6.2 - What is a "privileged' system application with regards to this
> specification? I think we have discussd this before, but it is not given
> in the document.
> * 6.4.3 - What is the 'navigator.apps.management" API? And the desktop-
> notification API - is that the WebNotification API?
> 
> --
> 
> 
> On 13/02/13 14:08, Wonsuk Lee wrote:
> > 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 Monday, 18 February 2013 13:16:01 UTC