1560059 - Nightly: installing addons from AMO give a trust warning

Status: VERIFIED FIXED

(WebExtensions :: General, defect, P3)

Description

[Caspy7]

Attachment: AMO Trust warning

On Windows Nightly: 69.0a1 (2019-06-18) (64-bit)

A few days ago I tried installing an addon from addons.mozilla.org and it wouldn't install. Don't recall full specifics but clicking install left the addon page and perhaps just tried to download it.

Today I tried again (using today's build) and got a coathanger warning me to check that I trust the site.
I've attached a screenshot of the warning.

It was this addon, but I tested one more than one and got the same result
https://addons.mozilla.org/en-US/firefox/addon/context-menu-search-webex/?src=search

Another user in #firefox on moznet (on Nightly, Linux 64 bit) reports they were able to reproduce this, while others were not.

I tested in a fresh profile and it worked as expected, no red minus sign with a warning. I expect this is historical/accumulated, perhaps related to the addonocolypse.

Comment 1

[Johann Hofmann [:johannh]]

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1298630#c16 this should only happen in "the old AMO frontend" (and that's expected), though I'm not sure how one would switch between that and the new one.

Comment 2

[Caspy7]

Attachment: Screenshot of my version of AMO

I am attaching a screenshot of what I'm seeing as the front page of AMO. I think it is the "new" frontend.

As I recall one used to be able switch with a link from the bottom of the page (this is gone). Also the history page of addons used to be the unthemed, old version of the page. It is now dark like the rest of the site for me (it used to be white and very bright that's how I remember).

Perhaps I now have a "bad" state or sorts.

Comment 3

[William Durand [:willdurand]]

FWIW, I had the same issue with FF Release on AMO new frontend (there is no old frontend anymore anyway). Profile wasn't new but not super old either (that's my main profile on my personal laptop).

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Caspy7]

Why was closed?
I specified in comment 0 that not everyone experienced it.
I still do.

Comment 6

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

I was able to reproduce this on release (68.0). When AMO has not been completely loaded (on slower connections?), clicking "Add to Firefox" triggered this me to experience what Caspy7 described in comment 0.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Caspy7]

