Not allowed to navigate top frame to data URL
Intent to Deprecate and Remove: Top-frame navigations to data URLs
Summary
We intend to block web pages from loading data: URLs in the top frame using tags, window.open, window.location and similar mechanisms.
Motivation
data: URLs are generally a source of confusion for users. Because of their unfamiliarity and ability to encode arbitrary untrusted content in a URL, they are widely being used in spoofing and phishing attacks. Another problem is that they can be passed along without a backing page that runs JavaScript (e.g. a data URL can be sent via email). For that reason, we intend to block top-frame navigations to data URLs.
We are considering two alternative implementations:
Alternative 1:
Block only content initiated top-frame navigations to data URLs, while still allowing direct navigations to them. Similar measures are already in place for other schemes such as “chrome:”, “chrome-devtools:” and more recently, “view-source:”.
In practice, these will be blocked:
Navigations when the user clicks on links in the form of
window.open(“data:…”)
window.location = “data:…”
Meta redirects
The following will still be allowed:
User navigating to the URL by typing or pasting it in the omnibox
Downloads from these protocols:
Via non-browser-handled MIME types
Via
Via “Save link as”
Alternative 2:
Block all top-frame navigations to data URLs. This only differs from (1) in that it will additionally block direct navigations (“User navigating to the URL by typing or pasting it in the omnibox”).
In both cases, subresources with data URLs (e.g.
<img src=”data:...”>, <iframe src=”data:...”>) will be allowed.
Pros of Approach 1:
Lower risk of breakage
Cons of Approach 2:
Might be confusing to some users (“why does it work when I type the address but not when I click the link?”)
We might end up playing whack-a-mole with edge cases where we don’t properly block the URLs
Pros of Approach 2:
Straightforward approach, consistent with IE/Edge behavior.
Might be simpler to implement.
Cons of Approach 2:
Higher risk of breakage
Compatibility Risk
IE and Edge already block all top-frame navigations to data URLs. Firefox and Safari allow them.
If we implement (2), Chrome’s behavior will align with IE/Edge after this change.
The blocking will be similar to how chrome:// URLs are handled:
For same page navigations, clicking the link won’t do anything, and a message will be displayed in the console.
For navigations in other tabs or popups, the page will navigate to about:blank instead.
No event handlers will be triggered.
Alternative implementation suggestion for web developers
The main use case for navigating to data URLs in the top frame is generating files (HTML, PDF, images etc.) on the fly and displaying them to the user.
For that use case, these alternatives exist:
-
Generate the file on the backend and send it to the user over http/https.
-
Initiate a download instead of displaying the URL.
-
If the contents of the URL is trusted, iframe the URL so that the omnibox displays the site’s URL.
Usage information
According to latest Stable Channel metrics over the last 28 days in January 2017, data URLs are 0.05% of all top-frame navigations among all platforms, and 0.01% of all navigations on Android.
OWP launch tracking bug
OWP tracking bug: https://crbug.com/684011
Discussion: https://crbug.com/594215
Entry on the feature dashboard
https://www.chromestatus.com/feature/5669602927312896
Requesting approval to remove too?
Yes, requesting approval to block top-frame navigations to data URLs.