[relate]

Another issue is that browsers do not display the non-secure http:// prefix in the url bar (which should probably be red and striked through).

As a PoC, I bought the domain https.is, and now I can construct urls like https.is//accounts.google.com - which can look convincing when glimpsed over.

[nucleardog]

This is why I disagree with the author's solution and find the Google employee's response fairly compelling:

> The data: URL part here is not that important as you could have a phishing on any http[s] page just as well.”

Calling out the use of data URIs doesn't solve the issue at all. I could just as easily register abc.xyz, pick up an SSL certificate, and send users to `https://abc.xyz//accounts.google.com/ServiceLogin?service=ma... or `https://abc.xyz/https://accounts.google.com/ServiceLogin?ser...

They get a green lock, and that certainly doesn't seem to require the user to overlook any more than the URI in question: `data:text/html,https://accounts.google.com/ServiceLogin?service=mail`

Anyone who treats the URI as an opaque string and simply scans for keywords (which is someone falling for the data: trick) is going to be vulnerable to a large variety of attacks, almost none of which the proposed solution solves.