Hmm.  I don't know that I agree about the spoof risk here.  We do have "data:" visible in front of the URL.

+CC Brett regarding whether escaping content in data URLs is something we don't do intentionally/what the specs are here.

Instead of "data:http://example.com" I can also use "data://example.com". Perhaps the latter is more convincing, especially to non-technical users.

This is not a true URL spoof, because the scheme is a part of the URL. For non-technical users, this is not that much different from directing them to a misspelling of the domain being spoofed.

I am clearing security flags, but leaving the bug open for the consideration mentioned in comment 1.

Technically, the scheme is part of the URL, but the point of spoofing is that the user believes otherwise.

Here is a more convincing example, I inserted multiple spaces before the spoofed URL. With EV certificates, there is also junk in front of the actual URL, so it's a believable spoof IMO.
I picked a star as a visual separator, but any Unicode symbol would work.


I just looked for "URL spoof" on the issue tracker and found  bug 646278 , a security bug with similar URL spoofing abilities. Given the similar circumstances, I move this bug back to the security team.

Deleted: url-spoof-two.png 5.9 KB

	url-spoof-two.png 5.9 KB View Download

Following the same reasoning as  https://crbug.com/646278#c18 , this is a medium security bug. But I'll defer the actual labeling to the Security team.

+Charlie for triage within your team, since you triaged the other bug.

Okay, I can let Charlie triage, though I really think Medium severity is too high for something that isn't actually a URL spoof bug. Phishing exists because URLs are fundamentally flawed security indicators, since we can't realistically expect most users to be able to understand how to parse them. Phishers use deceptive subdomains, look-alike misspellings, IDN homographs and other techniques which are potentially just as effective as data: or blob: URLs.

It's reasonable for us to try to reduce user confusion, such as IDN restrictions that try to prevent homograph attacks, but the lack of such measures is not a vulnerability in the browser -- it is a design problem in the web.

This problem is already being tracked at  issue 594215 , where meacer@ is working on blocking renderer-initiated top-level navigations to data: and blob: URLs.  meacer@, can you confirm that your plan would fix this, and if so, mark this as a duplicate?

In terms of severity, we are generally not treating data: URLs as URL spoofs, because the URL shown is accurate (and is not supposed to have an origin, because each data: URL is a unique origin).  I would justify the medium severity rating of  issue 646278  because blob: URLs *do* have origins that are visible, and that bug showed how to spoof the origin part of the URL.

That said, the potential for user confusion around data: URLs is real, and that's why we're trying to block such navigations in  issue 594215 .  Thanks for the report, and hope that clarifies things.

I agree there is no spoof here, the omnibox is showing the URL as is. I'm not sure how making the page look like it's loading changes the situation.

The work to block data: URLs is happening at  issue 594215 , so merging there.

Security>UX component is deprecated in favor of the Team-Security-UX label