Regarding the parsing of URLs, this is a common, but mostly counterintuitive argument: Take for example names in most western countries, addresses (street-zip-city-country), etc. Most of our most important identifiers work this way.

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?

Except this is already broken by multi-part TLDs.

foo.com is owned by "foo" foo.evil.com is owned by "evil" foo.co.uk is NOT owned by "co"

The best security change we could make, imo, is rewriting domains so that they look like com.evil.bank.www/now/urls/go/from/most/specific/to/least

You're in good company. Tim Berners-Less said something similar when reflecting on what he would do differently if given the chance:

> 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...

Yes. Think how you have to read "mobile.tasty.noodles.com/italian/fettuccine" to determine where it goes.

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.

I'm not so convinced. There would be still "uk.co.bbc" and "com.bbc" pointing to the same body behind it and any kind of confusion arising from this, like, "is 'ug.co.bbc' the same?" The most important part is teaching users that the identity isn't just "bbc" with some extra decoration. Also, we have the reverse example in software packaging (com/example/disruptiveLibrary) and it isn't fool-proof either (especially, if you only know of "disruptiveLibrary" and not about its origin).

Years ago, before the WWW, some parts of the world indeed ordered them that way.

* https://en.wikipedia.org/wiki/JANET_NRS

I don't see how you could enforce a hostname binding to some real world identity. Hostnames really need to have a non-ambiguous mapping from a name to a computer (more or less), but real world entities don't have that, without using really cumbersome indentifiers. Many natural persons share a name, so how do we decide who gets a hostname based on that; the same is true of corporate persons -- there are many that share names. Even if there was a way to disambiguate these things, it seems unlikely that the entity in charge of this would also want to rub a public registry -- so how do you make that work.

Absolutely. People don't have a single coherent model of identity in the real world. It's hard to glue certs to a pile of sand. Did I buy lunch from "Tim Horton's", from "The TDL Group Corp." or from some random company with an address for a name? The answer is yes to all three, despite only buying one lunch.

On a higher level, all those considerations are about a single question: Is the Web about communication (then it's probably OK as it is), or about a viable business platform with an entry-level as low as it can be?

Who's without interest may throw the first stone, er, browser extension.

Both techniques are deceptively effective; I know the following might be only anecdotally relevant, but it's the most recent case of a successful phishing attack I know of:

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/