Closed Bug 1504018 Opened 6 years ago Closed 5 years ago

Adding ftp ws/wss permissions should not trigger extension permission warnings on extension upgrade

Categories

(WebExtensions :: General, enhancement, P2)

63 Branch
enhancement

Tracking

(firefox66 verified)

VERIFIED FIXED
mozilla66
Tracking Status
firefox66 --- verified

People

(Reporter: alexeiatyahoodotcom+mzllbgzll, Assigned: robwu)

References

Details

(Whiteboard: [permission])

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Steps to reproduce:

We have recently had another (still ongoing) incident with HTTPS Everywhere. A third of HTTPS Everywhere's users are no longer upgrading to the latest version because of a trivial permissions change: HTTPS Everywhere already had *://*/* and asked for ftp://*/*. You can see some of the fallout in https://github.com/EFForg/https-everywhere/issues/16377 and more in HTTPS Everywhere's addons.mozilla.org reviews.

A similar issue is blocking Privacy Badger from properly filtering web socket requests (https://github.com/EFForg/privacybadger/issues/1010). Privacy Badger currently asks for http/https permissions, but needs ws/wss (or <all_urls>). However triggering a permissions dialog on upgrade is unacceptable as Privacy Badger will effectively lose a third of its userbase.


Actual results:

Users saw "Access your data on all websites" (https://user-images.githubusercontent.com/156799/44497426-0822b980-a62e-11e8-8db8-1bb942de3f11.png) and freaked out.


Expected results:

Adding ftp/ws/wss permissions (or replacing http/https with <all_urls>) should not trigger any new permission warnings on upgrade.
This issue is related to bug 1411999 and bug 1441693.
There is also the question of whether setting "match_about_blank" on a content script declaration will trigger any new warnings (https://bugzilla.mozilla.org/show_bug.cgi?id=1411999#c9). It should not!
Priority: -- → P3
Severity: normal → enhancement
Whiteboard: [permission]
I'm having trouble reproducing this permissions bug in testing.

I set up a self-hosted, unsigned copy of an extension that asks for the "*://*/*" permission in the extension manifest. I then configured Firefox to accept unsigned extensions, installed the self-hosted extension, uploaded an updated version that adds the "ftp://*/*" permission, updated the updates manifest to point to the new version, and forced an update in about:addons. The extension updated, but no permissions dialog appeared.

I was able to reproduce getting the permissions dialog when I added "unlimitedStorage", however.
See Also: → 1411999
We’re having similar issues in the latest version of Ghostery (v8.2.5) in which we added manifest permissions for `ws://` and `wss://`. The upgrade causes Firefox to throw a permission dialog, which is misleading and redundant since users have already allowed `http://` and `https://` host permissions on installation.  As Alexei mentioned, this is needlessly scaring users and forcing them to re-accept a permission that they’ve already accepted. 

You can see the pushback from Ghostery users on our review board:

https://user-images.githubusercontent.com/4699516/49228878-54626000-f3ba-11e8-8c89-7fa233300492.png

Additionally, some users aren’t getting the permission prompt in the url bar, but instead it’s buried in the toolbar hamburger menu. If they don’t see it, it goes away when you close Firefox.

https://user-images.githubusercontent.com/4699516/49228286-013bdd80-f3b9-11e8-8863-c939acdbdfca.png

For the time being, we are forced to remove WebSocket filter support from the Firefox version of Ghostery. The upgrade conversion rate has been very low. 

In cases where users have already consented to allow host permissions for an extension, could a fix be implemented so that these users are not re-prompted when a host permission is changed?
I'd like to point out that none of these permissions warnings gotchas are a problem in Chrome.
Assignee: nobody → rob
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: P3 → P2
STR for QA:

1. Install https://addons.mozilla.org/en-US/firefox/addon/https-everywhere/versions/2018.6.21
2. Visit about:addons and click on Extensions.
3. Click on the gears icon and "Check for Updates".
4. Click on "Install updates" at the "Available updates" tab.

Expected:
- Updated without additional prompt

Actual:
- New "Access your data on all websites" permission warning as reported in comment 0.
To be clear, this isn't just about "ftp", but ws/wss (Privacy Badger needs to add them but can't, not without losing a large percentage of its user base which is unacceptable: https://github.com/EFForg/privacybadger/issues/1010#issuecomment-442260262) and really any other what should be trivial upgrade. I suggest taking a hard look at all the differences in permissions warning logic Firefox has with Chrome, removing as many as possible and documenting the rest (bug 1411999). There should also be a simple way of testing what happens with permissions warnings on extension update (bug 1505510).

Thank you for working on this!
Depends on D5527

Depends on D14962
If an extension with the "mozillaAddons" permission is updated, the
permission diffing logic should support restricted schemes.
Otherwise the MatchPattern will throw and prevent the update from being
installed.

`Extension.comparePermissions` is called with the result of
`.userPermissions`, which in turn is equivalent to the result of the
`manifestPermissions` getter. This already filters out restricted
schemes if needed. Therefore we can unconditionally use
`restrictSchemes:false` in `comparePermissions`.

Depends on D14963
Attachment #9032400 - Attachment description: Bug 1504018 - Unit tests for permission warnings on update → Bug 1504018 - Skip host permissions for which a warning has been shown before
Attachment #9032401 - Attachment description: Bug 1504018 - Add restrictSchemes:false to comparePermissions → Bug 1504018 - Support unrestricted schemes in permission warnings
Attachment #9032399 - Attachment is obsolete: true
Blocks: 1515697
Pushed by rob@robwu.nl:
https://hg.mozilla.org/integration/autoland/rev/dc4bd4ee4c22
Skip host permissions for which a warning has been shown before r=aswan
https://hg.mozilla.org/integration/autoland/rev/8583d9d48387
Support unrestricted schemes in permission warnings r=aswan
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Depends on: 1519626

Verified using multiple profiles and addon updates including 'HTTPS everywhere' on Nightly 66.0a1 (20190117095319) running on Windows 10 x64 bit following the steps described on comment #7, upon update no prompts were displayed, also verified that the issue is indeed reproducible on earlier versions (64.0 ).

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: