No way. The most sincere problem is that hostnames do not enforce any binding to a real world identity that users can understand (nobody inspects certs) and that the most trustworthy component of a hostname is the second to the last section (right before ".com"). Humans tend to look at the front of the URL, making "www.bank.evil.com" a mind bogglingly effective phishing technique.
Homoglyphs are almost always a sign of bad behavior and can just be banned to a large degree. The fact that "foo.com" or "foo.evil.com" are not necessarily owned by company foo is much worse.
Regarding lacking binding of identity: On the other hand, this has been one of the most important features of the web, from the very beginning. Also, there is no way to setup a system, which will attribute to a single person in a readable and intuitive way. (E.g., names fail to do so.) Arguably, this should be left to (optional) extensions.
I'd argue, the knowledge required to parse a URI safely may be conveyed in couple of minutes. Why not enforce this knowledge? Why not have a URL-parsing note on the start screen of any browser? Why dumb down the system and introduce ambiguity – and by this even more insecurity – instead of educating users? URL-parsing is a vital skill, which can be acquired in less time than memorizing a basic table of partial addition results. Why do we still try to teach addition, if we can't teach URLs?
foo.com is owned by "foo" foo.evil.com is owned by "evil" foo.co.uk is NOT owned by "co"
> Looking back on 15 years or so of development of the Web is there anything you would do differently given the chance? > "I would have skipped on the double slash - there’s no need for it. Also I would have put the domain name in the reverse order - in order of size so, for example, the BCS address would read: http:/uk.org.bcs/members. The last two terms of this example could both be servers if necessary."
From http://www.impactlab.net/2006/03/25/interview-with-tim-berne...
First start at the slash and work your way left: "com -> noodles -> tasty -> mobile" - then jump back to the slash and work your way right: "italian -> fettuccine".
This is counterintuitive and I doubt most users understand it. "com.noodles.tasty.mobile/italian/fettuccine" makes more sense to me.
Also, I think TLDs like "com" and "edu" and now "io" and "cool", etc, are misguided. I wish we had "country.language" as the only TLDs. For instance, "us.en.apple.www/mac". I see several advantages.
One, if "us.en.apple" and "uk.en.apple" were different entities, it would make legal sense, whereas "apple.com" and "apple.cool" being different entities makes no sense. Two, a use would likely notice if they ventured outside their usual TLD(s), and be less surprised by the different entity. Three, these TLDs could have rules about allowed characters; eg, only ASCII in "us.en". This would make homoglpyh attacks much more difficult.
Who's without interest may throw the first stone, er, browser extension.
Recently a friend of mine didn't see the lower dot on the 'e' in a URL [0], and promptly ended up inadvertently broadcasting messages to everyone on her WhatsApp contacts list.
[0] www [dot] hẹb [dot] com/coupon/
If you have 1000 distinct images, but a given domain has 5 letters that could each be replaced with any of 3 visually identical Unicode characters, then, well, the chances are very high that there exists a plausible impostor domain with the same image. I don't think this is a very workable approach.
An identicon is a hash value represented as an icon. "facebook.com", for instance, may hash to a red image with a yellow line through it. While you wouldn't remember the icon initially, over time you would – or at least your subconsious would. If you ever visisted a fake-Facebook, you'd immediately notice that something was wrong if the icon suddenly was green with a blue dot in it, for instance.
However, teach users to read domain names! If users do not grasp the general concept, e.g., if the supposed identity is just "example" (possibly with some decoration considered insignificant) and not "example.com", how are they supposed to survive? Domains have been around for more than a quarter of a century, the Internet is actually part of our lives… There is no excuse, and there is no sense in pretending that there was no harm in not understanding the basics. That said, there are real ambiguities that have to be addressed.
FFS, if users cant see that somedomainname.com is different than somedomanname.com how does a randomized image of the domain name based on a hash solve this.
I know of at least one site which users a user selected image in the login screen to thwart phishing attempts. Because its user selected its memorable, I think more so than a password for example. It would be hard for a scammer to spoof as well because they don't know the image the user selected when they created the account.
Unfortunately this would probably be less notable and thus memorable if everyone did it.
Here is the discussion on HN: https://news.ycombinator.com/item?id=17947467
this is essentially what is already implemented in most browsers. You can't mix characters from different scripts in a domain name, except for special cases (e.g. japanese and latin are frequently used together and have little potential for confusion)
The domain name system has been around for decades and it's a clever and proven system. It can – and should be – taught in school and, arguably, knowledge of it is, while not difficult to obtain, essential in our times. Additional ambiguity in this is probably not what we want.
Arguably, the most sincere problems arise from mixed alphabets with Unicode domains and look-alike characters/glyphs. This could be addressed by a) going back to codepages (Unicode subranges) and defining a valid subset for each range, and b) enforcing a domain name (hostname and domain) to be in a single codepage. Clients should derive the codepage by the Unicode range and generate a codepage-identifier, which may be displayed as a badge, identifying the respective range. And, of course, any mixed domains should be regarded illegal and invalid. (We may even want to make this codepage-identifier a mandatory particle of any URI, preceding the hostname.)