Users worried about "Block content on any page" permission

Add-ons Add-on Support
1

Users are starting to show concern for a new permission that has appeared: “Block content on any page”: https://github.com/odebroqueville/contextSearch/issues/201

I thought that the problem might be coming from using the “declarativeNetRequest” permission, but removing that permission doesn’t solve the problem.

Context Search doesn’t try blocking any content, so I don’t understand where this is coming from?!?

2

I’m pretty sure it’s the declarativeNetRequest, because for example this addon has only that and storage permissions and it shows that permission:
AdBlocker for YouTube™ – Get this Extension for 🦊 Firefox (en-US)

Note that once the addon has the permission approved, it will stay visible in the “about:addons” permissions page, even when the addon update removes it from the manifest file.
I had a similar issue recently: "not supported search provider" in console.error · Issue #24 · fastaddons/SearchResultPreviews · GitHub

Also, someone should update this page, because currently it doesn’t list the declarativeNetRequest at all permission:

(anyone knows where to report bugs for extensionworkshop?)
UPDATE: reported bug here:

2 Likes
3

Hi Juraj, nice to hear from you. I’m actually using the declarativeNetRequest to request change the user agent (to a mobile version) requesting the web page when rendering the page in the sidebar. I’m not blocking any content, so I find that wording misleading and I perfectly understand that users could be scared away! I understand Mozilla’s security concerns, but this could typically hurt extension adoption rate, which in turn will hurt Firefox adoption rate. I also just noticed another permission: “Access your data for all websites”. I don’t know where this one is coming from, but it also makes users think that we’re not respecting user data privacy. Not a great time to develop extensions for Firefox!

4

I have a feeling you should be using declarativeNetRequestWithHostAccess instead of declarativeNetRequest. They are the same, but one is alerted to users and the other one is not.

And since you already have "<all_urls>" permission, you have access to all hosts, so declarativeNetRequestWithHostAccess will work as expected.

Note that “Access your data for all websites” warning is caused by the "<all_urls>" permission, but I’m not sure you can avoid that.

1 Like
5

Dear Juraj, Thank you so much for your kind help and expertise. I’ve encountered some strange behaviours lately in firefox. I had users complaining that whenever they typed youtube.com they were being redirected to m.youtube.com, which was a bug because one of my header rules had a urlFilter set to “https://youtube.com/*” and the rule would change the user agent to receive the mobile version of a website to display it in the sidebar. I fixed this by changing the urlFilter to “https://youtube.com/*#_sidebar”. I tested yesterday in about:debugging and it was working fine, so I uploaded the fix to AMO. The funny thing is that the AMO version didn’t work! I tried again today and now it’s working! :face_with_spiral_eyes: :upside_down_face:

I’m not sure if it’s due to a firefox update, but it’s the only explanation I have!

On a side note, I’ve finally succeeded in getting a cross-browser version of Context Search based on manifest v3 working. It was a lot of work and I had to use sendResponse everywhere instead of returning functions because that wasn’t supported by Chromium mv3. I still have to look into adding payments as it’s been a lot of work on my end to get things working. If you have a little spare time, I’d be thrilled to have your feedback. I hope your extensions are doing well.

1 Like
6

By itself, the declarativeNetRquest permission grants extensions limited access to modify network requests. Most notably, it gives extensions the power to block a network request based on criteria such as the URL being requested. When an extension requests both declarativeNetRequest and host permission, the extension is able to declaratively modify other, more sensitive properties of the request or response, such as the User-Agent head. As @juraj.masiar suggested, your use case may be better served by declarativeNetRequestWithHostAccess, as that permission only gives an extension access to Declarative Net Request capabilities on hosts that the extension that the extension has host permission access to.

EDIT: Moved my comments about “Access your data for all websites” to @odebroqueville2’s other post: How to avoid "Access your data for all websites" permission

1 Like
7

I made the change and am now using declarativeNetRequestWithHostAccess. On macOS Sequoia running Firefox 136.0.1, typing youtube.com no longer redirects to m.youtube.com. However, for some unknown reason, a Ubuntu (20 Focal) user running Firefox v136.0.1 (64bits) is still being redirected and I don’t understand why! This is the rule that I’m using:

    {
        // Rule for YouTube
        id: 2,
        priority: 2,
        action: {
            type: 'modifyHeaders',
            requestHeaders: [
                {
                    header: 'User-Agent',
                    operation: 'set',
                    value: USER_AGENT_FOR_GOOGLE
                }
            ]
        },
        condition: {
            urlFilter: '*youtube.com/*#_sidebar',
            resourceTypes: ['main_frame', 'sub_frame']
        }
    }
8

Nothing specific is jumping out at me. My main question would be whether the Ubuntu user is on the correct version and if the DNR rule was updated as expected. You might want to consider adding a debug.html page to your extension that collects information that users can copy-paste to you to help investigate.

You can retrieve the current extension version by calling browser.runtime.getManifest().version and get the current set of DNR rules by calling await browser.declarativeNetRequest.getDynamicRules().

Also, one of my colleagues pointed out that urlFilter: "https://xyz" will match requests for https://xyz as well as requests where https://xyz is a substring in the URL, like https://abc/...path?url=https://xyz. If you only want to match pages on youtube.com or it’s subdomains, you might want to change the urlFilter to '||youtube.com/*#_sidebar'.

1 Like
9

Thank you for your speedy response, Simeon. Your level of knowledge is always impressive! i had suggested to the user who experienced the problem to see if it was also occurring in private mode. Since then, he told me that the problem was fixed. I’m not certain what happened, but maybe the cache was cleared (not sure if the cache would be involved in memorizing redirects).

A debug.html page sounds like a good idea and I’ll definitely adopt your colleague’s subtle suggestion for the urlFilter. I wonder what those pipes (||) stand for?

Thanks again for being such a great help.

10
  • || : Domain name anchor: If used at the beginning of the pattern, specifies the start of a (sub-)domain of the URL.

Source: declarativeNetRequest.RuleCondition

In other words, if the URL filter starts with ||, the pattern will match the domain specified in the URL filter or any of it’s subdomains. "||example.com" matches both https://example.com and http://sub.domain.example.com, but will not match http://example.com.dotproto.com or https://mozilla.org/firefox?domain=example.com.

1 Like