At present, I can’t, so I may have to uninstall chromium-browser (and in future, potentially, any other snaps) since I need to enforce policy system-wide, in this case restrict the URLs a user can access such that they can’t override it.
(Yes, I’m using a forced web proxy-- https sites don’t allow control of URLs without MITM evil I’d rather avoid)
Sounds as if this should be done on the firewall and not on the client.
How would a firewall block URLs on an HTTPS site without using MITM?
by watching network traffic on IP level and blocking port 443 for a pre-defined set of IPs like firewalls do (there is no need for MITM if you block the general port access before any negotiation happens) ?
That blocks a host, not a URL, i.e. there is no ability to allow one path but not another. i.e.
https://example.com/foo OK
https://example.com/bar blocked
is impossible.
First of all, I am not a network specialist.
The main problem is, that you base your “security policy” on client software. The snap is inside the home directory of the user and the user can replace it with a version without your “restrictions”.
Instead, you should control the outgoing traffic from the network device, not from one specific software. Any restrictions on a browser does not affect wget or curl. You don’t have solved the problem, you have found only one workaround for one specific software.
If the domain example.com is under your control, than you should fix it on the server side (authentication and authorisation).
If the domain is not under your control, than you need a firewall which is working on higher OSI layers. I guess, a web application firewall (WAF) can do this.
So far, I don’t really understand, why you want to allow example.org/foo, but not example.org/bar. Maybe you could explain, what exactly you try to do and not how?