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

23592 kali dilihat
Langsung ke pesan pertama yang belum dibaca

Mustafa Emre Acer

belum dibaca,
1 Feb 2017 20.47.5501/02/17
kepadablink-dev, Emily Schechter, elaw...@chromium.org

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

belum dibaca,
2 Feb 2017 01.24.3002/02/17
kepadaMustafa Emre Acer, blink-dev, Emily Schechter, elaw...@chromium.org
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

belum dibaca,
2 Feb 2017 01.30.1202/02/17
kepadaPeter Kasting, Mustafa Emre Acer, blink-dev, Emily Schechter, elaw...@chromium.org
+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

belum dibaca,
2 Feb 2017 02.28.2202/02/17
kepadaCharles Harrison, Peter Kasting, Mustafa Emre Acer, blink-dev, Emily Schechter, elaw...@chromium.org
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

belum dibaca,
2 Feb 2017 02.39.2002/02/17
kepadaPhistucK, Charles Harrison, Mustafa Emre Acer, blink-dev, Emily Schechter, elaw...@chromium.org
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)

belum dibaca,
2 Feb 2017 07.36.4102/02/17
kepadaPeter Kasting, PhistucK, Charles Harrison, Mustafa Emre Acer, blink-dev, Emily Schechter, elaw...@chromium.org
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

belum dibaca,
2 Feb 2017 11.17.4702/02/17
kepadaTorne (Richard Coles), Peter Kasting, PhistucK, Charles Harrison, Mustafa Emre Acer, blink-dev, Emily Schechter, elaw...@chromium.org
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

belum dibaca,
2 Feb 2017 11.46.3402/02/17
kepadaJochen Eisinger, Torne (Richard Coles), Peter Kasting, Charles Harrison, Mustafa Emre Acer, blink-dev, Emily Schechter, Eric Lawrence
Note that a "Not Secure" indication was recently added to any data: URL (in Chrome 56, as stable patch!).

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

belum dibaca,
2 Feb 2017 15.50.0902/02/17
kepadaPhistucK, Jochen Eisinger, Torne (Richard Coles), Peter Kasting, Charles Harrison, blink-dev, Emily Schechter, Eric Lawrence
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

belum dibaca,
2 Feb 2017 20.37.2802/02/17
kepadaMustafa Emre Acer, PhistucK, Jochen Eisinger, Torne (Richard Coles), Peter Kasting, Charles Harrison, blink-dev, Emily Schechter, Eric Lawrence
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

belum dibaca,
2 Feb 2017 20.45.2002/02/17
kepadaRick Byers, Mustafa Emre Acer, PhistucK, Torne (Richard Coles), Peter Kasting, Charles Harrison, blink-dev, Emily Schechter, Eric Lawrence

lgtm2




PhistucK

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



Philip Jägenstedt

belum dibaca,
2 Feb 2017 23.08.2502/02/17
kepadaJochen Eisinger, Rick Byers, Mustafa Emre Acer, PhistucK, Torne (Richard Coles), Peter Kasting, Charles Harrison, blink-dev, Emily Schechter, Eric Lawrence
lgtm3 assuming nothing worrying appears in the httparchive data.

PhistucK

belum dibaca,
3 Feb 2017 01.58.4003/02/17
kepadaRick Byers, Mustafa Emre Acer, Jochen Eisinger, Torne (Richard Coles), Peter Kasting, Charles Harrison, blink-dev, Emily Schechter, Eric Lawrence
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)

belum dibaca,
3 Feb 2017 05.16.5103/02/17
kepadaPhistucK, Rick Byers, Mustafa Emre Acer, Jochen Eisinger, Peter Kasting, Charles Harrison, blink-dev, Emily Schechter, Eric Lawrence
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

belum dibaca,
3 Feb 2017 09.36.0003/02/17
kepadaTorne (Richard Coles), PhistucK, Rick Byers, Mustafa Emre Acer, Peter Kasting, Charles Harrison, blink-dev, Emily Schechter, Eric Lawrence

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

Rick Byers

belum dibaca,
3 Feb 2017 10.08.1003/02/17
kepadaJochen Eisinger, Torne (Richard Coles), PhistucK, Mustafa Emre Acer, Peter Kasting, Charles Harrison, blink-dev, Emily Schechter, Eric Lawrence
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

