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 Wednesday, 13 February 2013 15:28:40 UTC