If it would be possible to pregame a list of trusted sites, it would help a lot in managed deployments.

I am looking at "Configure ExtensionSettings policy", and it does appear you can exclude a list of sites with which extensions are excluded from interacting with, runtime_blocked_hosts:

Prevent extensions from interacting with or modifying websites that you specify. Modifications include blocking javascript injection, cookie access, and web-request modifications.

So it looks like what you want can already be accomplished.

I confirm this works. I followed the instruction for linux, and the following JSON file put in /etc/chromium/policies/managed/ caused uBOL to no longer filter anything on arstechnica.com:

{
  "ExtensionSettings": {
    "ddkjiahejlhfcafbddmgiahcphecmpfh": {
      "runtime_blocked_hosts": [
        "*://*.arstechnica.com"
      ]
    }
  }
}

The only quirk is that the extension shows as being active and blocking, but in reality it ends up not affecting the web pages on arstechnica.com.

Disregard my previous comment, I got confused about what was the topic here.

For your interest, there is an admin setting to disable uBOL for specific hostnames, implemented two months ago, see gorhill/uBlock@d19e62a.

Using this uBOL-specific policy will cause the blocking mode to be properly reflected in the popup panel, as opposed to using the browser-enforced list of hostnames on which the extension is bypassed.

Usage (since I use linux, the content below is in a json file in /etc/chromium/policies/managed/):

{
  "3rdparty": {
    "extensions": {
      "ddkjiahejlhfcafbddmgiahcphecmpfh": {
        "noFiltering": [
            "d3ward.github.io"
        ],
      }
    }
  }
}

Thanks, saw the managed_Storage.json file, now things are starting the click :) Will peak at that method. Though I do like your idea trying to leverage the existing extension management features, so most likely will look at both.

Using the extension runtime_blocked method, did seem to prevent the badge count for some sites but not others like cnn.com, msn.com. Though still testing to confirm if visual or other reasons.

On Edge browser (115.0.1901.203) using policy via windows registry (same setting).

https://learn.microsoft.com/en-us/deployedge/microsoft-edge-manage-extensions-ref-guide

not others like cnn.com, msn.com

It could be that these sites embed iframe with different origins and if these origins are not excluded by the policy, filtering will occur -- just speculating. If using uBO's own managed settings, the exclusion will (should) also apply to embedded different origins.

Yeah you are most likely right about the iframe (not that I know much about these things:). Digging in dev mode found iframe references to other origins/URLs, and adding to the native extensionsettings controls were successful.

As for your change/linux config json.

Tried to translate the example to windows, but haven't had much luck.

Is there specific code in normal uBO for edge+windows to get JSON config from registry? Was able to get that to work in uBO (for sanity), but have failed so far to translate your json example for uBOL (ddkjiahejlhfcafbddmgiahcphecmpfh).

For reference (lol): HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\3rdparty\Extensions\odfafepnkmbhccpbejgmiehpchacaeak\policy
adminSettings = {JSON Config here}

From what I can tell Edge policy doesn't natively support the "3rdparty" format/path, so assuming this was coded in uBO?

About the closest I have come to apply a JSON for Windows/Edge policy is the intial_preferences file (looks to be sort of like the master_preferences of chromium). Also found references to MSEDGE-GLOBAL.json for linux, so plugging away hoping something will work.

MSEDGE-GLOBAL.json - https://techcommunity.microsoft.com/t5/discussions/global-profile-configuration-on-linux/m-p/2365884

intial_preferences - https://learn.microsoft.com/en-us/deployedge/initial-preferences-support-on-microsoft-edge-browser

I used the documentation to create uBOL policies on my side (linux) at https://www.chromium.org/administrators/configuring-policy-for-extensions/. They have instructions for other OSes -- I don't use Windows so I wouldn't know how to proceed.

Note that you probably have to restart the extension twice for the policy to take effect -- uBOL reads the policy in a lazy way to avoid having to read managed storage every time the worker starts (which is very often). When you create a new policy, uBOL will read once per cold start (when you disable/enable the extension or restart the browser), then save the result in its local storage for next cold start. The next cold start it will then use the policy as seen in its local storage.

https://github.com/uBlockOrigin/uBlock-issues/wiki/Deploying-uBlock-Origin

See #35 (reply in thread) above.

Hi there, perhaps I am misunderstanding, I checked the manifest file and only see options for noFiltering and disableFirstRunPage. What we are trying to do is set the default filtering mode for all sites.

set the default filtering mode for all sites

