Navigation to about:config is disallowed per spec

[bzbarsky]

If I read the spec correctly, when an attempt is made to navigate to "about:config" (e.g. via the URL bar) we land in https://html.spec.whatwg.org/multipage/browsers.html#navigate and in step 12 we have a "fetch scheme" so try to do a "navigate fetch".

Then in https://html.spec.whatwg.org/multipage/browsers.html#process-a-navigate-fetch step 6.1 we try to fetch the request, which results in a network error.

[bzbarsky]

/cc @annevk

[domenic]

As far as I can tell this is working as intended; see e.g. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4914 and try to click the link.

The issue is in assuming that URL bar navigation is the same as regular navigation. I always thought the URL bar was allowed to have special powers, e.g. typing "about:config<enter>" went down a different code path, not governed by specs.

[bzbarsky]

If it's not covered by specs, what is it covered by? Something needs to define what happens to the session history on URL bar navigation....

The way this is implemented in practice, in Gecko, is that there's a security check, akin to the one that prevents the "http: navigates to file:" situation, that blocks the about:config load. And clearly that check does not apply to loads via the URL bar.

I should also note that the fetch spec has an explicit note saying "about:config" is handled in navigation, so either that note or the navigation spec is wrong. ;)

[domenic]

Fair enough, that is probably a better model...

[domenic]

Let's note that related matters are being discussed in https://bugs.chromium.org/p/chromium/issues/detail?id=698559

[annevk]

If <a href=about:config>test</a> should work, the way we want to do this I think is to generally leave navigation to about:... undefined (though probably only for top-level?) and special case about:blank.

[bzbarsky]

If test should work

It shouldn't, in a web page. It should only work via the URL bar.

[bzbarsky]

Well, or other UA entrypoints (bookmarks, whatever). It should never work from any invocation of "navigate" from a web spec. But there needs to be a way of invoking "navigate" that does make it work, to explain how UAs actually work.

[youennf]

I did some tests recently with Chrome, Firefox and Safari when loading about:XX URLs.
The behaviours are widely different.

1. Top-level navigation of about:xx using window.location

• Chrome is loading about:xx (empty content), window.location is about:xx but navigation bar shows about:blank#blocked
• Firefox is denying access to about:xx
• Safari is loading about:xx (empty content)

2. iframe loading of about:xx

• Chrome is loading about:xx as a same-origin iframe
• Firefox is loading about:xx as if it was about:blank (probably it stays as about:blank).
• Safari is loading about:xx as a cross-origin iframe

3. Using window.open with about:xx

• Chrome is loading about:xx, navigation bar shows about:blank#blocked. opener is considered same-origin.
• Firefox is denying access to about:xx
• Safari is loading about:xx. opener is considered cross-origin

4. Top-level navigation of about:xx through the navigation bar

• Chrome is loading about:xx but the navigation bar shows about:blank#blocked
• Firefox is treating it as an invalid URL
• Safari is not treating it as an URL

In Safari, we are contemplating processing about:xx as if it was about:blank from the start.
This would align with Firefox behaviour for iframe, would be similar to Chrome behaviour, except for thins like window.location accessors which would return 'about:blank' instead of 'about:xx'.
Is it something that other browsers could align to as well?

Any thoughts?

[bzbarsky]

Firefox is loading about:xx as if it was about:blank (probably it stays as about:blank).

Right, Firefox tries to do the about:xx load, that's blocked, and so the initial about:blank is what's in the iframe.

I'd like to understand the exact semantics being proposed here. In Firefox, a load of a url string generally works like this:

1. The string is converted to a URL object (not exactly the same as the web-exposed URL). This part can fail in various ways. Ideally the ways it can fail are covered by the URL standard, but we may have per-protocol checks that are not in that standard that could cause this to fail at this stage. Right now about:xx gets through this stage and produces a URL object that represents a URL with two pieces to it: about for the protocol and xx for "the rest".
2. In some cases (including window.open and location sets), but not in general, a security check is performed to see whether the entity that triggered the load is allowed to load the given URL object. This is the thing that ends up failing for about:xx in cases 1 and 3 above. These security checks are legacy ones that we are working on removing, fwiw, which might affect behavior here.
3. If the security check passes, an object representing the load is created from the URL object. This step can fail even if step 1 passed, in various ways. In particular, it fails for about:xx.
4. A security check is performed on the object created in step 3. If this passes, the load tries to happen; of course this can fail for various reasons.

So a few thoughts/questions:

• Now that I've written out that list and compared it to the cases that were tested, the lack of testing for <a href="about:xx"> jumps out. What do browsers do in that situation? I am pretty sure that the step-2 security check in Firefox happens for that case too, fwiw, so I expect its behavior to be much like the location case.
• At what stage in that process would the remapping to about:blank conceptually inject. For example, if there is a <base href="about:xx">, would reading document.baseURI return "about:blank" or "about:xx"? It returns "about:xx" in all browsers right now, so presumably the remapping would not happen in step 1 (which is used by the <base> handling too), but the output from step 1 is directly used in the security checks at step 2. And we'd really rather not add weird special-casing to security checks, for obvious reasons. If we remove those step 2 checks and then have step 3 create a load for about:blank if there is an unknown about:xx, that might be workable.
• There are various privileged about: URLs in Firefox (like about:config). What is the proposed behavior in those cases? One option is "treat those as themselves but still fail the security checks they fail now", which means those would be observably different from about:xx. That would be the case to some extent even in Firefox with no other changes if we remove those step-2 security checks.... Another option is to treat them, in step 3, as "about:blank" if the load originator is not privileged enough. A third option would be to instead make about:xx act the same way as about:config and succeed at step 3, just fail all the same exact security checks. I'm not sure what's best here, though I have certain preference for making the web-facing behavior of about:config and about:xx the same, whatever that behavior is.

[youennf]

I am mostly interested in improving consistency among browsers for about:xx JS navigation loads.
Address bar about:xx loads are basically out of scope.

The most important thing to consider in my mind is web compatibility, Chrome/Safari/Firefox behaviours are all good starting points.

• Now that I've written out that list and compared it to the cases that were tested, the lack of testing for <a href="about:xx"> jumps out. What do browsers do in that situation? I am pretty sure that the step-2 security check in Firefox happens for that case too, fwiw, so I expect its behavior to be much like the location case.

I think is similar to window.open and window.location.
Firefox blocks the load when clicking or when right-clicking to 'open in a new tab'.
Chrome treats the load as about:blank#blocked as well.

• At what stage in that process would the remapping to about:blank conceptually inject.

This should be based on an URL, slightly before the call to fetch.
Your step 3 proposal makes sense to me.

• There are various privileged about: URLs in Firefox (like about:config). What is the proposed behavior in those cases?

The idea would be to treat them as any other about:xx JS navigation.
This seems consistent with what I see in Chrome and Firefox: trying to load these specific URLs through JS navigations is 'blocked'.

[bzbarsky]

Address bar about:xx loads are basically out of scope.

OK.

The idea would be to treat them as any other about:xx JS navigation.

So they would load about:blank? Would they get the origin-and-CSP-inheriting behavior about:blank gets?

I'd honestly prefer to treat such loads, as well as about:xx as network errors, presumably async from the fetch start...

[anforowicz]

I just wanted to share that I learned today (see https://crbug.com/1220186#c9) that some old best-practices documents recommended navigating to "about:self" rather than to "about:blank". One specific example is/was the "IAB Best Practices for Rich Media Ads in Asynchronous Ad Environments" document from 2008 at https://www.iab.com/wp-content/uploads/2015/09/rich_media_ajax_best_practices.pdf