Brian Smith (:briansmith, :bsmith, use NEEDINFO?) Reporter
	Description • 12 years ago

The app author can list any author of his choice in his app manifest, and we show that claim of identity to the user during app installation. Instead, unless the app is signed by a trusted app store, we should show the user the install origin instead of the author listed in the manifest.

Everywhere else in the product, we are very careful about asserting identity of people or companies in the product. That's the whole reason we have EV certificates instead of DV.

Also, the installation prompt is very much like a permission prompt, and in permission prompts we show the website origin. So, showing the website origin would be consistent with the other permission prompts.

For signed apps though, showing the manifest author field is better than showing the install origin, because the install origin will always be the marketplace for those apps, and we don't want to claim that Mozilla is the author of the apps.

	Jason Smith [:jsmith]
	Comment 1 • 12 years ago

Probably should have done this from the beginning, but it might be too late to get this implemented for v1.

	David Scravaglieri [:scravag]
	Comment 2 • 12 years ago

We wouldn't block on this for V1 but we would take a patch.

	Josh Carpenter [:jcarpenter]
	Comment 3 • 12 years ago

Makes sense to me, but I'd defer to security on the best approach.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?) Reporter
	Comment 4 • 12 years ago

installOrigin is the origin of the app that called mozApps.install or mozApps.installPackage. That isn't the origin we want to show. Instead, we want to show the origin of the app, which is the origin of the web app manifest for hosted apps and the origin of the mini manifest for packaged apps.

When we discussed this, Jonas asked whether we should show the origin for packaged apps, or the installOrigin. We need to show the (mini-manifest) origin because that is the most security-sensitive origin, as that is what directs us as to what zip file to install to install, and it is the origin that has the responsibility for notifying us about updates (especially security updates). We *don't* want to show the installOrigin because installOrigin is the origin of the store, and we don't want to say that the store is the author of the package.

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 5 • 11 years ago

For all the reasons in comment 0, this bug is important should be blocking a release I think. I'd love to see it in leo but I don't know what design work is needed. Can it just be as simple as in the attachment?

One concern I have is long URLs - for this reason I think it is better to show only the origin, but even so we need a way to either wrap or truncate the origin. And if its truncated, then this needs to be indicated to the user so they know to scroll across and see the whole thing if need be.

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 6 • 11 years ago

Meant to just show the origin

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 7 • 11 years ago

I agree with comment 4 on hosted apps - we should definitely be showing the manifestURL, since this is the origin of the app (i.e. this is what gets granted permissions for example). At the moment, we only allow one app per origin, and we forbid re-install for the same origin, so in the interested of readability, can just show origin? But is this going to be future proof? Previously there was a lot of interest in multiple apps per origin. Maybe solve that when we get to that though.

As for packaged apps, I am not sure about the suggestions above. Take for instance the our calculator package app available from https://marketplace.firefox.com/app/calculator-2.

The options are:

installOrigin: https://marketplace.firefox.com
Mini-manifest URL: https://marketplace.firefox.com/app/9f96ce77-5b2d-42ca-a0d9-10a933dd84c4/manifest.webapp
Origin of the app: app://<some locally generated id not available at install time>
origin.manifest: None in this case (but if it did have one, it might be something like app://calculator.gaiamobile.org)

Pondering this...

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 8 • 11 years ago

Ok what about this. We use manifestURL for hosted apps, and manifest.origin (see bug 852720 for details) for packaged apps. For packaged apps without an origin, we just use the name of the app since either
a) its a privileged app so the name has been reviewed
b) its a web packaged app so it's installed on a synthetic domain and can't get permissions


Hosted App:
--------------------
Install Calculator?
*App: https://calculator.domain

Packaged App (no origin parameter):
--------------------
Install Calculator?
*App: Calculator


Packaged App (origin parameter):
--------------------
Install Calculator?
*App: app://calculator.domain



The only remaining issue I see is that this doesn't disclose the update URL to the user. I am not sure that this is useful to show on the install prompt though and is maybe better exposed through app details inside the settings app.

Thoughts?

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 9 • 11 years ago

* minor correction, I meant 'origin of the manifestURL' for hosted apps above, as in the example.

I'm going to optimistically request leo? with this, but maybe koi is more realistic. See comment 0 for why this is important.

	Jason Smith [:jsmith]
	Comment 10 • 11 years ago

(In reply to Paul Theriault [:pauljt] from comment #9)
> * minor correction, I meant 'origin of the manifestURL' for hosted apps
> above, as in the example.
> 
> I'm going to optimistically request leo? with this, but maybe koi is more
> realistic. See comment 0 for why this is important.

koi is more realistic. We shouldn't be taking any changes that pose l10n risk or features at this point for leo.

	Jason Smith [:jsmith]
	Comment 11 • 11 years ago

As a point of comparison, FxAndroid did implement this feature, but they used the installOrigin for packaged apps, not the manifest.origin. If I recall past security discussions, the reasoning for showing the installOrigin for packaged apps was to give clear indication to the user on what store they were trusting when they were installing their packaged app, such that they know who they are trusting to get their zip archive from.

The problem with using manifest.origin for packaged apps here as the UI choice is that I question if that's really going to be end-user understandable and add user trust. If I was your average joe seeing app://marketplace.firefox.com in the UI, what does that mean?

As for the update URL - I'd say let's file a different bug for that if we want to consider that, only cause this bug is focusing on the origin piece, not the update URL.

	bhavana bajaj [:bajaj]
	Comment 12 • 11 years ago

Moving the flag to koi: ? here considering this is not a blocker bug and may not fit well with the leo timelines.

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 13 • 11 years ago

> The problem with using manifest.origin for packaged apps here as the UI
> choice is that I question if that's really going to be end-user
> understandable and add user trust. If I was your average joe seeing
> app://marketplace.firefox.com in the UI, what does that mean?

To be clear, I don't mean the location of the mini-manifest. I mean the 'origin' attribute as defined inside the app manifest itself (from 852720). IE most apps dont set this, so we can't use this, but some do, so in that we should display it, since it will end up being the origin which gets displayed in permission prompts etc.

	Lisa Brewster [:adora]
	Comment 14 • 11 years ago

In response to comment 8, I just want to clarify what is and isn't verified by the app review team.  

For privileged apps, we verify that the code isn't abusing permissions or doing anything malicious, but we don't verify the identity of the developer/app name.  For example, the developer could list their identity to be Foursquare, and only staff reviewers (eviljeff and myself) have high enough permissions to perform a common sense check on the email address to see if it looks legit. 

This doesn't scale and is absolutely not foolproof, plus if we don't have suspicion of malicious intent, this is really a trademark check which may put our DMCA Safe Harbor status at risk.  (I've currently got a bug filed with Legal to explore what additional policies we can set in the short term, but without an engineering solution we'll still only be able to catch the most obvious misuses.)

I don't think any of this makes a material impact on the direction of this bug, I just don't want anyone making assumptions that the app review team can't deliver.