Not sure if it makes a difference but did you try to provide chrome via app policy and use the inbuild management settings to do that?

Maybe this works better than set those settings via Soti, just an idea for you to test and get further maybe.

What are the version of your Chrome browser?

What about the version and build numbers of your device agent?

There have been many posts reporting issues related to web-filtering policy for quite some time.  The problem seems to be related to deprecated whitelist/blacklist policies in Google's Chrome implementation.   Your problem may be fixed with a proper Chrome browser and device agent upgrade, but beware any such change may incur other problem(s)  or side-effects.  So, test thoroughly on  one or two devices before considering mass-scale deployment to your whole fleet of production devices. 

Have a look at the following article:

     https://discussions.soti.net/articles/web-filter-not-working-for-blacklist-whitelist-with-google-chrome

Then your problem may be related to how you configure the policy. 

From your screenshot, you are trying to configure like in many conventional firewall, blocking everything and then allowing some exceptions.  But this may not be the proper way here.

Firstly, the software (parser in the Chrome browser, device agent,  server, etc.)  may not take wildcard character like * or ?.    Secondly, the design of the API may not allow you to mix blacklist(s) and whitelist(s), and there may be no need to specify allow/block all at the very beginning.  Finally, the syntax of each individual item may also be significant, and it may be documented in some Google's Chrome manual (I had one released many years ago).  Without the latest documentation from Google, it still may not be too hard to figure out by trial-and-error in 15 minutes or so.

I haven't  done any test on the latest Chrome/MobiControl version combination lately.  So, you'd better do it yourself for your own server/device environment.  Start with just a single blacklist (exception) URL with no wildcard.  

If possible, please share your test results here  for your particular Chrome/MobiControl version combination.

Did you mean the blocking failed in only one device but succeeded in a few others? Or did you actually just looked at one device and it failed?

What exactly did you type in?

I just took 2 minutes to test a Samsung device on hand and it was OK.

I checked the Web Filter myself and I am running in the same problem as you, Simon.

The configuration is not applied to the Chrome browser.

I am using agent version 15.2.3 and Chrome 105.*.

On the following website you can see which types of URLs Chrome understands in its block or allow lists.
https://chromeenterprise.google/policies/?policy=URLBlocklist.

So I think it is correct to use the * symbol for blocking all websites. 

I tested it with blocking one specific website, but no success.

You can check if Chrome has applied the policy successfully by typing chrome://policy in the address bar.

My bookmark policy is visible, but not the block or allow list for URLs.

edit: After upgrading the device agent to v15.2.4 it suddenly works for me.

In my example I created a block rule with the following content:

www.spiegel.de

And it worked. This website is blocked by Chrome.

So you may try upgrading the device agent to the latest version.

Firstly,  retry with simple URL such as 

     www.google.com

Secondly, test on more than one device, preferably of different brand/model or firmware version, to confirm if the problem is consistent?

Thirdly, check the version and build numbers of your MobiControl server.

OMG.  That's why.

So, it works in the Chrome Browser app.  Just the same test results as mine.

When you use a lockdown shortcut, the web-page is displayed by the rendering engine within the Soti device agent, not by the Chrome Brower app.  The Web-Filter profile payload option affects only the Google Chrome Browser app.

BTW If you want to block an URL, you won't add it as a lockdown shortcut anyway.

Forget about the document at https://chromeenterprise.google/policies/?policy=URLBlocklist., as the parser in my MobiControl server v15.6 does not allow many of the patterns mentioned.

Blocking of all initially with wildcard * is OK,  but whitelist of all with wildcard * is not allowed (not needed anyway)

Single-character wildcard ?, slash and colon character are not supported.

If Google Chrome browser app is already the default browser or the only browser app available on your device, use the following as your kiosk item to go to www.abc.com:

    intent:https://www.abc.com#Intent;action=android.intent.action.VIEW;end

In your web filter profile payload, specify

   BLOCK   *

   ALLOW   www.abc.com

Hi Simon,

There are currently no managed configuration options in Google Chrome to hide address bar or other features needed in your use case.  So you shouldn't be using or asking about web-filtering profile payload in the first place, as it is used to configure Google Chrome apps.  The built-in renderer is primarily used to support a very flexible lockscreen layout with html/css/javascript that all likely reside on the device, and is not meant for accessing external web pages in a secured manner, and that's why there is no support for URL blacklist/whitelist.

When doing your tests using Soti Surf,  you had actually made the right choice.  Just use surf://YourURL  rather than https:// or other kiosk item types, when defining your lockdown item.   It has an added advantage of supporting dynamic URL with custom attributes or some standard MobiControl macros.

There are plenty of security features configurable using Soti Surf profile payload, including kiosk, catalog, whitelist, ...