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 that is similar to other matching 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 have 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:
- A leading dot before the host means exactly match; the filter
.example.commatches justhttps://example.combut nothttps://www.example.com - 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 query (
example.com?bar=*); you may omit the path to have the 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 ofdata:*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 blob and 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 blob: URL.
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.
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).
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?)
References
Impatient optimist. Dad. Author/speaker. Created Fiddler & SlickRun. PM @ MSFT '01-'12, and '18-, presently working on Microsoft Edge. My words are my own. View more posts