1411999 - Document which permissions trigger user prompts in the different browsers

Status: RESOLVED WONTFIX

(Developer Documentation Graveyard :: Add-ons, defect, P3)

Description

[Alexei]

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

Steps to reproduce:

Added "unlimitedStorage" permission to WebExtensions add-on (Privacy Badger), pushed update to users.

unlimitedStorage (https://developer.chrome.com/extensions/declare_permissions#unlimitedStorage) is documented (https://developer.chrome.com/apps/permission_warnings#nowarning) to not produce a warning in Chrome. As WebExtensions are based on Chrome, I expected permission warning logic to carry over.


Actual results:

Users are being shown a scary, unhelpful confirmation dialog: https://github.com/EFForg/privacybadger/issues/1745#issuecomment-339694141.


Expected results:

Users should not be shown a confirmation dialog.

Comment 1

[Andy McKay]

Its a change in how the add-on behaves and how it stores data on the users device. We think that its pretty important to let users know that the add-on is choosing to store large amounts of data, it is the users device after all.

Chrome doesn't have the same warning but we've chosen to differ in areas that we think are important.

Comment 2

[Alexei]

Is this incompatibility documented somewhere?

Comment 3

[Alexei]

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Chrome_incompatibilities is good, but I don't see this particular incompatibility noted there. Undocumented WebExtensions implementation differences are particularly frustrating for Firefox platform developers.

Comment 4

[Andrew Swan [:aswan]]

Will, any thoughts about comments 2 and 3?

Comment 5

[Will Bamberg [:wbamberg]]

What we say about permissions prompts is:

"If you request permissions using this key [permissions], then the browser may inform the user at install time that the extension is requesting certain privileges, and ask them to confirm that they are happy to grant these privileges. The browser may also allow the user to inspect an extension's privileges after installation."

(https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/permissions).

We don't in general document the way every browser implements permissions prompts. This seems like something that's very likely to diverge from one browser to another. Also, the standard as far as I can tell doesn't talk about this, beyond "Upon installation of a browser extension, a browser MAY notify the user of potential privacy-related capabilities of the extension" (https://browserext.github.io/browserext/#getbrowserextpermissionprompt) - and I doubt very much that the standard will ever say much more than this.

So I'm not exactly against this, but it's not a high priority thing for me to be working on.

I've reopened it and moved it to dev-docs component so it can get triaged tomorrow.

Comment 6

[Alexei]

It's not at all obvious that permission warnings are "very likely to diverge from one browser to another". The developer expectation is that WebExtensions work the way they work in Chrome, unless specified on the incompatibilities page. Any difference in implementation is a rude surprise.

Comment 7

[Alexei]

Could somebody help us figure out how to test permission warnings in Firefox? I previously asked for help in https://bugzilla.mozilla.org/show_bug.cgi?id=1441693#c6 but haven't gotten any replies.

We might be blocked from switching to <all_urls> (https://github.com/EFForg/privacybadger/issues/1010#issuecomment-379091361) and handling enabling "match_about_blank" for our content scripts (https://github.com/EFForg/privacybadger/pull/2205), in which case we need to get these permission bugs fixed in Firefox (Firefox should not needlessly hassle/alarm add-on users!), but we don't even know if we have a problem (probably yes for <all_urls> and no for "match_about_blank"?) since it's not clear how test permissions properly.

Comment 8

[Will Bamberg [:wbamberg]]

Alexei, I'm sorry to not have got to this.
Caitlin, is this a thing we could ask Richard to do?

Comment 9

[Alexei]

No problem! It would really help in the short term to know if setting "match_about_blank" on a content script declaration will trigger any new warnings: https://github.com/EFForg/privacybadger/pull/2205/files#diff-051a8a7bcae8db1e4cee8eb09b52e619R106

Comment 10

[Will Bamberg [:wbamberg]]

For a specific question like this I would suggest asking on the mailing list (https://mail.mozilla.org/listinfo/dev-addons).

Comment 11

[Caitlin Neiman [:caitmuenster]]

Sorry for the late response here! Will, I can ask Richard if we can add some notes to our documentation about permissions warnings differing between browsers. It's unlikely that we'll be able to go into full details about the other browser permission warnings, but we can see if we can link to any relevant documentation the other browsers provide so that people can find more information.

Comment 12

[Will Bamberg [:wbamberg]]

I was thinking we could have something quite detailed in the Firefoxy parts of the WebExtension docs, and something quick in the general docs on permissions (e.g. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions) saying that the situation may differ from one browser to another and pointing at any browser-specific resources.

Comment 13

[Alexei]

Chrome used to document testing extension permission warnings on extension upgrade here: https://web.archive.org/web/20180114080742/https://developer.chrome.com/apps/permission_warnings#test (I don't know why the instructions are gone from the latest version of the page ... Will probably open a crbug.)

Here is Chrome's current documentation of which permissions result in warnings:
https://developer.chrome.com/apps/permission_warnings#permissions_with_warnings

Comment 14

[Alexei]

Will, I last asked for help with testing extension permission warnings on upgrade in Firefox seven months ago in issue 1441693. We have since had another (still ongoing) incident with another EFF extension, HTTPS Everywhere. A third of HTTPS Everywhere's users are no longer upgrading to the latest version because of a trivial permissions change: https://github.com/EFForg/https-everywhere/issues/16377 (HTTPS Everywhere already had *://*/* and asked for ftp://*/*)

Could you please help us figure out how to test permission warnings on extension upgrade here or over at issue 1441693?

Comment 15

[Alexei]

Bug 1504018 is a related issue.

Comment 16

[Will Bamberg [:wbamberg]]

> Could you please help us figure out how to test permission warnings on extension upgrade here or over at issue 1441693?

Alexei: I'm not working on WebExtensions any more, but:

* if there are specifics that are missing or wrong in the docs, it's best to file a docs bug (like this one, and I hope that this will get some action)

* if there are ways the permissions notifications work in Firefox that you think are inadequate, it's best to file an engineering bug (like bug 1441693, and as Jorge suggested in https://github.com/EFForg/https-everywhere/issues/16377)

* if you have some specific support request (like, "my extension currently has permissions XYZ, what will happen if an upgrade asks for WYZ instead") - which is what "figure out how to test permission warnings" sounds like - then I'd say that it's best to start by asking in the dev-addons list.

Comment 17

[Alexei]

OK, thank you. I asked on the list and was told to essentially set up a self-hosted version of the extension. I got that to work, but I have some doubts still because I haven't been able to reproduce the permissions dialog in one of my expected permissions dialog upgrade scenarios: https://bugzilla.mozilla.org/show_bug.cgi?id=1504018#c3

Comment 18

[Alexei]

Here is an overview of my permissions on extension update test setup:

0. Configure Firefox to accept unsigned extensions.

1. Set an extension ID (applications.gecko.id) and update URL (applications.gecko.update_url) in your extension manifest.

- The update URL has to be HTTPS with a certificate Firefox will auto-accept. This is annoying because you can't simply run a simple Python localhost server or use a self-signed certificate.

- The update URL points to where you will host your updates manifest (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Updates).

2. Build your extension (cd src; zip -qr ../build.xpi *), get a SHA256 hash of the XPI (sha256sum ../build.xpi).

3. Make whatever manifest changes you'd like to test, update the extension version, and rebuild the extension into a second XPI; get the hash of that.

4. Create the updates manifest file. Make sure to use the same extension ID you set in your extension manifest. Add two entries pointing to HTTPS URLs of where you will host the XPI files. Make sure the versions and the SHA256 hashes are set correctly.

5. Upload the updates manifest and the two XPIs to your HTTPS server. Copy and paste the link to the first XPI to install it. Visit "about:addons", click on the gear button, and click "Check for Updates" to get the update and see if you get a new permission warnings prompt because of your manifest changes in step 3.

Comment 19

[Rob Wu [:robwu]]

(In reply to Alexei from comment #7)
> and handling enabling "match_about_blank" for our content scripts
> (https://github.com/EFForg/privacybadger/pull/2205), in which case we need
> to get these permission bugs fixed in Firefox (Firefox should not needlessly
> hassle/alarm add-on users!), but we don't even know if we have a problem
> (probably yes for <all_urls> and no for "match_about_blank"?) since it's not
> clear how test permissions properly.

When bug 1504018 is fixed, there won't be a new warning when you switch between host permissions that result in the "Access your data on all websites" warning. So you will be able to switch from <all_urls> to *://*/* to https://*/ and back without new warnings.

The match_about_blank property does not cause new warnings. Of content scripts, only the "matches" field results in potential permission warnings.

Comment 20

[Alexei]

Thank you Rob!

Will this fix be backported to ESR 60? I think it should be since we want as few Firefox users using the old, buggy permissions warnings logic as possible before we can release any extension updates that go from "http:///" and "https:///" to "<all_urls>".

Comment 21

[Rob Wu [:robwu]]

Even if the patch for bug 1504018 was backported, then users who don't update immediately will still be affected by the bug (and see warnings as soon as you release an update).
But you can already publish releases that reach everyone (even those on older versions) by building two versions of your add-on, without new permission warnings, with the following steps:

1. Publish version with minimal permissions.
2. Publish (higher) version with desired permissions, and set applications.gecko.strict_min_version to 66.0a1 (since bug 1504018 was fixed in 66).

When Firefox 65 or Firefox ESR 60.5 queries for add-on updates, they will be served the first version.
When Firefox 66 or later queries for add-on updates, they will be served the second version.

Example manifests:

manifest.json (publish first):

{ ...
  "version": "2019.01.25",
  "permissions": [ "https://*/*", "http://*/*" ],
  ... }

manifest.json (publish second):

{ ...
  "version": "2019.01.25.1",
  "permissions": [ "https://*/*", "http://*/*", "wss://*/*", "ws://*/*" ],
  "applications": {
    "gecko": {
      "strict_min_version": "66.0a1"
    }
  },
  ... }

Above, I increased the version by appending a .1. If the version numbers are important to you, then you could choose a different version format, such as "2019.01.25+" or "2019.01.25pre" - see https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/version

Does this work for you?

Comment 22

[Alexei]

Ah, thanks for pointing out this possibility. This would work, but I would really like to avoid the complication of having multiple supported versions in production.

Now that I look at our stats dashboard by browser (https://addons.mozilla.org/en-US/firefox/addon/privacy-badger17/statistics/usage/applications/?last=30), we might be OK without ESR having the fix as ESR users make up a small percentage of user base. I think our release strategy (for switching to "<all_urls>") will be to wait until 95%+ of our users are on Firefox 66+.

Don't get me wrong, I would still like this fix to be backported to ESR.

Comment 23

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.

Comment 24

[Alexei]

Looks like unlimitedStorage will no longer prompt users as of Firefox 77: bug 1630413

Comment 25

[Caitlin Neiman [:caitmuenster]]

Thanks Alexi! We updated our documentation for requesting the right permissions on Firefox Extension Workshop: https://extensionworkshop.com/documentation/develop/request-the-right-permissions/#request-permissions-at-runtime