Doing a bit of digging,
https://bugzilla.mozilla.org/show_bug.cgi?id=680300 contains some more
interesting context...
We apparently used to sync-throw when assigning location.href to an
unknown protocol URI in the past, there we changed it to silently fail,
and now it is navigating to an error page...
I'll try to look at when behavior changed around here... Though the
sync-throwing clearly makes no sense as it doesn't account for redirects
or what not.
-- Emilio
On 3/29/20 8:23 AM, Emilio Cobos Álvarez wrote:
Hey, a quick web-observable change that may deserve a bit more
visibility / an intent.
I'd welcome some feedback, specially from the fingerprinting / privacy
angle (where I'm clearly not an expert).
Summary: A page redirecting / navigating to an unknown protocol will be
silently ignored (and logged to the DevTools console) instead of showing
an error page. This is not amazing, but it's needed because it causes a
bunch of compat issues (see the list of issues in the bug below).
There are a few subtle problems here. Part of the issue is that authors
don't have a cross-browser way of detecting whether a protocol will be
handled externally (that is, whether an app is installed to handle a
given protocol).
They technically can in Firefox (see example below). It's unclear
whether we want to expose more than that, or that at all.
Given Chrome just ignores the navigation if they can't handle it, some
authors (who don't seem to test on other browsers ;)) just spam the
redirect (using various methods like the location href setter / meta
refresh / whatevs). This works just fine in Chromium-based browsers, but
not in Firefox or Safari, which will just show an error, which causes a
very frustrating experience for users.
As far as I know, this behavior doesn't really expose more information
than we were exposing before. In a test-case like:
<iframe src="unhandled-protocol://foo"></iframe>
<iframe src="handled-protocol://foo"></iframe>
we have different behavior also before this patch: the contentDocument
for the handled-protocol iframe will be accessible to content, and be
about:blank. The contentDocument for the unhandled protocol will be the
error page, which will not be accessible to content and thus be null.
Other browsers seem to do about:blank for both iframes, but you can also
detect this in all browsers via window.open instead (there may be other
ways around it too, haven't dug all that much). Chrome insta-closes the
handled protocol window (so you can check window.closed). Firefox /
Safari will leave about:blank in that window, and show an error document
for the second (which will throw a security error on access).
So I don't think this change introduces a new privacy hole. That being
said, this all seems a bit sad, and a somewhat-serious potential
fingerprinting factor. I was in fact a bit nervous about this change
before realizing we were already exposing this information in other
(even simpler to test) ways... But I'm clearly not an expert on this
matter.
There are mitigations possible both for the ignored-navigation case
(maybe only ignore the navigation to an unknown protocol once per
document or something, and only for browsing contexts that can't be
accessed by any ancestor JS? not sure) and the iframe case (probably
just not show error pages in frames?). Please let me know if I you think
I should file this and follow-up on it.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1528305
Standard: https://html.spec.whatwg.org/#process-a-navigate-url-scheme
allows for both the old and new behavior, as far as I (and Anne) can
tell. This uses urls after redirect and so on so beforeunload and such
will fire. This matches the behavior of Chromium browsers.
Preference: dom.no_unknown_protocol_error.enabled (I could've sweated it
a bit more).
Devtools bug: N/A, ignored navigations get logged to the console.
Other browsers: Chromium browsers do this, but WebKit doesn't seem to.
This was causing compat issues, specially on Android, but also desktop
(see above).
web-platform-tests: Spec allows both behaviors, so I've added an
internal test for now. Furthermore it's not clear if we want to do this
for sub-windows, which my patch does, so I may need to tweak the test or
add an internal switch depending on the outcome of the discussion here.
Secure contexts: not restricted to secure contexts, this is a compat
hack, of sorts...
Is this feature enabled by default in sandboxed iframes? Not sure if the
question quite applies to this, but we don't special-case sandboxed
iframes here. This doesn't expose anything you couldn't do before, as
discussed above.
Thanks for reading all the way until here
-- Emilio
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