belum dibaca,
3 Feb 2017 12.31.0403/02/17
kepadaRick Byers, Jochen Eisinger, Torne (Richard Coles), PhistucK, Mustafa Emre Acer, Peter Kasting, Charles Harrison, blink-dev, Emily Schechter, Eric Lawrence
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

belum dibaca,
3 Feb 2017 12.36.3903/02/17
kepadaEmily Schechter, Rick Byers, Jochen Eisinger, Torne (Richard Coles), Mustafa Emre Acer, Peter Kasting, Charles Harrison, blink-dev, Eric Lawrence
Remember that use counters on Android does not count WebViews.


PhistucK

dyl...@gmail.com

belum dibaca,
6 Feb 2017 09.23.3506/02/17
kepadablink-dev, emilysc...@chromium.org, elaw...@chromium.org, mea...@chromium.org
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

belum dibaca,
6 Feb 2017 09.28.0906/02/17
kepadadyl...@gmail.com, blink-dev, Emily Schechter, Eric Lawrence, Mustafa Emre Acer
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

belum dibaca,
6 Feb 2017 09.37.0606/02/17
kepadablink-dev, dyl...@gmail.com, emilysc...@chromium.org, elaw...@chromium.org, mea...@chromium.org
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

belum dibaca,
6 Feb 2017 10.16.1606/02/17
kepadaRick Byers, Torne (Richard Coles), Emily Schechter, Peter Kasting, Mustafa Emre Acer, PhistucK, Jochen Eisinger, Charles Harrison, Eric Lawrence, blink-dev
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

belum dibaca,
6 Feb 2017 13.51.4906/02/17
kepadaElliott Sprehn, Rick Byers, Torne (Richard Coles), Emily Schechter, Peter Kasting, PhistucK, Jochen Eisinger, Charles Harrison, Eric Lawrence, blink-dev
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

belum dibaca,
6 Feb 2017 13.57.1606/02/17
kepadaMustafa Emre Acer, Torne (Richard Coles), Emily Schechter, Peter Kasting, Rick Byers, PhistucK, Jochen Eisinger, Charles Harrison, Eric Lawrence, blink-dev


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

belum dibaca,
6 Feb 2017 16.53.3606/02/17
kepadaElliott Sprehn, Mustafa Emre Acer, Torne (Richard Coles), Emily Schechter, Peter Kasting, Rick Byers, PhistucK, Jochen Eisinger, Charles Harrison, Eric Lawrence, blink-dev
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

belum dibaca,
6 Feb 2017 17.00.5106/02/17
kepadaChris Harrelson, Elliott Sprehn, Torne (Richard Coles), Emily Schechter, Peter Kasting, Rick Byers, PhistucK, Jochen Eisinger, Charles Harrison, Eric Lawrence, blink-dev
Allowing right click actions for data URLs but keeping them blocked for chrome:// et al sounds reasonable to me.

Philip Jägenstedt

belum dibaca,
8 Feb 2017 00.25.5408/02/17
kepadaMustafa Emre Acer, Chris Harrelson, Elliott Sprehn, Torne (Richard Coles), Emily Schechter, Peter Kasting, Rick Byers, PhistucK, Jochen Eisinger, Charles Harrison, Eric Lawrence, blink-dev
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)

belum dibaca,
8 Feb 2017 11.11.4308/02/17
kepadaPhilip Jägenstedt, Mustafa Emre Acer, Chris Harrelson, Elliott Sprehn, Emily Schechter, Peter Kasting, Rick Byers, PhistucK, Jochen Eisinger, Charles Harrison, Eric Lawrence, blink-dev
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

belum dibaca,
8 Feb 2017 12.10.4608/02/17
kepadaTorne (Richard Coles), Philip Jägenstedt, Mustafa Emre Acer, Elliott Sprehn, Emily Schechter, Peter Kasting, Rick Byers, PhistucK, Jochen Eisinger, Charles Harrison, Eric Lawrence, blink-dev
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.
 


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.


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

Torne (Richard Coles)

belum dibaca,
8 Feb 2017 12.41.5508/02/17
kepadaChris Harrelson, Philip Jägenstedt, Mustafa Emre Acer, Elliott Sprehn, Emily Schechter, Peter Kasting, Rick Byers, PhistucK, Jochen Eisinger, Charles Harrison, Eric Lawrence, blink-dev
We do test popular apps on WebView, but there is a huge long tail of apps (a majority of all android apps use webview) and we can't test them all.