What default filtering mode do you want? My understanding is that it's not possible for higher filtering mode than basic one require users to explicitly grant permissions to "Allow this extension to read and change all your data on websites you visit", there has to be a user gesture, i.e. clicking "Agree" to the browser prompt. Hence why the only possible filtering mode available through policy is "no filtering".

If you think there is a way through policies to bypass this prompt, I would like to know about it.

the little number that shows "blocked elements" still shows even on sites added to the allow list

How did you add to the allow list?

I'm using the 'adminSettings' registry key under the extension ID (same as the previous uBO version) to pull in a custom allow list via JSON. I verified it's working as intended by comparing it against our uBO install (ie: testing on a website we have allowed and seeing which elements are not blocked, then testing with uBOL with the same list applying to see if those same elements are showing).

adminSettings is not a property understood by uBOL, the extension is too different to try to mimic how uBO works admin setting-wise.

The results might look the same because there is no cosmetic filtering being applied by default since it requires explicitly giving permissions to a site for cosmetic filtering to apply. The block count number on the badge shows that the site is not being allowlisted.

The proper way to allowlist through a policy in uBOL is detailed in the thread above, see #35 (reply in thread) -- it's through the noFiltering admin setting. This will exclude listed hostnames from being subjected to filtering, i.e. the same effect as setting a site's filtering mode to "no filtering" in the popup panel.

the little number that shows "blocked elements" still shows even on sites added to the allow list

How did you add to the allow list?

adminSettings is not a property understood by uBOL, the extension is too different to try to mimic how uBO works admin setting-wise.

The results might look the same because there is no cosmetic filtering being applied by default since it requires explicitly giving permissions to a site for cosmetic filtering to apply. The block count number on the badge shows that the site is not being allowlisted.

The proper way to allowlist through a policy in uBOL is detailed in the thread above, see #35 (reply in thread) -- it's through the noFiltering admin setting. This will exclude listed hostnames from being subjected to filtering, i.e. the same effect as setting a site's filtering mode to "no filtering" in the popup panel.

Thanks, I guess the issue here is the policy is different than uBO which is why I was running into issues and I am still seeing the number of elements being blocked.

I did manage to get it showing in Chrome by adjusting the previous string from 'adminSettings' to 'noFiltering' and messing with the JSON formatting. But I suspect the JSON needs to be further updated - we currently have sites formatted like this in one line:

[".autodesk.com/","https://www.fedex,com/*",etc]

But looking at the formatting above, each site will need to be placed in its own brackets/container, correct?

So for example we would need an entry for each site:

[".autodesk.com/"],
["https://www.fedex,com/*"],

I will play around with this to see if I can get it loaded correctly.

The proper format is shown above at the link I provided:

{
  "3rdparty": {
    "extensions": {
      "ddkjiahejlhfcafbddmgiahcphecmpfh": {
        "noFiltering": [
            "d3ward.github.io"
        ],
      }
    }
  }
}

The list of hostnames is really just plain hostnames, no wildcard, no https://..., no leading .. So using the snippet you provided in your comment, this should be:

{
  "3rdparty": {
    "extensions": {
      "ddkjiahejlhfcafbddmgiahcphecmpfh": {
        "noFiltering": [
            "autodesk.com",
            "www.fedex.com"
        ],
      }
    }
  }
}

Thanks @gorhill - I think that's the problem. We have a ton of sites with wildcards, etc so I will have to clean up our list and see if I can get it working. Appreciate you taking the time to reply.

Which exact registry key/value are you pushing?

I attempted using the following in Google Chrome to suppress the first run page:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\3rdparty]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\3rdparty\Extensions]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\3rdparty\Extensions\ddkjiahejlhfcafbddmgiahcphecmpfh]
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\3rdparty\Extensions\ddkjiahejlhfcafbddmgiahcphecmpfh\policy]
"disableFirstRunPage"=dword:00000001

That did not work, so I then added the following:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"ExtensionSettings"="{\"ddkjiahejlhfcafbddmgiahcphecmpfh\": {\"disableFirstRunPage\": {\"title\": \"Disable first run page\",\"type\": \"boolean\" \"value\": \"1\"}}}"

I added that value through Google's ADMX template under Group Policy. The box only accepts code as a single line. Sometimes the first run page does not open, other times it does. These registry keys are baked into an image for deploying new installations. I have pushed out just those keys before to live installations to mixed success. I am not sure what is the cause of the inconsistency.

I get this at chrome://policy when I set disableFirstRunPage to true:

