We currently directly download the zip package, but we need to switch to downloading a simple manifest. The manifest could look like this, with the same localization structure as the webapps manifest: { "name" : "my app", "version" : "1.0a1", "size" : 1084562, "release_notes": "first release", "package_path": "http://...", "icons" : { "128" : "data:..." } "locales" { "fr_FR" : { "name" : "mon application" } } }

Needed for updates.

The only thing I would add are "required_features", so user can review the required Permissions prior to install.

We've been designing the security model around users not having to make security decisions at install/update time. Instead they always happen at runtime. I think we should have as an explicit goal *not* to show permissions stuff at updates since we never want users to chose not to apply an update for security reasons as that likely will have the opposite effect. Instead they should simply say "no" in dialogs (or in the settings app).

> We've been designing the security model around users not having to make security decisions at install/update time. Instead they always happen at runtime. Yep, we're on the same page. The plan since Barcelona meetings between UX + Security (and probably earlier) has been to enables users to review—but not act upon— permissions requirements in the update/install prompts. > I think we should have as an explicit goal *not* to show permissions stuff at updates since we never want users to chose not to apply an update for security reasons as that likely will have the opposite effect. Instead they should simply say "no" in dialogs (or in the settings app). From a UX standpoint I'm fine with this (less is more, etc), but I'd defer to Security. cc'ing Lucas and Paul for input here.

I think that not showing permissions changes during updates isn't a huge issue. iirc, one of the arguments for the runtime permissions prompts is to give users context behind their permissions decisions. There isn't much at update time that a user can base that decision off of. The only issue I can see is with implicit permissions, since those will not have to prompt. I'll have to look at the permissions matrix again, but I believe most of the implicit permissions are only granted to certified apps.

(In reply to Fabrice Desré [:fabrice] from comment #0) > We currently directly download the zip package, but we need to switch to > downloading a simple manifest. On Marketplace we pass the location of the zip file to install for packaged apps (which also means we store the zip file at a public URL for consumption). Instead are you saying we need to pull the manifest file from the packaged zip and host that as well as the zip file? Then pass the manifest URL to the install button instead of the zip file URL? When does Firefox OS download the zip file, which may contain various assets needed to run?

We can live without the enumerate permission list during the install experience for basecamp. Especially since it seems like we're far from having consensus around the right experience.

Great, thanks Lucas. I will pull the permissions list from the next round of Install prompts.

(In reply to Rob Hudson [:robhudson] from comment #6) > On Marketplace we pass the location of the zip file to install for packaged > apps (which also means we store the zip file at a public URL for > consumption). > > Instead are you saying we need to pull the manifest file from the packaged > zip and host that as well as the zip file? Then pass the manifest URL to the > install button instead of the zip file URL? When does Firefox OS download > the zip file, which may contain various assets needed to run? The mini manifest is not the same as the one in the zip file unfortunately. It can rather be seen as an update manifest. I think the marketplace can generate this mini-manifest from : - the manifest in the zip file for the name and l10n section. - the zip file itself (to get the package size). - other info that developers submit to the marketplace (release notes?). We decided to *not* have icons in this mini-manifest to prevent phishing.

Are we using the version string for anything in particular? Currently the app validator and Marketplace make no restrictions on what this version string can be. But it could be similar to add-ons where it must match the toolkit version format: https://developer.mozilla.org/en-US/docs/Toolkit_version_format For example, if the developer deletes a version and the update service returns the prior version, will Firefox OS downgrade the app? Or compare versions and realize it's a downgrade and refuse? Or something else? If we try to compare versions in any way we may need to be strict on app submission to the marketplace. (Apologies if this is a bad bug to ask this)

We're not planning on using the version for anything other than showing to the user, no. We will definitely need to have some sort of mechanism which ensures that you can't get a downgraded version. But that's not really important until we do things like allowing installs for signed apps to allow them to be installed from other websites than the signees store. Which we're not planning on allowing for now.

Here's the behavior implemented: During installation of a packaged app: When the app is first installed its .installState is "pending" and it's "downloadAvailable" and "downloading" properties are set to true. This is done based on just the data in the minimanifest, before we download the actual package. The downloadSize is set to the size from the minimanifest. As we download the package we fire "progress" events. Once the package has been downloaded we set .installState to "installed" and fire "downloaded" and "downloadapplied". Attempting to launch the app while still in "pending" throws an error. If there's an error while downloading the package we set .downloadError appropriately. .installState remains as "pending". If the cancelDownload() function is called we delete all downloaded data and set downloadprogress back to 0.

Rebased to current tree.

Comment on attachment 664736 [details] [diff] [review] patch >+ // Obtain a converter to read from a UTF-8 encoded input stream. >+ let converter = Cc["@mozilla.org/intl/scriptableunicodeconverter"] >+ .createInstance(Ci.nsIScriptableUnicodeConverter); >+ converter.charset = "UTF-8"; >+ >+ let manifest = JSON.parse(converter.ConvertToUnicode(NetUtil.readInputStreamToString(istream, >+ istream.available()) || "")); nit: indentation

In that hg commit I'm not seeing an explicit "If-None-Match"... is that handled elsewhere? I'm curious about the receipts and categories part of that too... is that something that should be in the mini manifest? Or server side at all? There's code here to treat installs and updates differently. On the server-side the mini-manifest URL is the same for both, so I want to verify that's ok. When there's an update the manifest will change along with the ETag header.

Rob, yes, the If-None-Match was added in a previous patch since this code is shared with hosted apps updates. Receipts and categories are part of the installPackage() arguments, so no need to add them to the manifest I think. It's fine of the mini-manifest URL is the same for install and updates, and in fact this is what the updating code is expecting, and it checks the ETag.

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/ee82f8e39afc for xpcshell bustage.

Yes, all the receipt stuff happens in JS-land. I.e. it's a JS-argument passed to install()/installPackage() which we then store in Gecko and expose through the App object so that it's accessible to JS running in the application. The http-layer never sees it. If you think we need to change that, please don't hesitate to raise a bug.

(In reply to Jonas Sicking (:sicking) from comment #19) > If you think we need to change that, please don't hesitate to raise a bug. Nope, just making sure I didn't miss anything. What's the intention of "categories"?

It's basically just JS-data like the receipt. The idea is that apps that has access to enumerate all installed App objects and render a launcher UI (like the b2g homescreen) can group things into categories. Again, not exposed to the http-layer at all.

Fixed the test failures there: https://tbpl.mozilla.org/?tree=Try&rev=e60242438b99

Sorry for taking so long to get on this testing-wise. I'm having difficulty seeing this working. I tried your test app on your test page (http://people.mozilla.com/~fdesre/openwebapps/test.html), but that didn't work because the packaged app being referenced doesn't have sufficient privileges to access contacts. I then tried my own test app here - http://people.rit.edu/~jds2501/downloads/appinstall.html, but that isn't working either. Am I doing something wrong? Or is there a bug here?

Spoke with Fabrice on this. Etienne is currently working on the new install and update flows, so it might be better to hold off testing this until that lands. I'll hold testing on this until the new flow lands.