Re: App Manifest & API Proposal

Ok, thanks for the responses.

For (1) we can expect a text change, right?

For (2), If the app manifest if obtained over non-secure HTTP, it is subject to modification. If the app is delivered over non-secure HTTP, even more can be modified. So is the plan to provide some kind of user warning when the manifest and/or app (including assets from the same origin) are delivered via non-secure HTTP (in the absence of a manifest signature)? And even if a manifest signature is provided how does it ensure protection of the assets (e.g. JS, CSS, and HTML) if they are delivered over non-secure HTTP? Does HTTPS need to be enforced, and cert domain validation as well?

For 3), I understand. We went through a lot of the similar issues in WAC, so maybe some of that experience will be useful in the discussion.

For 4), the ability to present the user with info/options prior to downloading the app (or its root page), or to process the manifest in an app manager / AppStore client, is probably the key added value. So from that perspective, i agree that supporting similar info In a Web page markup doesn't add value in this case, and does prevent the pre-processing capability.

Thanks,
Bryan Sullivan

On May 13, 2012, at 7:04 PM, "Anant Narayanan" <anant@mozilla.com> wrote:

> Hi Sullivan,
> 
> Thanks for your comments, some responses inline:
> 
> On 5/13/2012 1:11 AM, SULLIVAN, BRYAN L wrote:
>> 1) Re "version: A string that represents the version of this manifest. The User-Agent does not interpret this value in any way and is opaque to everyone but the application itself.": it's also likely that the "privileged caller" may also need to interpret this, as one key use case for the a privileged caller is an appstore client.
> 
> Yes, absolutely.
> 
>> 2) How do you propose that the manifest information be trusted, through signature on the JSON file?
> 
> We haven't devised any signing scheme yet, we are only relying on manifests being served over SSL for establishing trust. I recall someone from Google saying something quote-worthy regarding this: "If it's good enough for your banking, it's good enough to install some apps" :)
> 
> That said, we are definitely open to adding signatures. This already seems required for packaged apps for highly sensitive apps like phone dialers, as we are discovering for B2G.
> 
>> 3) Re softening of the requirement "There must only be one application per origin.": you will likely need an App ID field (a URI), for which there should be only one installation at a time (otherwise per the manifest trust above, an untrusted app could pose as another app).
> 
> Correct, this is one of the reasons we enforce one app per origin (posing as another app becomes very hard). Relaxing that restriction won't be trivial as we have to consider this and many other repercussions.
> 
>> 4) For which of the attributes, instead of being in a manifest, could we achieve the same purpose with HEAD section elements in the start page of the app? I guess this question comes down to what is the inherent value of a manifest, and also how can we get similar value for these attributes on normal Web pages (with no manifest).
> 
> As I mentioned in another email, I'm not too worried about duplication in two places as the goals are different. The point of storing such information in the manifest is to enable various parties to make decisions about how they will handle an app before purchase/install/launch time.
> 
> As you noted in your previous email, the manifest is also an appropriate place to let the developer declare what APIs they intend to use, regardless of whether the UA asks for user permission up-front or at run-time.
> 
> Regards,
> -Anant
>

Received on Sunday, 13 May 2012 21:18:04 UTC