1502987 - Should be able to request specific host permission when not already granted

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement, P3)

Description

[Martin Giger [:freaktechnik]]

Specific host permissions are more powerful than wildcard host permissions in Firefox. They allow bypassing tracking protection.

When an extension requests a specific host permission but already has <all_urls> or similar the permission is not requested, since the permission manager assumes that it is already granted and fully included in <all_urls>.

However if a permission for a specific host is not already granted, the request should always be shown, so extensions can disable tracking protection for specific hosts by user interaction, even when they want to disable CORS everywhere, for example.

Comment 2

[Shane Caraveo (:mixedpuppy)]

There was probably a reason for the ni? but I've no idea what.

Comment 3

[Tom S [:evilpie]]

We are running into this with Livemarks, a recommended extension. We already request permission: ["<all_urls>"], because we want to be able to handle opening RSS URLs like https://magic.wizards.com/en/rss/rss.xml by showing a preview. For some RSS feeds however this doesn't work like Gmail or Reddit.
We get an error message like:

Request to access cookie or storage on “https://mail.google.com/mail/u/0/feed/atom” was blocked because it came from a tracker and content blocking is enabled.

To give our users a chance to add these RSS feeds my idea was to extend our code for manually adding RSS feed URLs by first requesting the appropriate permission like browser.permissions.request({origins: ["https://mail.google.com/"]}). Now we come back to this bug: Firefox always resolves this request to true and doesn't ask the user for permission and of course doesn't add the more specific host permissions that we need to bypass the cookie/storage blocking.

Comment 4

[Shane Caraveo (:mixedpuppy)]

Attachment: Bug 1502987 support explicit optional origins when granted all_urls in manifest

Comment 5

[Rob Wu [:robwu]]

With the tracking protection use case addressed, do we want to close this one?

Or do we still want to keep it open somehow, to have the possibility of the following:

• request <all_urls>
• request example.com
• revoke <all_urls>
• still have the ability to access example.com

Comment 6

[Rob Wu [:robwu]]

^ see comment 5

Do you want to keep this bug and the patch open or can it be closed?

Comment 7

[Shane Caraveo (:mixedpuppy)]

Assuming that bug 1629436 has made this more generic and we do not need host-specific permissions to deal with TP (and other stuff), I'd say lets close this for now unless/until we have a solid reason to do it.

Comment 8

[Rob Wu [:robwu]]

Bug 1629436 solved this for extension pages, but (intentionally) not for content scripts.

I agree with closing this until there is a solid reason.