Intent to Deprecate and Remove: Top-frame navigations to data URLs

[Mustafa Emre Acer]

Primary eng (and PM) emails

Eng: mea...@chromium.org

PM: emilysc...@chromium.org

Summary

We intend to block web pages from loading data: URLs in the top frame using <A> 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 <A HREF=”data:…”>

• 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 <A download>

• 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.

[Peter Kasting]

On Wed, Feb 1, 2017 at 5:47 PM, Mustafa Emre Acer <mea...@chromium.org> wrote:

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:”.

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”).

Please don't implement approach 2.  As the omnibox owner, I actually test data: URLs and the like by typing them in.  If we find we really have to, we can mitigate entry using a method like what we do for javascript: URLs, where we strip the scheme on paste -- the code to do that is already there -- but I would vastly prefer leaving these untouched unless we run into further problems.

The omnibox is a pure user-entry surface that should be able to directly load anything the browser can.  Blocking navigations from it should be viewed as an extremely serious step that we have not been willing to take for any other type of URL so far (even shellexecute-type stuff, to my knowledge).

PK 

[Charles Harrison]

+1 

There have been a number of very simple renderer crashes that can be triggered by navigating to a data url. This is very convenient for e.g. pasting into bug reports, as opposed to hosting a file somewhere (or forcing another dev to host it locally to test/bisect).

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[PhistucK]

While I also use data: URLs constantly (multiple times hourly sometimes!) for test cases and quick-hack-to-see-if-it-works, I can sympathize with the risk it entails and I think the javascript:-removing approach would be appropriate here (I usually type them, not paste them, so this will only marginally affect my use case).

You can block them altogether, if you really think this is the only safe way to go, but I think it is way too harsh.

It is a shame that data: URLs have to be blocked in any way, though and I would even call it an intervention, honestly.

Regarding the alternatives, blobs can be constructed with the same string (minus data:text/html,) and navigation to them will still be allowed, right?

If so, is that fine from a security perspective (because it shows the originating domain, though with a perhaps confusing prefix), or is this going to be deprecated as well (as far as you know now)?

That can be a sort of acceptable alternative (it only adds about three lines of code, if I remember correctly).