What do you get?

I just checked a PC that had a fresh install, but still showed the first run page. Chrome policy page shows that setting exactly as you have it in the picture with the status as OK. Small note, but I also had the exact same keys applied to Microsoft Edge and it also popped up there.

I do notice a slight delay in all the policies applying when I open Chrome or Edge for the first time. Could that be why the setting is not taking effect (even though it's already in the registry)?

As of November 20, 2024, it looks like the first run page is no longer opening in either Chrome or Edge when the policy is applied. Whatever changed in the update seems to have worked! Just for clarification, do I need the registry key from "Policies/Google/Chrome" or is the key from "3rdparty/Extensions" all that is needed?

This is a uBOL setting, this needs to go under 3rdparty\extensions\ddkjiahejlhfcafbddmgiahcphecmpfh for Chrome, or (I guess) 3rdparty\extensions\cimighlppcgcoapaliogpjjdehbnofhn for Edge.

I see you are using uppercase Extensions, while as per official documentation, it should be lowercase. But I don't use Windows so I don't know.

Adding on to this, can we allow only specific filtering modes instead of all four? (Ex. Only allow users to select either basic or no filtering.)

See #113.

Hi gorhill, the goal is to reduce helpdesk overhead from users selecting complete and later having issues with websites or resource utilization. If we can disable the "optimal" or "complete" modes, it would not require additional permissions.

Which exact features you would want to prevent from being changed?

• Access to dashboard?
• Filtering mode? (including no-filtering?)

I'm not sure if anyone has responded regarding this topic, but preventing users from accessing the dashboard and changing the filtering mode would be appreciated. Would help prevent unwanted changes to filtering.

From reply above from @gorhill:

set the default filtering mode for all sites

What default filtering mode do you want? My understanding is that it's not possible for higher filtering mode than basic one require users to explicitly grant permissions to "Allow this extension to read and change all your data on websites you visit", there has to be a user gesture, i.e. clicking "Agree" to the browser prompt. Hence why the only possible filtering mode available through policy is "no filtering".

If you think there is a way through policies to bypass this prompt, I would like to know about it.

We deploy the Extension with Intune. I'll test if the permissions are accepted automatically, since the extension is deployed silently. Will report back in a few days.

Event when deployed using Intune the user will still need to manually accept the permissions...

You need version 2024.10.20.869 for the new code path which toggles default setting to Optimal if the extension detects it has broad permission at install time. The current version in the Windows Add-ons Store is still 2024.10.14.189.

In any case, I don't think there is a way to preset these optional host permissions. I opened an issue in Chromium tracker a few days ago: https://issues.chromium.org/issues/374073122. It might help to +1 it.

@gorhill Do you know if this behavior is the same for Google Workspace deployment? We are trying to deploy uBOL with Optimal filtering mode enabled by default.

I know nothing about deployment on any OS. I just test locally that browser.storage.managed.get works as intended using a JSON file as described in the wiki according to https://www.chromium.org/administrators/configuring-policy-for-extensions/.

Would it be feasible to add support to deny the user permission to add sites to this list?

Sure.

Just tested the "disabledFeatures" ("filteringMode" and "dashboard") settings. Great work! 😃

Still, we're having an issue with updating the "noFiltering" list. It turns out that, upon installing, if the registry keys are already set, uBOL will read them and correctly configure the list. Once uBOL is installed, it won't update the list if the settings change in the registry. As you pointed out, you need to bring up the popup for the extension to re-read the "noFiltering" settings and update its list accordingly.

uBOL will detect if an admin setting changes, and re-configure accordingly. The issue is probably that there is a delay before uBOL can read the modified admin settings, I have observed that this can take many seconds after browser launch or extension restart. If you open the dashboard after launch, you should see the "No filtering" content updating itself after a while.

The slow managed settings update is a browser issue, uBOL is just waiting for the browser to return back an answer and it may take long seconds, I think I have observed even ~10 seconds.

Is that valid when you do not click on the extension icon? We plan to lock the "dashboard" and "noFiltering" list, users will have no reason to click on the icon and take a look the UI of the extension.

I let Chrome open for a few minutes before closing it and then opening it again. I did this several times and I saw no change to the filtering behavior on sites that I had added to the "noFiltering" policy.

You don't need to invoke the UI. uBOL calls chrome.storage.managed.get(...) for admin settings and the browser often responds long seconds after, and when it does, uBOL reconfigure according to whether the admin settings changed from the last observed ones.

I could add support for this.

See https://github.com/uBlockOrigin/uBOL-home/wiki/Managed-settings#rulesets, in next release of uBOL.

Exactly what I was looking for, thank you!

Would anyone here happen to know what the registry version for the filter setting looks like? For a setting like disabling the first run page, I can add "disableFirstRunPage"=dword:00000001 under the correct path to apply it. I assume that the "rulesets" setting is not a dword switch so what would it look like?

That should be like the "noFiltering" list. For Chrome, that's probably something like this:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\3rdparty\extensions\ddkjiahejlhfcafbddmgiahcphecmpfh\policy\rulesets]
"1"="-*"
"2"="+default"
"3"="+adguard-spyware-url"
"4"="+annoyances-cookies"

You are mixing browser properties with extension properties. Regarding runtime_blocked_hosts the documentation says it is under ExtensionSettings policy, so in your case it would go under ExtensionSettings/cimighlppcgcoapaliogpjjdehbnofhn

disableFirstRunPage is a uBO Lite property, so it goes under 3rdparty/extensions/cimighlppcgcoapaliogpjjdehbnofhn, see https://www.chromium.org/administrators/configuring-policy-for-extensions/.

Invalid properties in one group or the other will prevent all property from being applied.

For instance this is what I use when I want to test policies, it works fine (I use ciokjnpbnekglcdehmlkojioejipaebj on my side because this the id of locally installed uBOL) -- I added runtime_blocked_hosts for demonstration:

{
  "ExtensionInstallForcelist": [
  ],
  "ExtensionSettings": {
    "ciokjnpbnekglcdehmlkojioejipaebj": {
      "runtime_blocked_hosts": [ "*://*.domain.dk" ]
    }
  },
  "ExtensionManifestV2Availability": 2,
  "3rdparty": {
    "extensions": {
      "ddkjiahejlhfcafbddmgiahcphecmpfh": {
        "noFiltering": [
        ],
        "disableFirstRunPage": true
      },
      "ciokjnpbnekglcdehmlkojioejipaebj": {
        "noFiltering": [
        ],
        "disableFirstRunPage": true,
        "rulesets": [
        ]
      }
    }
  }
}

What exactly is "custom blocking rules"?

I mean if I want to use custom rules that aren't part of the included lists. I just got the wording wrong but basically what is under "My filters" in uBo.

So basically a place where I could add custom rules like

nationalgeographic.com##.InlineImagePromo
bing.com##textarea[maxlength="2000"],input[maxlength="2048"]:remove-attr(maxlength)
blick.ch##.swiper-items-container > div:has([class*=gallery_ad]):remove()

uBOL Lite does not support custom filters at the moment.

Got it. Thank you for your work and your quick response! 🙏

This is a really useful file and most of it is working for me with the exception of the noFiltering list which seems to be ignored. Any ideas welcome; I'll post back here if I figure out what's going on.

Edit: seems to be working after a browser restart (most of the other settings took effect immediately, noFiltering seems to take longer).

Thank you! This worked for me as well for Chrome OS using Google Workspace.

{ "disableFirstRunPage": { "Value": true }, "noFiltering": { "Value": [ "google.com", "msn.com" ] } }

+EasyList/yBO -- Cookie Notices won't do anything, the token representing the list must be used, not its user-facing name. It should be annoyances-cookies, which is already declared in your admin settings.

+EasyList/yBO -- Cookie Notices won't do anything, the token representing the list must be used, not its user-facing name. It should be annoyances-cookies, which is already declared in your admin settings.

I realised I had not removed this entry from my previous attempts to get this working after uploading the screenshots. I'll leave the images here as all the other entries are correct.

Registry operations in GPO are expensive. I don't think you need to make individual registry values for each entry. Creating a noFiltering REG_SZ value under
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\3rdparty\extensions\ddkjiahejlhfcafbddmgiahcphecmpfh\policy key and setting value data as ["example.com", "example2.com"] works.

showBlockedCount will be available as managed policy in next release: https://github.com/uBlockOrigin/uBOL-home/wiki/Managed-settings#showblockedcount

What is "wildcard blocking"?

Ah sorry, should've been more explicit. I would like to be able to disable any kind of filtering on an entire domain, to also include all possible subdomains.

If you add example.com to noFiltering array, this will disable all kind of filtering on example.com and all subdomains.

Oh. You are right. I am very sorry, I thought I had tried it multiple times and saw it fail, but I probably did some mistake, again sorry. Thank you!