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" <[email protected]> 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 >