I can imagine a tool that quickly generates blob URLs for the use case we had for data: URLs for test cases (though much less convenient, since you have to create a new URL for every single change you make), but it will not be the same. :(

☆PhistucK

[Peter Kasting]

On Wed, Feb 1, 2017 at 11:27 PM, PhistucK <phis...@gmail.com> wrote:

I can sympathize with the risk it entails

They entail risk if they're being used in social-engineering attacks involving pasting them.  There are reasons people suggest doing that with JS URLs, most of which don't apply to data: URLs, and I think the risks here are much lower.

I am leery of assuming risk and fixing problems unless you know concretely what the risks and problems are.

PK

[Torne (Richard Coles)]

Android WebView apps use top-frame data URLs very frequently. Alternative 2 would definitely break those. It's likely some of them will also be broken by alternative 1, but I'm not sure how common that usage is, and we don't currently have metrics for WebView.

[Jochen Eisinger]

Do you have some data or estimates on what part of those 0.05% of navigations are phishing attempts?

I understand that from a security perspective, we'd have to block all possible paths, because otherwise attackers will find ways around this, but I don't think we can break 0.05% of all top-level navigations.

Have we explored alternatives, such as the stripping of the protocol on paste that Peter mentioned, or warn the user if there are e.g. forms on a data: URL, or otherwise making it hard to influence the text shown in the omnibox if it's a data url?

[PhistucK]

Note that a "Not Secure" indication was recently added to any data: URL (in Chrome 56, as stable patch!).

https://chromium.googlesource.com/chromium/src/+/2fde612bdca4930cd5bf82a2603ad86d9c5cec57

Huh, this is pretty weird. If data: URLs are not considered secure, then how come you can embed them as an iFrame in an HTTPS page? I would expect them to be mixed content by that rule...

(I do not really think they should be considered insecure, really. Just vulnerable to phishing, just like any page when running a javascript: URL on it)

☆PhistucK

--

[Mustafa Emre Acer]

Thanks everyone for the feedback. Some answers inline:

> It is a shame that data: URLs have to be blocked in any way, though and I would even call it an intervention, honestly.

It is indeed an intervention, please see intervention-dev for past updates.

 

> Regarding the alternatives, blobs can be constructed with the same string (minus data:text/html,) and navigation to them will still be allowed, right?

blob: will be allowed for the time being, though there is ongoing discussion about it (see crbug.com/594215). blob URLs require a backing page to be generated and have a security origin, so we might have other options there, e.g. change how they are displayed. 

> Do you have some data or estimates on what part of those 0.05% of navigations are phishing attempts?

We have additional Rappor data where google.com and fb.com properties occasionally show up as top initiators of data navigations. Upon further research, these look to be open redirectors that end up at data URLs, and I think it's reasonable to assume they are being used for phishing. 

> Have we explored alternatives, such as the stripping of the protocol on paste that Peter mentioned, or warn the user if there are e.g. forms on a data: URL, or otherwise making it hard to influence the text shown in the omnibox if it's a data url?

If we implement #1 (and I lean towards it), stripping the scheme will be moot since direct navigations won't be blocked. We are also looking into other improvements (crbug.com/680810 for form warnings, crbug.com/533705 for graying out url).

> Huh, this is pretty weird. If data: URLs are not considered secure, then how come you can embed them as an iFrame in an HTTPS page? I would expect them to be mixed content by that rule...

The short answer is that data URLs themselves are loaded without hitting the network thus they are not mixed content when loaded on an HTTPS page. Also, please see crbug.com/684231.

[Rick Byers]

I chatted a bit with Mustafa and Emily about this.  There really is a lot of evidence and user complaints about phishing attacks leveraging this, which makes trying something fairly urgent.  It's really hard to say what fraction of the 0.05% is phishing, but it could be most of it (especially given that Edge already blocks this).

Mustafa, can you please check HTTP Archive to see if you can find any example of a site that triggers our UseCounter for this on page load?  That seems like it shouldn't happen, but if it ever does it would be worth digging in to to understand why.

Assuming we can't find evidence of a site relying on this for legitimate usage than LGTM1 to deprecate and remove, and given the urgency I'd suggest merging the deprecation warning back to M57 and land the removal in M58 ASAP.  If you get reports of sites relying on this for legitimate usage then please follow-up here so we can discuss the implications.

There's probably a spec issue to be raised on this, right?  Can we produce a pull-request for how we'd like to see the spec change and debate with the other implementations?  IMHO getting consensus on that doesn't need to block shipping, but we should at least get the process going.

[Jochen Eisinger]

lgtm2

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

lgtm3 assuming nothing worrying appears in the httparchive data.

[PhistucK]

I know websites are using this to hide their referrer (though they can simply use referrerpolicy nowadays, right?). Hehe, I really liked that way of thinking at the time, actually. I thought it was a clever use of this feature.

Perhaps there should be a page linked from the deprecation warning (and later, the request-blocked warning) that explains how to use referrerpolicy instead.

☆PhistucK

[Torne (Richard Coles)]

I'm still concerned about the possible impact on WebView but I'm not really sure what we can do about it other than be ready to revert if we see lots of issues. WebView doesn't have metrics and is often used to view content embedded in the app or dynamically generated by private API endpoints, which won't show up in the HTTP archive. Deprecation warnings also haven't generated a lot of developer feedback in the past; many developers don't actively test their apps on current versions of WebView and won't see the warnings.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jochen Eisinger]

Maybe the way to go is to not have this restriction for webview?

[Rick Byers]

The most common ways an Android app could load a data URL unto a WebView shouldn't be impacted (since they're not "content navigations"), right?  But I can imagine how there may still be substantial risk here.