Unfortunately, we often only find out about the extent of breakage caused by a backward-incompatible platform change like this long after a stable release - in several cases we haven't found out about major breakages until after the *subsequent* stable release, because the latency on "enough users have the new version -> enough complaints reach the app developer -> app developer figures out it was a webview change -> bug gets reported to us" can be very long.

This isn't an argument for not shipping this change, but I'd suggest you at least make sure you have the option to reasonably easily revert this for a while :)



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.


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

alexand...@gmail.com

belum dibaca,
24 Mar 2017 12.32.3924/03/17
kepadablink-dev, chri...@chromium.org, foo...@chromium.org, mea...@chromium.org, esp...@chromium.org, emilysc...@chromium.org, pkas...@chromium.org, rby...@chromium.org, phis...@gmail.com, joc...@chromium.org, cshar...@chromium.org, elaw...@chromium.org
How will this impact HTML injected into a WebView using the loadData method, which seems like it would be a very common use case? Currently the following message appears to be logged:

Upcoming versions will block content-initiated top frame navigations to data: URLs. For more information, see https://goo.gl/BaZAea.", source: data:text/html 

Thanks!

Torne (Richard Coles)

belum dibaca,
24 Mar 2017 13.06.3824/03/17
kepadaalexand...@gmail.com, blink-dev, chri...@chromium.org, foo...@chromium.org, mea...@chromium.org, esp...@chromium.org, emilysc...@chromium.org, pkas...@chromium.org, rby...@chromium.org, phis...@gmail.com, joc...@chromium.org, cshar...@chromium.org, elaw...@chromium.org
We discussed this earlier in the thread; it shouldn't be affecting use of WebView.loadData because that's not a content-initiated navigation, so unless the plan changed since this thread then that's a bug.

Mustafa Emre Acer

belum dibaca,
24 Mar 2017 13.43.1324/03/17
kepadaTorne (Richard Coles), alexand...@gmail.com, blink-dev, Chris Harrelson, foo...@chromium.org, Elliott Sprehn, Emily Schechter, Peter Kasting, Rick Byers, PhistucK, Jochen Eisinger, Charles Harrison, Eric Lawrence
Yes, the deprecation warning may be overly broad and showing in cases where it shouldn't. I'll make sure WebView.loadData still works after this change.

PhistucK

belum dibaca,
2 Apr 2017 03.33.1502/04/17
kepadaMustafa Emre Acer, Torne (Richard Coles), alexand...@gmail.com, blink-dev, Chris Harrelson, Philip Jägenstedt, Elliott Sprehn, Emily Schechter, Peter Kasting, Rick Byers, Jochen Eisinger, Charles Harrison, Eric Lawrence
What about extension-initiated navigations (the extension adds a link and adds an event listener that initiates a navigation to a data URL - all of this is done within the world of the content script)?

While the alternative solution is not too complicated (send a message to the background/event page which calls chrome.tabs.update, I guess), I do not think they should be blocked (like they can use XMLHttpRequest in the world of content script to send cross origin requests and if I remember correctly, call APIs that require user gesture as if they had a user gesture)


PhistucK

jack...@gmail.com

belum dibaca,
4 Apr 2017 15.53.3904/04/17
kepadablink-dev, emilysc...@chromium.org, elaw...@chromium.org, mea...@chromium.org
For what it's worth, there are many common use cases in web apps for loading urls from blobs. 

For example, the only workflow I'm aware of for printing a PDF from the web uses the following steps

1) Pull PDF data as blob
2) Open in new window
3) Call window.print() on window
4) Close window

On Wednesday, February 1, 2017 at 8:47:55 PM UTC-5, Mustafa Emre Acer wrote:

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.


Mustafa Emre Acer

belum dibaca,
5 Apr 2017 19.40.2805/04/17
kepadajack...@gmail.com, blink-dev, Emily Schechter, Eric Lawrence
What about extension-initiated navigations (the extension adds a link and adds an event listener that initiates a navigation to a data URL - all of this is done within the world of the content script)?

