Hash based domain names would be even worse. You have no idea what site is lurking behind some big string of hex digits. You could argue that a person should just compare the hash to some known set of hashes, but that's a. cumbersome and b. unrealistic. If it's done by humans, it's error prone (a malicious site could spoof the first few chars to point to their site), and if it's done by computers, what's the point? You've now effectively created a really shitty replacement for DNS.
Is it impossible to overcome the flaws you pointed out? Is there a way to abstract away the risk from the end user? Are there other applications for this where trust is not an issue? At risk of sounding like an idiot, could some sort of distributed proof-of-work/proof-of-stake protocol alleviate some of the trust problem?
So, you suggest that non english speakers should just "learn it" to use DNS?
Should the Cherokee syllabary be permitted in .us domains? If so, you are still open to homograph spoofing against the Latin character set(e.g. Ꭹ for y or Ꭲ for T). If not, isn't it a trifle rude to declare that writing system "unamerican"?
What about immigrant languages other than English? Why are Latin-charset language users more American than e.g. Hebrew ones like the long-standing and well-known Yiddish population of New York?
You could ban mixing of code ranges in domains. That might help, but how do you sensibly restrict a code range? Turkish is a Latin charset language, but contains a few extra characters that pose a homograph risk. How do you work out whether a domain is Turkish (and allowed to contain ı) or not Turkish? Also, what if you wanted to differentiate the website for your California-based Yiddish-named restaurant from a similarly named competitor in New York?
Should the governments of Morocco and Algeria be empowered to blanket-refuse Tifinagh domain names? What about when Georgia was part of Russia?
I buy 'apple.com' and while if I want to leave it as this, fine. However, I should also have 'apple.com.us' and 'apple.com.ru' so that I can handle these appropriately. It's not perfect, but it at least gives my users a chance to say "hey, I probably prefer (english|russian), so please give me that page."
Of course, this is also a bit lazy and somewhat of a non-solution, as this only addresses the issue for English speakers. A russian speaker using the .ru namespace is already willing to "play by the ascii rules."
People going to 'apple.com' really expect to go to the webpage of the American electronics company. One could assume this by the TLD. Users sending a request to 'apple.рф' would be doing something somewhat strange (user sends english base label, followed by a cyrillic tld). This isn't that absurd though, as english company names become loanwords (at least in russian -- see "xerox" or even ask a russian if he owns a 'yabloko makkniga pro' or an 'apple macbook pro' for example). Should the presence of a non-unicode TLD trigger country-specific mode in browsers for the sake of security? How do we handle loanwords (spoiler to above: russians say 'apple' when referring to the brand, even though it shadows the actual Russian word for apple) with non-ascii TLDs?
It seems that generally a subset of sufficiently distinct characters should mostly suffice. I don't think e.g. Latin, Hebrew and Chinese have much visual overlap.
Well, seeing as that "huge chunk" is a large majority, then the solution isn't "learn english because I'm used to typing URLs _this_ way."
I understand that English is the current lingua franca, but it's aggressive to expect everyone to deal with it just to use the internet.
Why not use our country tlds? It might mean that ICANN has to actually do some work, but I think that the uppermost tld for countries should actually be reserved for suffixes.
apple.us #should have never been sold
apple.com.us #there, none of that scary unicode
apple.com.ru #same unicode problem abound (but at least it addresses the first issue)
Note that you can't just type it in because kto.p? is not the right letters and that last one is obviously not on your keyboard. But cut and paste should work fine.
Using phone number doesn't require you to "learn" Math.
As for the apple site, there are other (better) systems in place for supplying identity information than just the url.
Unicode or not, if you type in apple.com on your English keyboard, you will go to the website of Apple, Inc. (Unless your DNS cache has been poisoned.)
Except in the case of a carefully selected unicode domain, the address bar will say 'www.paypal.com', not 'www.paypallolimstealingyourlogin.com'.