Hi! Thanks for the report. Assigning @meacer since he owned https://bugs.chromium.org/p/chromium/issues/detail?id=594215.

@meacer can you take a look and reassign if necessary?

It appears @meacer is out of office now, CC'ing others.

I'll leave this assigned to meacer for now, since it's low severity. I may try to debug why the BlockedSchemeNavigationThrottle (https://cs.chromium.org/chromium/src/content/browser/frame_host/blocked_scheme_navigation_throttle.cc?l=33) isn't properly handling this case if I have some spare cycles soon.

Inlining the PoC, in case the actual one goes offline:

<h3>Right click of the mouse: open new window or tab</h3>
<a name="aaa" target="name" href="data://www.google.com                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        ,fake google.com">

Google.com</a>
<script>

</script>

I wonder why data://www.google.com even parses as a valid URL.

This is specifically happening because right click open is considered a browser-initiated navigation, and the throttle only blocks renderer-initiated navigations:

https://cs.chromium.org/chromium/src/content/browser/frame_host/blocked_scheme_navigation_throttle.cc?l=57

If I remember right, we limited the blocking to renderer-initiated to still allow copy+pasting blocked scheme URLs into the omnibox for powerusers.

We can block the context menu ones too, NavigationHandle has an API to tell you whether it started that way: https://cs.chromium.org/chromium/src/content/public/browser/navigation_handle.h?rcl=dc36de41bc2a61aa572ea88b9746ee174ce9afeb&l=116

Comment 5: That's right.  Open Link in New Tab has generally been treated as browser-initiated (similar to copy/paste for a new URL), but that does lead to a lot of confusion and issues like this.  I'm not sure what depends on it being a browser-initiated navigation, but maybe we can look into changing it.  (If that doesn't work, we'll want to find a way to at least cover the data URL restriction for that case, but I imagine this isn't the only case where it causes problems.)

Comment 4: Not sure about the parsing question, but the same problem applies to syntactically valid data URLs as well.

Checking for context menu navigations seems like a good mitigation. Testing it locally, it behaves roughly as expected: the new tab does not load, although the URL is left in the omnibox. Are there any breakage concerns for adding that as an alternate condition (`IsRendererInitiated() || WasStartedFromContextMenu()`)?

Re: parsing, I do think that this weird case makes it particularly spoofy as it looks like "https://www.google.com" just with s/https/data/, although maybe only for people who understand schemes in the first place.

A cursory search found one possible case of breakage in Issue 845950 if we added the WasStartedFromContextMenu() check, but that seems like a minor internal use case that would still work with manual copy+paste.

I don't think we ever intended to block context menu navigations for data URLs. The goal of the blockage was to prevent drive by navigations to data URLs.

Open Link in New Tab is unlikely to happen accidentally, so I prefer not to special case it for data URLs.  (When we had Click-To-Play for plugins, we required a  right click to play the plugin because it was much less likely to be an accidental action)

Given these, I'm inclined to drop the security labels and open up this bug.

Dropping view restrictions since no one objected.

Issue 910308 has been merged into this issue.