Chromium-based browsers like Microsoft Edge make very limited use of Windows Security Zones. Instead, most permissions and features that offer administrators per-site configuration via policy rely on lists of rules in the URL Filter Format.
Filters are expressed in a syntax (Chrome Doc, Edge Doc) that is similar to other types of globbing rules, but different enough to cause confusion. For instance, consider a
URLBlocklist rule expressed as follows:
These filters don’t work as expected. The HTTPS rule should not include a trailing * in the path component (it won’t match anything), while the
data: rule requires a trailing
* to function.
The syntax has a few other oddities as well:
- You do not use a * to represent a part of a hostname: the * character is only used by itself to mean “ALL hosts”. A rule of
*xample.comis invalid and does not match
- The right way to express “Match example.com and its subdomains” is just
example.com. If you want to match only the hostname
example.com, and none of its subdomains, use
.example.com(note the leading dot).
- You may specify a path prefix (
example.com/foo) but you must not include a wildcard
*anywhere in the path
- You may specify wildcards in a querystring (
example.com?bar=*). You may omit the preceding path component to have that querystring checked on all pages, or include a path to only check the querystring on pages within the path.
- A rule of
blob:*doesn’t seem to match blob URLs, while a rule of
data:*does seem to match all data URLs.
Unfortunately, there’s not a great debugger for figuring out the proper syntax. You can use the
chrome://policy page to see whether Chrome finds any glaring error in the policy:
…but short of testing your policy there’s not a great way to verify it does what you hope.
Q: The problem of special-URLs
There are a variety of special URLs (particularly
data) that do not directly express a hostname– instead, the URL exists within a security context that is not included in the URL itself. This can cause problems for Policies if the code implementing the policy does not check the URL of the security context and looks only at the blob/data URL directly. A system administrator might set a policy for downloads from
https://example.com/download, but if download page on that site uses a script-generated file download (e.g. a
blob), the policy check might overlook the rule for
example.com because it checks just the
An example bug can be found here.
Q: Can filters match on a site’s IP?
The Permissions system’s “Site Lists” feature does not support specifying an IP-range for allow and block lists. Wildcards are not supported.
It does support specification of individual IP literals, but such rules are only respected if the user navigates to the site using said literal (e.g. http://127.0.0.1/). If a hostname is used (http://localhost), the IP Literal rule will not be respected even though the resolved IP of the host matches the filter-listed IP.
Q: Can filters match just dotless hostnames?
Not today, no. You must individually list each desired hostname, e.g. (
https://payroll, https://stock, https://who, etc).
Chromium’s URL Filter Format is convenient if your intranet is structured under one private domain (e.g.
*.intranet.example.com) but is much less convenient if your Intranet uses dotless hostnames (http://example) or many disjoint private domains.
The ability to match only hostnames not containing dots would be convenient to accommodate the old IE behavior whereby Windows would map dotless hostnames to the Local Intranet Zone by default. (To my surprise, there’s been no significant demand for this capability in the first year of Edge’s existence, so perhaps corporate intranets are no longer using dotless hostnames very much?)