1232664 - Allow developers to whitelist their domains for easier (non-AMO) install (inline install)

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Markus Jaritz [:designakt] (UX)]

Currently on all domains except AMO installing an addon first results in a warning that the installation has been blocked. While this is probably needed to limit unintentional installs, it should be omitted for certain domains per add-on to allow the developer to also advertise and distribute the add-on on their own terms on their website.
(Or would this result in a security risk I am missing?)

see: https://groups.google.com/d/msg/mozilla.addons.user-experience/t9q_PWG_Row/m1rabRO4DAAJ

Comment 1

[Andy McKay]

ni: dveditz because I'm pretty sure this is a security concern

Also if this did happen there would be other restrictions like:
* the information would have to be in the add-on 
* that information would have to be passed securely somehow to the browser so it knows this information prior to showing the install dialog

Comment 2

[Tony Mechelynck [:tonymec]]

Can't you add a "Permission" to "Install Add-ons" for a particular site manually? Currently the SeaMonkey Permissions interface — Permissions tab of the Data Manager as well as chrome://communicator/content/permissions/permissionsManager.xul — is totally broken in SeaMonkey, so I cannot test it here. OTOH the warning mentioned in comment #0 used to include a checkbox to whitelist the current site, but IIUC that checkbox was removed quite some time ago for security reasons. But AFAIK it is (or ought to be) still possible to whitelist a given site independently of the Add-ons Manager via the Permissions interface.

Comment 3

[Daniel Veditz [:dveditz]]

We allow users to configure this using an "Exceptions" button on about:preferences#security, and generally we let add-ons modify user prefs (subject to the "No Surprises" rule). I don't see why we wouldn't let add-ons modify this particular pref(-like) setting. In fact I'd be surprised if some of them weren't already doing so.

On the other hand the user already got past that block and installed the add-on: they should get updates automatically without having to re-install. There may not be a lot of need for this.

Comment 4

[Markus Jaritz [:designakt] (UX)]

