Re: Runtime and Security Model for Web Applications

On 02/01/13 11:57, John Lyle wrote:
> I think that the document highlights some really good areas for
> discussion and that there is plenty of overlap with our proposal.

... which is a good sign, right? :)

> * Is there a special reason why application manifests need to be
> redefined, considering the presence of Widget packaging standards?  Is
> it just the need to define new elements, or a desire to get away from
> XML, or both?  Both of which are perfectly good reasons, I'm just
> interested to know the motivation.

As Jonas said, JSON seemed better. It isn't really a decision made by
this specification given that Mozilla had a Open Web App Manifest
specification since some time already.

However, that part of the specification can easily be moved to WebApps
and change to whatever format. The rest of the specification should be
independent of the format of the application manifest. Some rewording
might be needed though.

> * "required_features" is distinct from "permissions".  What happens when
> a permission is requested for a feature that isn't required?  Or the
> other way around?

Those are two different things. You can ask for a feature that doesn't
require a permission. Also, require_features is simply a hint for the
UA. It isn't mandatory for the app author to list all required features
it would just help the UA filter some applications that can't be run.

> * Is there a concept of a feature or permission that is optionally
> required? I'm thinking of situations where the device is under a
> corporate policy, for example, and a certain feature or permission can't
> be granted under any circumstance.  Can an application express that this
> feature is a deal breaker, or are all 'required' features actually
> optional?

Required features is indeed for mandatory features. Anything optional
should be checked at runtime. For example, a 3D game will require
'webgl' but a game using IndexedDB to store some scores might just
implement a localstorage fallback and not required 'indexeddb'... That
makes me think that some features might need to be expressed like (foo
|| bar)...

> * The 'version' string is not interpreted, but in the 'updates' section,
> the UA is supposed to compare version numbers.  Can you elaborate on the
> purpose of the version number?

It is now fixed locally and the UA isn't supposed to compare the versions.

> * Where is the origin of the application defined by the app?  It isn't
> listed in the manifest properties, but referenced frequently.  In
> particular, section 3.1 lists the 'origin' as being the origin described
> in the manifest, separately from the installOrigin.

Sorry for the confusion. I have added a description for "application's
origin".

> * Is it intended that the developer's website be connected, in any way,
> to the origin of the web app or manifest?  Is the developer's website
> purely given for information?

If you speak of developer.url, yes, it is purely informational.

> * For packaged apps there are two copies of a manifest: one outside and
> one inside.  Which has precedence?  What happens when they conflict? 
> You mentioned that this is for update / installation purposes - could
> you elaborate?  It seems to me that these shouldn't both be called
> 'manifest' as they serve different purposes and have different
> contents.  Does the manifest inside the package contain the 'package'
> section?  If not, it wont contain a copy of the URL of the package,
> which might be a problem for downloading updates.

Jonas and I have different opinions on this. In my opinion, we should
simply have the same manifest inside and outside the package. The only
reason we have a manifest outside the package is because it is easier to
check for an update if we give a manifest. In other words, if HTTP
semantics do not apply, we can download the manifest and check if it has
changed or check if the checksum of the package has changed (or do
anything that sounds clever). If we had no external manifest, the only
solution would be downloading the package and checking if there is an
update. Otherwise, relying on some ZIP format specificities that might
not be working very well in practice (ie. get the file table of the zip
file and only download that and the manifest). The main concern is
obviously to same bandwidth.

>From there, having the same manifest or not doesn't really matter as
long as the external one as the info required for it and the internal
one has the other info. The only reason it would matter would be to save
a few bytes. I think requiring the same manifest would make things
easier and more reliable.

> How is the
> application manifest inside the package proof that the update is
> genuine?  Are you assuming that packages are served from trusted origins
> only over TLS/SSL?

This sentence about genuine updates was assuming that the package is
signed. In that case, we can trust anything inside the package.

> * Can packaged apps load anything (images, for example) from the network?

As the Web does.

> * You don't seem to have defined 'hosted' applications, except "not a
> packaged application".  Can a system application be a hosted
> application?  This is a bit unclear.

I'm not sure what you mean by "system application". A hosted application
is an application that is related to real pages on the web using
appcache for offline usage but getting update as a website would. Except
for security concerns, there is no reason why those application should
be treated differently than packaged applications.