(In reply to Andrew Truong [:feer56] [:andrewtruong] [:atruong] from comment #6)

I was able to reproduce this on release (68.0). When AMO has not been completely loaded (on slower connections?), clicking "Add to Firefox" triggered this me to experience what Caspy7 described in comment 0.

As a further data point, I tested again, waiting for it to load completely, then waiting several minutes more for argument's sake (I have a fast connection) then attempted the install and got the same result.

Comment 9

[jingyu9575]

I'm also seeing this warning. During tests I found it is related to the config privacy.resistFingerprinting.block_mozAddonManager.

Comment 10

[Luca Greco [:rpl] [:luca] [:lgreco]]

I took a quick look at this and it looks that the warning is being shown because the installation is being triggered when "addons.mozilla.org" is installing an extension without the mozAddonManager API object, which happen if:

1. The network is slow and addons.mozilla.org may have been rendered (or partially rendered) and if the user click the button to install the addon, while AMO webpage javascript is still being loaded, the installation will not be triggered using the mozAddonManager API (because the javascript that would use the mozAddonManager is not loaded yet), instead it will be triggered by a GET http request for the add-on xpi url

2. privacy.resistFingerprinting.block_mozAddonManager is set to true, as in that case the mozAddonManager API will never be available and all the addon installations will be triggered by a GET http request for the add-on xpi url

It is quite easy to trigger the scenario 2 consistently (you just need to set the about:config preference to true and reload addons.mozilla.org), the scenario 1 can be triggered consistently by:

• opening the devtools network panel
• disabling the cache
• enable network throtthling (e.g. regular 2G)
• while the page is still loading (e.g. while the localized strings are not yet been applied to the addons.mozilla.org page), press the "+ Add to Firefox" button

When an addon xpi is being installed from an HTTP request to the xpi url, the request goes through AddonManagerInternal.installAddonFromWebPage, which internally check if the "installingPrincipal" is already allowed (whitelisted) or not by calling isInstallAllowed. For an xpi, the isInstallAllowed is implemented in XPIInstall.jsm.

As a side note: in my opinion "scenario 2" behavior (privacy.resistFingerprinting.block_mozAddonManager set to true) may be already ok as it is, the "privacy.resistFingerprinting.block_mozAddonManager" is an hidden one and so setting it is a quite explicit user choice.

Comment 11

[Johann Hofmann [:johannh]]

Thanks for looking into it! So, should we just add the permission back? That seems like the most straightforward solution?

Comment 12

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Johann Hofmann [:johannh] from comment #11)

Thanks for looking into it! So, should we just add the permission back? That seems like the most straightforward solution?

yeah, at a first glance that seems a pretty straightforward solution that we may apply on the Firefox side.

An alternative approach for the "scenario 1" (slow network) that may be handled on the AMO side could be to "ensure that the xpi installation is not triggered" when the user clicks the "+ Add to Firefox" button while the page is not yet fully loaded, but it sounds like a crude workaround to me (and it can be annoying for a user on a slow network to not be able to install the extension until the page is fully loaded).

I'm adding a needinfo for :aswan :scolville to hear their opinions.

Comment 13

[Andrew Swan [:aswan]]

I don't have a strong opinion. Is there a strong reason not to just add the default permission back?

Comment 14

[Caspy7]

I'm...not sure I follow everything, but privacy.resistFingerprinting.block_mozAddonManager is set to true for me though I did not explicitly set it.

Comment 15

[[e-mail]]

(In reply to Luca Greco [:rpl] [:luca] from comment #12)

(In reply to Johann Hofmann [:johannh] from comment #11)

Thanks for looking into it! So, should we just add the permission back? That seems like the most straightforward solution?

yeah, at a first glance that seems a pretty straightforward solution that we may apply on the Firefox side.

An alternative approach for the "scenario 1" (slow network) that may be handled on the AMO side could be to "ensure that the xpi installation is not triggered" when the user clicks the "+ Add to Firefox" button while the page is not yet fully loaded, but it sounds like a crude workaround to me (and it can be annoying for a user on a slow network to not be able to install the extension until the page is fully loaded).

I'm adding a needinfo for :aswan :scolville to hear their opinions.

If there's not a security rationale for removing the permission in the first place then adding it back seems reasonable. But I'd would think there was probably a reason for it being removed - who would know the answer to that?

Comment 16

[Jim Mathies [:jimm]]

The webext team discussed this and decided not to bring back the permission, since it would turn the warning off for any extension served up via amo from external sites.

We think the best way might to mitigate this is to make sure the button isn't enabled until the page is loaded.

Comment 17

[[e-mail]]

(In reply to Jim Mathies [:jimm] from comment #16)

The webext team discussed this and decided not to bring back the permission, since it would turn the warning off for any extension served up via amo from external sites.

Using ESR 60.8 (before the permission removal which landed in 67) The doorhanger with a permissions prompt ("Firefox prevented this site from asking you to install software on your computer") is shown when linking / framing to an XPI from a site that isn't AMO. So that case looks to be protected.

However, (still using ESR 60.8) if you open an AMO details page (with JS off) and click a direct link to an XPI via the install button, the add-on is installed with only the regular install doorhangers.

My understanding of bug 1298630 was that InstallTrigger was being removed and the permission was connected to that but if that has now impacted directly linking installing xpis from AMO that's a regression. Installtrigger was used on the old site and that is no longer used, but we'd still like link fallbacks to work.

I'd like to understand if there would be other additional security concerns from re-adding the permission removed in bug 1530371 - :johannh what do you think?

We think the best way might to mitigate this is to make sure the button isn't enabled until the page is loaded.

Let's see if adding back the permission would work without comprising security first.

Comment 18

[Andrew Swan [:aswan]]

Comment 16 appears to be incorrect. The permission that was removed in bug 1530371 lets AMO initiate installs with InstallTrigger or links to xpi files. It does not (and did not) permit other sites to initiate installs even if the target of the install is on AMO.

Comment 19

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Andrew Swan [:aswan] from comment #18)

Comment 16 appears to be incorrect. The permission that was removed in bug 1530371 lets AMO initiate installs with InstallTrigger or links to xpi files. It does not (and did not) permit other sites to initiate installs even if the target of the install is on AMO.

Yeah, that's my fault:

in Comment 10 I mentioned the installingPrincipal, which it actually means the "principal of the document that is triggering the installation", and so it should be AMO only if AMO is the triggering the installation and not a third party website just because the xpi url is an AMO url.

But we missed that part while we discussed about it today, and so "adding back the permission" looked more "concerning" than how much it would actually be (at least while we are also ensuring that no third parties, like other installed extension, can trigger it on webpage with the AMO principal).

Comment 20

[Johann Hofmann [:johannh]]

I'm not aware of any larger security concerns around adding it back either. We would be re-introducing bug 1298630 (which isn't a major issue) and I guess we would have to maintain two different "fast-track" add-on installation paths, but other than that there's no big secret reason we removed it or anything.

But thanks for checking :)

Comment 21

[[e-mail]]

:jimm would it be possible to get adding the permission back prioritized assuming there aren't other concerns?

Comment 23

[Tomislav Jovanovic :zombie]

Attachment: Bug 1530371 - Restore XPInstall permission for addons.mozilla.org

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fc8421b87060
Bug 1530371 - Restore XPInstall permission for addons.mozilla.org r=johannh

Comment 25

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/fc8421b87060

Comment 26

[Alex Cornestean]

Hello,

Verified the fix using the latest Nightly (71.0a1/20191007215350) under Windows 10 Pro 64-bit and MacOS High Sierra 10.13.6, while also performing additional tests on Nightly 69.0a1 buildID 20190618041042 as a basis for comparison.

On the latest version of Nightly, tests performed as per the steps provided in Comment 10 and normal AMO installation proved successful, the trust warning not being displayed, confirming the fix. On the older Nightly build, the issue is reproducible with consistency under those steps.