(In reply to Daniel Veditz [:dveditz] from comment #3)
> We allow users to configure this using an "Exceptions" button on
> about:preferences#security, and generally we let add-ons modify user prefs
> (subject to the "No Surprises" rule). I don't see why we wouldn't let
> add-ons modify this particular pref(-like) setting. In fact I'd be surprised
> if some of them weren't already doing so.
> 
> On the other hand the user already got past that block and installed the
> add-on: they should get updates automatically without having to re-install.
> There may not be a lot of need for this.

I am asking to allow add-on developers to specify a domain from which users can install a specific add-on without the warning. - As easy as from AMO.
Much like the option for simpler install in Google Chrome:
https://developer.chrome.com/webstore/inline_installation

Comment 5

[Daniel Veditz [:dveditz]]

I'm not sure what you're asking. AFAIK add-ons today (maybe not WebExtensions) have the power to alter the permissions that control this so I'm interpreting "Allow" in a review-y sense. Seems like we allow similarly powerful permission and preference changes when appropriate to the purpose of the add-on and I don't see why this would be different (that is, yes, allow it if the add-on isn't crazy about it).

Users can self-manage these permissions in preferences and could in theory notice the actions of a rogue add-on or recover from the damage once the add-on has been removed.

I don't know why an add-on author would feel the need to do this since in order to set this permission the add-ons users have already demonstrated that this wasn't a road-block for them. That's merely an observation; I don't know why add-ons authors do a lot of the things they do.

Comment 6

[Markus Jaritz [:designakt] (UX)]

(In reply to Daniel Veditz [:dveditz] from comment #5)
> I'm not sure what you're asking. AFAIK add-ons today (maybe not
> WebExtensions) have the power to alter the permissions that control this so
> I'm interpreting "Allow" in a review-y sense. Seems like we allow similarly
> powerful permission and preference changes when appropriate to the purpose
> of the add-on and I don't see why this would be different (that is, yes,
> allow it if the add-on isn't crazy about it).

I have the feeling we are talking about different things. Sorry if I am being unclear.
I understand your comment to apply to what an add-on can do once it is installed. What I am asking is, that an add-on - let's say one I created - can be installed from my website without the warning we currently show on every website except AMO.

The article from Google I linked describes the problem very good. In their case it is even a bigger problem, as they do not allow add-ons to be installed from anywhere except their store. Unless the developer specifies a domain to be linked to a certain add-on:
https://developer.chrome.com/webstore/inline_installation#verified-site

The goal would be to make installation of add-ons easier on it's developers site and allow developers to better advertise their add-ons on their website, as they right there could prompt the users to install the add-on very easily. (without the warning)

Comment 7

[Tony Mechelynck [:tonymec]]

IIUC, what Markus wants is that a user be able to tell Firefox (or Thunderbird, or SeaMonkey) that *any* add-on installs from some particular site (let's say johndoe.example.com) are to be accepted immediately, with nothing amounting to an "Are you sure?" warning.

What I said in comment #2 is that IIUC such a UI already exists, albeit maybe not very discoverable, and in any case not in the Add-ons Manager itself, but in the Permissions Manager, where it is (or, on SeaMonkey and maybe Thunderbird, would be except for bug 1188348) possible to allow an arbitrary site (let's say the above-mentioned johndoe.example.com) to "Install Add-ons". Once such permission has been set, add-on installs _from that particular site_ will be accepted just like they already are from addons.mozilla.org, while the behaviour toward other sites wouldn't be changed.

Comment 8

[Markus Jaritz [:designakt] (UX)]

No, that is not what I am trying to say.

I am talking about what the developer of an add-on can specify, not what the user can specify.

I am trying to say that the add-on developer (John Doe) should be able to specify (in AMO) that a specific URL (johndoe.example.com) is accepted to install their add-on (JohnDoeAddon.xpi) without warning the user first.

I would guess this might work something like this:
The developer defines an install-URL on submitting their add-on to AMO (which will be verified by AMO). At the start of an add-on installation Firefox mit check with AMO if the URL is ok to install this add-on, and not warn the user if it is ok.

Please ask if I am still being unclear. I wonder how we can talk about such different things...
(I am happy to meet in vidyo if my proposal still seams unclear.)

Comment 9

[Andy McKay]

I believe the reason the warning is there right now is because its the users browser and the add-on could negatively affect their browser. Giving the add-on developer the ability to make that choice for a user doesn't seem cool.

Assuming that the warning serves a purpose (I'm never really sure they do) it also means that the developer server could now be a target for malware. I could see a developer saying "yeah server x.y.z" is safe, then later on its taken over by a malicious user and is no longer safe.

Comment 10

[Tony Mechelynck [:tonymec]]

Markus: sorry, in comment #7 by "user" I meant "the user of Firefox". From Firefox's point of view, the developer of an extension is still a "user" (of the browser).

(In reply to Andy McKay [:andym] from comment #9)
> I believe the reason the warning is there right now is because its the users
> browser and the add-on could negatively affect their browser. Giving the
> add-on developer the ability to make that choice for a user doesn't seem
> cool. [...]

To me it does. For instance I personally trust mozdev and a couple other sources of extensions. I don't think that Firefox trusts them "out of the box". But what I would think "not cool" is Firefox highhandedly preventing me to suppress the are-you-sure dialog for mozdev.org, kairo.at, and those other add-on sources which I personally trust. Once upon a time I could add such permission (after due consideration) with no problem. Why should I now be robbed from that freedom? "Because Firefox thinks I'm no wiser than a kindergarten kiddie" is the only answer that comes to my mind.

Comment 11

[Tony Mechelynck [:tonymec]]

Oh, I think I misread comment #8 (and #9). Having an extension loaded from AMO change the add-on install permission to true for some third-party site without asking me or even telling me is something I would indeed not trust. As a browser user, I want to keep as much control as possible over which add-on sources I trust and which ones I don't.

Markus, with the mechanism you're proposing, someday I might install some ingenuous-looking extension which would, behind my back, turn on add-on install permission for spamrelay.voldemort.net and then proceed to install stuff from there. I would indeed (as Andy does) think this "not cool".

Comment 12

[Markus Jaritz [:designakt] (UX)]

(In reply to Tony Mechelynck [:tonymec] from comment #10)
> To me it does. For instance I personally trust mozdev and a couple other
> sources of extensions. I don't think that Firefox trusts them "out of the
> box". But what I would think "not cool" is Firefox highhandedly preventing
> me to suppress the are-you-sure dialog for mozdev.org, kairo.at, and those
> other add-on sources which I personally trust. Once upon a time I could add
> such permission (after due consideration) with no problem. Why should I now
> be robbed from that freedom? "Because Firefox thinks I'm no wiser than a
> kindergarten kiddie" is the only answer that comes to my mind.

Your point of a user being able to add trusted sources is an interesting idea, but not what this bug is about. Could you please file a separate bug for that discussion. Thanks.
(I imagine this might be a security risk as long as this list of trusted sources would be accessible by regular add-ons)

Comment 13

[Markus Jaritz [:designakt] (UX)]

(In reply to Andy McKay [:andym] from comment #9)
> I believe the reason the warning is there right now is because its the users
> browser and the add-on could negatively affect their browser. Giving the
> add-on developer the ability to make that choice for a user doesn't seem
> cool.

(In reply to Tony Mechelynck [:tonymec] from comment #11)
> Markus, with the mechanism you're proposing, someday I might install some
> ingenuous-looking extension which would, behind my back, turn on add-on
> install permission for spamrelay.voldemort.net and then proceed to install
> stuff from there. I would indeed (as Andy does) think this "not cool".

I still think the user should show intent to install the add-on before any add-on is installed. 
I do not think however that this should take more than one click in optimal cases.
(I fail to understand how this is "not cool", or are we still talking about different things?)

Those optimal cases being a user intentionally installing verified add-ons from verified sources. 

How we check if a user intentionally installs an add-on is up to us. Currently we go the easiest way and just make them click one more button if the click does not originate on our one and only verified source.

I think there must be better ways for us to determine if an add-on installation is intentional and verified if we want users to install add-ons. Especially the case of a developer having a page to promote their add-ons should be a priority to improve the experience on as this gives us more reach than forcing everyone to go through AMO.

How to secure those paths, to only let one specified add-on be installed from the devs site is not my expertise.


> Assuming that the warning serves a purpose (I'm never really sure they do)
> it also means that the developer server could now be a target for malware. I
> could see a developer saying "yeah server x.y.z" is safe, then later on its
> taken over by a malicious user and is no longer safe.

(Yes, warnings sometimes do not have a purpose. Especially not if they are shown to often.)
This server still would only be able to allow users intentional installation without warning of this one add-on that is a verified add-on (and maybe even hosted on AMO). What is unsafe about that?
The add-on is still verified and the user would still have to intentionally click "install".

How does Chrome do it? https://developer.chrome.com/webstore/inline_installation
Or is their solution not secure enough?


The aim of this proposal is not for the user to have less control over their browser, 
but only to make it easier for them to install an add-on in certain cases, 
and for us to gain more reach by developers helping to spread add-ons without the need to refer to AMO.
(Which might be attractive to devs as they probably like users to stay on their page throughout install.)

Comment 14

[Daniel Veditz [:dveditz]]

(In reply to Markus Jaritz [:maritz] (UX) from comment #13)
> How does Chrome do it?
> https://developer.chrome.com/webstore/inline_installation
> Or is their solution not secure enough?

Essentially it's an embedded chunk of their web store, and since the web store can install without extra prompts that's what happens. Their store has a way to associate (and verify!) domains with their extensions. Currently AMO does not, just emails, and we certainly don't want to use the email domain. Think of all the addons GMail could install? If AMO did have that kind of association we could work something out between the client and the site, as we did for the about:addons page (though of course not that exact mechanism).

I am NOT a fan of the popup "Firefox blocked this site from installing something" -- I think it should silently fail! In otherwords I'm a fan of the Chrome approach. Think of how annoyed people get when everytime they go to certain web sites in their mobile browser the side first prompts them to install the app instead. That's what can happen on the web. Note that Google will revoke their site install permission if they feel it's being abused. We can create such a mechanism but I fear we don't have the resources to police the sites for good behavior.

Comment 15

[Mike Kaply [:mkaply]]

If we believe that AMO addons are trusted from AMO, why wouldn't we believe they can be trusted when installed from someone else's site?

Can't we just check the origin of the addon, see that it's a signed reviewed AMO addon, and allow it to be installed from anywhere?

I think the reason Chrome doesn't allow this is because they have no true review process, so in theory you could deliberate malicious addons this way (assuming you could get an account with a stolen or prepaid credit card).

Comment 16

[Jon]

This is a major issue that I would love to see fixed. If it's a signed AMO addon, what is the downside of allowing it be installed outside the store? Our users of our addon are confused when they are on our site and get the warning "Firefox prevented this site from asking you to install software on your computer" If I send the users to the AMO store, I can't provide them a success and next steps instructions as easy. 

I think the software owner should be allowed to optimize the user flow experience without scaring their users by having the warning above show first.

Comment 17

[Andy McKay]

(In reply to Jon from comment #16)
> This is a major issue that I would love to see fixed. If it's a signed AMO
> addon, what is the downside of allowing it be installed outside the store?

A listed add-on on AMO has been reviewed by the review team. An unlisted but signed add-on has not been reviewed, its been automatically signed. The fact that the add-on has been signed isn't any guarantee of the quality or security of the add-on.

If it was signed AND reviewed, it seems more reasonable to suppress the warnings and allow install from 3rd party site.

Comment 18

[Jon]

(In reply to Andy McKay [:andym] from comment #17)
> (In reply to Jon from comment #16)
> > This is a major issue that I would love to see fixed. If it's a signed AMO
> > addon, what is the downside of allowing it be installed outside the store?
> 
> A listed add-on on AMO has been reviewed by the review team. An unlisted but
> signed add-on has not been reviewed, its been automatically signed. The fact
> that the add-on has been signed isn't any guarantee of the quality or
> security of the add-on.
> 
> If it was signed AND reviewed, it seems more reasonable to suppress the
> warnings and allow install from 3rd party site.

Yea, that would work great for us!

Comment 19

[Kev Needham [:kev]]

Taking this. Will have proposal for EoW. Good suggestions, and I see three parts:

- Follow-up on detail in https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/
- Differentiating installation of listed and unlisted reviews with third-party distribution
- Updates to add-on installation warnings to provide additional clarity and information to users where needed

Comment 20

[Mike Conca [:mconca]]

I'm taking the ni? from Kev and providing some additional comments. Since this bug was filed nearly three years ago, the landscape has changed a bit.  Chrome's inline installation mentioned in comment 4, comment 6 and comment 13 has been deprecated [1]. By Chrome 71 (end of 2018), inline installation of extensions will not be possible. Google's primary reason for this is user security, citing "confusing or deceptive uses of inline installation on websites".

I think we can take that as fairly strong, worldwide, market-based evidence that inline installation of extensions is not a good idea. I understand that Firefox extensions include code review, which Chrome extensions do not, but no review process is foolproof, and malicious extension authors will always try to find ways to exploit the system. I don't think Firefox should provide an additional feature, inline installation, that increases the attack surface of the browser, and that Chrome has already decided is getting so exploited that feature removal is the only solution.

[1] https://blog.chromium.org/2018/06/improving-extension-transparency-for.html

Comment 21

[Mike Conca [:mconca]]

I wouldn't mind seeing the wording of the initial install prompt improved and softened a bit, though. "Firefox prevented this site from asking you to install software on your computer" does feel too strong, especially in response to the user clicking an install button.

Comment 22

[Jim Mathies [:jimm]]

per comment 20.