The current implementation will block content script initiated navigations. Allowing content scripts while blocking pages will complicate the implementation, and I think we should strive for simplicity here. As you pointed, there is a fairly straightforward alternative that serves this use case well.

For example, the only workflow I'm aware of for printing a PDF from the web uses the following steps

Thanks for pointing this out. I don't think this use case necessitates loading the blob URL in the top frame though. A static page that takes a blob ID as a parameter and displays the corresponding blob URL in an iframe should work the same. Nevertheless, this change will not affect blob URLs and I'll send a separate intent if we decide to change them in the future (unless you meant the literal PDF blob and not blob URLs).

gabrielale...@hotmail.com

belum dibaca,
9 Apr 2017 09.08.3809/04/17
kepadablink-dev, emilysc...@chromium.org, elaw...@chromium.org, mea...@chromium.org
Please, no!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 

habd...@gmail.com

belum dibaca,
27 Apr 2017 15.06.4627/04/17
kepadablink-dev, emilysc...@chromium.org, elaw...@chromium.org, mea...@chromium.org
houf  hiidid dijejiid jkejjjijkoqijlkd njkjdiojejnojnjd njeiojokjopjeojj jn nkmkmkndjiekndiod jeknfiojeiojdjjaklmjnnm dfknojejfoijcioejcnnjbbhnfjkldjk jkenvkjnjkhdbnkjnvjkiojjkd jj jondsnkmdjdnj fdnc kjndnkljdlkjfkn dn kjndcjshfbinklkjankjhjc en kjcuhjncouakjbh dnhbvjj hk jdkncoi hb ckj hjkbdiulkjfkjsankdjsfbhdhabiahkjnkjfbjn sakfnbojdnklkljnck hjdbhkcikjd h cjdnchj chjjknusnh d

Mustafa Emre Acer

belum dibaca,
28 Apr 2017 18.21.1328/04/17
kepadablink-dev, emilysc...@chromium.org, elaw...@chromium.org, mea...@chromium.org
Update: The blockage CL landed last week and is on Canary channel. For SEO purposes, the console message is "Not allowed to navigate top frame to data URL".

victorpa...@gmail.com

belum dibaca,
15 Mei 2017 23.29.2815/05/17
kepadablink-dev, emilysc...@chromium.org, elaw...@chromium.org, mea...@chromium.org

PhistucK

belum dibaca,
19 Mei 2017 09.50.0419/05/17
kepadavictorpa...@gmail.com, blink-dev, Emily Schechter, Eric Lawrence, Mustafa Emre Acer
Refreshing the page (by pressing F5, Control + F5, Shift + F5 in a tab, in the omnibox  or in the Developer Tools feature, by clicking on the refresh button, or by clicking on "reload" in data:text/html,<a href="javascript:window.location.reload()">reload</a> and similar) shows the deprecation warning. Those should still work after this is implemented, I believe. Should I file an issue, or did you address those cases?


PhistucK

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/637edc2c-457f-4f51-9452-4e769585a615%40chromium.org.

Mustafa Emre Acer

belum dibaca,
19 Mei 2017 13.59.2419/05/17
kepadaPhistucK, victorpa...@gmail.com, blink-dev, Emily Schechter, Eric Lawrence
Sorry, it's not clear to me which deprecation warning you are referring to. Is it the pre-Chrome 60 warning that says "Upcoming versions will block content-initiated top frame navigations"? If so, that's removed in Chrome 60 so you shouldn't be seeing it. I don't see any console warning with data:text/html,<a href="javascript:window.location.reload()">reload</a>in Chrome 60.

PhistucK

belum dibaca,
19 Mei 2017 16.49.2819/05/17
kepadaMustafa Emre Acer, victor palacio, blink-dev, Emily Schechter, Eric Lawrence
Yes, Chrome 58 -
Upcoming versions will block content-initiated top frame navigations to data: URLs. For more information, see https://goo.gl/BaZAea.

Great, just wanted to verify. :)


PhistucK

Mustafa Emre Acer

belum dibaca,
19 Mei 2017 17.24.5519/05/17
kepadaPhistucK, victor palacio, blink-dev, Emily Schechter, Eric Lawrence
Yes, it appears the deprecation message was displayed in some cases where it shouldn't have been :) Sorry about the false alarms.

mackenzie....@gmail.com

belum dibaca,
20 Mei 2017 11.07.2120/05/17