But WebView is also used to build browsers of potentially malicious content, right?  So the same phishing protection arguments apply.  Perhaps we could use a targetSdk quirk for this so that Android apps are only impacted when the build against a future SDK?  Or perhaps we should wait until we have concrete examples of this being a problem in practice before going to the effort?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Emily Schechter]

My understanding is that usage on Android is much lower than on Desktop, so the breakage risk is actually less (@meacer, did we have a separate use counter?)

[PhistucK]

Remember that use counters on Android does not count WebViews.

☆PhistucK

[dyl...@gmail.com]

As others have mentioned, this looks like a fairly breaking change for various approaches to testing. For example, Intern ( http://theintern.github.io/intern/ ) uses top-level data URLs approach within its Leadfoot ( https://github.com/theintern/leadfoot ) library to run a series of feature tests using WebDriver, prior to running tests. This is to prevent user tests from triggering known WebDriver defects. I don't see either proposed alternative working in this scenario, since it's in the context of an automated testing environment.

[PhistucK]

Is it using window.location.href (and friends) or clicks on <a href> to change the top level URL to a data: URL, or is it using the WebDriver API for navigation?

I think the former is problematic, while the latter should not be.

☆PhistucK

On Mon, Feb 6, 2017 at 4:23 PM, <dyl...@gmail.com> wrote:

As others have mentioned, this looks like a fairly breaking change for various approaches to testing. For example, Intern ( http://theintern.github.io/intern/ ) uses top-level data URLs approach within its Leadfoot ( https://github.com/theintern/leadfoot ) library to run a series of feature tests using WebDriver, prior to running tests. This is to prevent user tests from triggering known WebDriver defects. I don't see either proposed alternative working in this scenario, since it's in the context of an automated testing environment.

--

[dyl...@gmail.com]

It is using the latter (the WebDriver API). I suppose it was the "and similar mechanisms" that gave us pause for concern, as well as alternative 2 which blocks direct navigation. I understand that WebDriver does not follow the same path as direct navigation, but the intent of the WebDriver API is to mimic direct user interactions. I hope that helps.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Elliott Sprehn]

I think the discussion of the two strategies is confusing this intent, I don't think we can do #2 at all, it breaks a substantial amount of use cases (as listed here already plus more). For example folks draw to canvases and then use toDataURL() to display them in an img element. From there users can right click the element and choose "Open in a new tab" or "download" and this would break that.

In the future we should probably have design discussions before the intent to deprecate phase. Having multiple ideas, one very extreme and one less so in the same intent makes this discussion hard to follow.

Which thing got an LGTM above? 

[Mustafa Emre Acer]

> In the future we should probably have design discussions before the intent to deprecate phase. Having multiple ideas, one very extreme and one less so in the same intent makes this discussion hard to follow.

To clarify, I'm going to proceed with Approach #1 (only blocking content initiated navigations). The feedback from this thread indicates that full blockage will be too disruptive and may break legitimate use cases.

We had a separate discussion before sending this intent, and listing both approaches was a decision from that discussion. 

Rick, Jochen, Philip: Could you please clarify that you are LGTM'ing Approach #1?

> From there users can right click the element and choose "Open in a new tab" or "download" and this would break that.

Downloads shouldn't be blocked in either case. In contrast, "Open in a new tab" will be broken in both cases to be consistent with the blocking of other URLs such as chrome://, view-source:// etc ("Open in a new tab/window" doesn't work with these URLs). That is, unless we make an exception for data URLs. 

[Elliott Sprehn]

On Feb 6, 2017 1:51 PM, "Mustafa Emre Acer" <mea...@chromium.org> wrote:

> In the future we should probably have design discussions before the intent to deprecate phase. Having multiple ideas, one very extreme and one less so in the same intent makes this discussion hard to follow.

To clarify, I'm going to proceed with Approach #1 (only blocking content initiated navigations). The feedback from this thread indicates that full blockage will be too disruptive and may break legitimate use cases.

We had a separate discussion before sending this intent, and listing both approaches was a decision from that discussion. 