> * Applications are isolated from each other.  In some of our (webinos)
> use cases, apps need to be able to communicate with each other in a
> limited way (e.g., over a message channel).  Is this forbidden in your
> proposal?  Or can one application trigger a System Message to another
> somehow?

Depending on what you want to do, Web Activities might help you.
Otherwise, we thought of a simple solution that would allow cross-app
communication involving ports but that seems to be out of the scope of
this specification.

> * What is the 'pool of messages' used for when an application has no
> message handler?  Is this in case the application defines a message
> handler subsequently, and then receives all the (old) messages?

Yes. When a system message is fired on an application, that case will
hit the following sentence:
"Otherwise, if the application is running and no handler is defined, the
UA must add the message to the pool of messages;"
In addition, setMessageHandler has this sentence:
"If callback is not null and there was no message handler for the given
type and there are messages in the pool of messages for the type, then
the UA must start an asynchronous task that executes all the messages in
the pool by the new handler in a FIFO basis and then remove all those
messages from the pool of messages."

> * Permissions can be granted automatically, denied automatically,
> granted/denied by the user at install time, or granted/denied by the
> user at runtime.  Is there a file or system for saving these decisions
> and specifying defaults?  This (or at least requirements for it) seem
> like a good thing to include in a potential standard.

I do not think this should be specified. Where and how the permissions
are saving is an implementation detail as long as everything work as
expected.

> * The "basic Permissions" specified in 8.3 - is this list exhaustive, or
> are these only examples?  Geolocation seems an odd one to include with
> the others - in our experience, Geolocation is bit 'special'.

This list is the list of permissions that are related to specification
that will unlikely be updated to add the permission "keyword". They are
not enabled by default. They are just defined in this specification
because they can't - unlikely will - be defined in their own specification.

> * I suggest not using the terms 'trust', 'trusted', 'trusty' or similar
> in specifications because it inspires no end of confusion (see Dieter
> Gollmann's classic essay "Why Trust is Bad For Security").  If such
> words really need to be used, a definition would be helpful.

I think 'trust' defines better how this is working than 'privileged'. As
I see it, 'trust' is the cause and 'privileged' the consequences. We
indeed give privileges to some applications but mostly because we trust
the application to not do anything nasty with those privileges.

As a user, if I browser a store and see that "this application is
privileged" I will definitely be anxious regarding what they could do
with those privileges. However, if I see "this application is trusted"
and if I trust the store, I would think that I am safe.

Anyway, this is only wording and if you think privileged is better, I
will just change that.

> * I'm concerned that relying only on the trustworthiness of the origin
> of an application is too limited a measure.  It removes the opportunity
> for system level applications to be side-loaded (which is a *big*
> decision to make) as well as having some other limitations.  I can't
> place trust in an author, only a distributor.  It also provides no way
> for application developers to have assurance in the integrity of their
> packaged apps that are distributed by third parties.  However, as I'm
> aware this is the approach taken in Firefox extensions, i'd be
> interested to know whether you have analysed how well this has worked in
> your experiences.

As you said, Firefox extensions is using some kind of trusted extensions
mechanisms after reviews. For the moment, the only thing implement in
Firefox OS is that exact same system. Non-reviewed applications will be
hosted applications and will have no privileges.

> * Section 8.4.4 seems to be a discussion rather than a set of security
> considerations.  I think there's a good case for a more strict set of
> security requirements, expected threats and definition of the
> relationships and reliance between different parties involved.  I would
> be very happy to collaborate on such a section.

It is indeed a discussion. That is why the section is marked "non
normative".

> * Section 8.4.5 - In line with the principle of least privilege, in
> webinos we're specifying that applications must specify their
> 'connect-src' in the manifest, such that applications can only connect
> using websockets / XHR to pre-defined domains. Can Packaged apps in this
> specification create XHRs to any origin?
> * Section 8.4.5 - If a packaged app embeds an iframe pointing to another
> origin, what is the expected behaviour?

For both questions: we do exactly the same thing as the Web does.

Thank you for your feedback.

--
Mounir

Received on Friday, 4 January 2013 19:51:37 UTC