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.

参考链接：来自Google论坛