Rick, Jochen, Philip: Could you please clarify that you are LGTM'ing Approach #1?

> From there users can right click the element and choose "Open in a new tab" or "download" and this would break that.

Downloads shouldn't be blocked in either case. In contrast, "Open in a new tab" will be broken in both cases to be consistent with the blocking of other URLs such as chrome://, view-source:// etc ("Open in a new tab/window" doesn't work with these URLs). That is, unless we make an exception for data URLs. 

That seems like a pretty serious breakage. A user choosing "Open in tab" on an image with a data URL src is very reasonable for an offline image editor app or photo galleries. For example Google image search even used data urls for thumbnails at one point.

I don't see why choosing an option like that from a context menu (or dragging the image into the tab strip) would be different from a user pasting the URL into the omnibox.

[Chris Harrelson]

On Mon, Feb 6, 2017 at 10:57 AM, Elliott Sprehn <esp...@chromium.org> wrote:

On Feb 6, 2017 1:51 PM, "Mustafa Emre Acer" <mea...@chromium.org> wrote:

> In the future we should probably have design discussions before the intent to deprecate phase. Having multiple ideas, one very extreme and one less so in the same intent makes this discussion hard to follow.

To clarify, I'm going to proceed with Approach #1 (only blocking content initiated navigations). The feedback from this thread indicates that full blockage will be too disruptive and may break legitimate use cases.

We had a separate discussion before sending this intent, and listing both approaches was a decision from that discussion. 

Rick, Jochen, Philip: Could you please clarify that you are LGTM'ing Approach #1?

> From there users can right click the element and choose "Open in a new tab" or "download" and this would break that.

Downloads shouldn't be blocked in either case. In contrast, "Open in a new tab" will be broken in both cases to be consistent with the blocking of other URLs such as chrome://, view-source:// etc ("Open in a new tab/window" doesn't work with these URLs). That is, unless we make an exception for data URLs. 

That seems like a pretty serious breakage. A user choosing "Open in tab" on an image with a data URL src is very reasonable for an offline image editor app or photo galleries. For example Google image search even used data urls for thumbnails at one point.

I don't see why choosing an option like that from a context menu (or dragging the image into the tab strip) would be different from a user pasting the URL into the omnibox.

I agree that this seems a serious problem. Can this be special-cased?

[Mustafa Emre Acer]

Allowing right click actions for data URLs but keeping them blocked for chrome:// et al sounds reasonable to me.

[Philip Jägenstedt]

Approach #1 is what I assumed since it was your preference and #2 got pushback.

And keeping "Open in new tab" working on data: images seems reasonable, but is that cleanly separated into its own code path and policy, or will that also keep a few other cases still working? Anything that fixes the problem without breaking too much and that the reviewers are happy with is fine, really.

One thing, though, at least in the case of a script trying to navigate a top-level frame, this change should be web observable, right? Would it be possible to write web-platform-tests for this that will pass in Chromium but fail elsewhere? If so, there should be some spec that covers this that should be updated, and it's probably HTML. Can you look into that while making the change?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Torne (Richard Coles)]

OK, as long as we're going with approach #1 this probably is okay for WebView, but since we don't have metrics (or a large dev/beta population) we aren't likely to find out if this breaks a lot of WebView apps until after it ships to stable - we'll have to keep an eye on incoming bug reports for any developers/users reporting issues here.

[Chris Harrelson]

On Wed, Feb 8, 2017 at 8:11 AM, Torne (Richard Coles) <to...@chromium.org> wrote:

OK, as long as we're going with approach #1 this probably is okay for WebView, but since we don't have metrics (or a large dev/beta population) we aren't likely to find out if this breaks a lot of WebView apps until after it ships to stable - we'll have to keep an eye on incoming bug reports for any developers/users reporting issues here.

I'm concerned about WebView. Are there a suite of common WebView apps that can be tested manually on an earlier channel? I would hope the Chrome testing team does some of this as part of release testing.