adminSettings Support?

[mttaggart]

Hello! Is there any thought to bringing the adminSettings support over from uBO? It would seriously help orgs that are interested in getting ahead of the MV3 curve by using this extension.

[gorhill]

What settings do you want to be able to manage?

[mttaggart]

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

[gorhill]

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.

[dandirkmn]

This is interesting... When I test the policy with: ["://.d3ward.github.io"] (https://d3ward.github.io/toolz/adblock.html)

While the block setting is still "optimal", the extension doesn't show count of blocks. Results from page confirm functionality of exception.

Yet when I try other sites like ["://.msn.com"], the counter still displays...

Still playing with it....

[gorhill]

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"
        ],
      }
    }
  }
}

[dandirkmn]

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

[gorhill]

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.

[dandirkmn]

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

[gorhill]

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.

[dandirkmn]

What does your chrome://policy look like? Shifted over to chrome for a more direct comparison.

[gorhill]

---

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.

[dandirkmn]

That worked... Yeah see what you mean, wasn't exactly 2, but it got there after a few browser restarts. At least in my case the UI would show no filtering, but still blocking, badge counter etc. Another restart, everything caught up.

Is there a wiki for uBOL, happy to create an article for the Chrome/Windows registry keys.

Just confirmed the same worked for Edge, though it doesn't show in the respective policy page edge://policy Which doesn't surprise me a ton, saw an MS rep comment on a similar "3rdparty" policy question, that it wasn't officially supported.

[iam-py-test]

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

[possiblyanowl]

Hi there, bumping this because we are an organization that also used uBO and are now migrating to uBOL on our non-firefox browsers.

Is there any way a shared storage setting for the default filtering mode could be added? We would ideally like to set this to complete on all of our machines without having to walk users through it.

Thanks!

[gorhill]

See #35 (reply in thread) above.

[possiblyanowl]

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.

[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.

[lexcyn]

Hi @gorhill - just some suggestions/comments from an admin who uses this on over 30k clients:

• would there be a way to show in the UI that a custom filtering set is being used? It doesn't have to show all of the custom sites like the regular version, but even if it detects a filter set via policy being applied stating something like "An additional filter set is being applied by policy" would help
• similar to the above, I noticed that the little number that shows "blocked elements" still shows even on sites added to the allow list. I know the list is applying properly (tested it side by side with legacy uBO) so I'm not sure if this is just a bug or a limitation of the new API
• I see you answered the question about enabling the optimal filtering mode vs basic. Unfortunate that this requires an explicit user interaction :(

Thanks for all you do in light of these difficult changes from Google.

[lexcyn]

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).

[gorhill]

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.

[lexcyn]

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.

[gorhill]

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"
        ],
      }
    }
  }
}

[lexcyn]

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.

[SnazzLAN]

Is disableFirstRunPage meant to work on Edge (v126)?
noFiltering only applies on the second run, so are first-run settings therefore useless?

If not, would anyone mind sharing their working registry key path and value for disableFirstRunPage?

We obviously don't want the dashboard popping up on startup on every user profile that logs onto a machine when we deploy it. I find extensions opening tabs by themselves obnoxious and unnecessary behaviour in general, the users that actually care about settings are perfectly capable of finding them.

Also, more info in the wiki would be appreciated, e.g. browser-specific instructions.

For anyone after the noFiltering registry paths for Edge:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\3rdparty\extensions\cimighlppcgcoapaliogpjjdehbnofhn\policy\noFiltering]
"1"="bing.com"
"2"="google.com"

[Bvanderstraeten]

For chrome it's the following path
[Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\3rdparty\extensions\ddkjiahejlhfcafbddmgiahcphecmpfh\policy\noFiltering]

Also testing some value for the disablefirstrun, with no luck

[Bvanderstraeten]

difficult to replicate but it seems that when creating in the registry for chrome under that node;
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\3rdparty\extensions\ddkjiahejlhfcafbddmgiahcphecmpfh\policy]
a dword value of "disableFirstRunPage" with a value data of "1"

[lexcyn]

This would be great as we are planning to deploy this to over 35k users and having that prompt is causing us some sleepless nights on communicating this to users. So far in my tests I have not been able to get it working, though in both Edge and Chrome.

[robcle]

Can the app be locked so users are not able to change settings?

[gorhill]

Maybe your browser offers a way to remove the toolbar icon?

[felix-ng-lacity]

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.)

[gorhill]

See #113.