Funny thing is that Firefox decided to hide the "http://" when Google decided it must be done, and now the "https://" used mostly everywhere is safe, because there is absolutely no excuse to hiding things that change.
But the real problem is that the web is currently dominated by entities that are interested on obfuscating it. Yes, domain names reading backwards is a really bad decision, but there is no reason to keep composing it by hiding the end of URLs, confusing URLs with search terms, and formatting everything the same.
GUId per domain. No hierarchy. Peer-to-peer sharing. Cryptographically signed user-comprehensible metadata that's resolved through some quorum protocol or stored in a blockchain.
URLs are fine, but the idea that identity of a website is embedded into its "location" is silly. Google owns gmail.com, but Steam/valve doesn't own steam.com. How am I supposed to know that as a user?
Really, the usecases for domain names names have completely changed since the time DNS was conceived.
That mostly solves technical problems, but technical problems are (probably) not what is driving this effort. Is a user supposed to know that d6998147-a7a2-485a-ac5f-74dddebfe070 is legimately Steam, but d69a2b76-96ca-4d7e-b25c-c5a69848e070 is not? Who verifies the metadata for accuracy? Who says you can't register Bank Of America? Those problems, and the other problems like them, are the hard problems, not cryptographically signing the answers to those hard problems. Crypto is easy by comparison.
1. Aliasing/abstraction of IP addresses. Being able to change physical location or server of a service without reconfiguring everything.
2. Mnemonics for getting to a particular server.
3. Indicator that a server belongs to a particular organization or company.
4. Grouping services together so they can share resources (like cookies).
DNS solves all of those problems, but not particularly well.
#1: You need to deal with a lot of BS when all you need is stable identifier.
#2: There is a lot of contention around domain names. Users prefer to use search instead of typing long domains. There is no particular reason why my mnemonics should be the same as for everyone else.
#3: Similar-looking domain names used for phishing. Users don't understand DNS hierarchy. Expiration. Hijacking. A tree structure isn't enough anymore. And so on. This one is particularly bad. Like you said, it's not just a technical problem.
#4: Just look at HTTP security headers and all the iframe issues.
The problem #3 can be solved separately from the rest. The rest are relatively simple technical problems if you consider them in isolation and we could solve them much better than DNS does.
URLs, as defined on the web using http and https, specify the use of DNS, which itself brings in a lot of semantics that are not optional. If you fundamentally change how domains are identified on the web, you're going to fundamentally change how HTTP & HTTPS urls are defined, either by rewriting the current definition or putting a new one on the side.
Since we're probably playing telephone here, at least two steps removed from the source, it's difficult to tell if they actually want to rewrite what "https://" means, or if perhaps they would create a new protocol ("ghttp://") which would define domains differently.
Here's a hyper-quick stab at an example of what that could mean. Imagine a world in which
ghttp:Bank of America: {
"server_namespace":"accounts",
"title":"Account Management",
"subhead":"Account Details"
}
is a legitimate "url" that you could use to link to things. The key here is not in the mere embedding of information, since of course you could translate the literal information contents into a URL no sweat, but that the semantics of ghttp would be redefined to A: change the lookup of "Bank of America" to use Google's home-grown domain-like validation system that is run like the highest-end TLS certificates B: contains a specification of how to render such URLs out in the user agent and C: probably contains all sorts of other exciting things that can go in that JSON blob because why not. Certainly the standard will not be a one-paragraph sketch on HN but run into the hundreds of pages, because that's how these things go.One of the benefits, for instance, might be sold as making it easier to parse the URL with a JSON library than bashing regexes together as we do now, which is incredibly error-prone, speaking as one who has made many errors myself.
Technically, that's still a URL, if you ignore the newlines I added for clarity. It turns out that if you read the standard, there's nothing about URLs containing DNS-based domain names; that's a specific detail of HTTP, HTTPS, FTP, and several other schemes, but not technically a characteristic of a URL in general.
So I would consider it a valid interpretation of the article (which, as I said, is rather vague) to say that what is meant by "redefine URL" is "redefine the set of URLs that user agents are used to using" and that Google may want to create a new protocol scheme.
It's also faintly possible they want to actually redefine "https://" itself, but, while there's technically room to do that in some sense, I don't think it will succeed.
amptp{
culture[en_US];
nice[36];
name[Bank of America];
host[Accounts]
node[/Management/Details];
data{
[view][statement];
[year][2017];
[month][Feb];
[page][2];
[section][debits];
[anchor][`[15`]];
}
}
This roughly translates ashttps: //accounts.bankofamerica.com/Management/Details?view=statement&year=2017&month=Feb&page=2§ion=debits#%5B15%5D
Compacted comparison:
amptp{culture[en_US];nice[36];name[Bank of America];host[Accounts]node[/Management/Details];data{[view][statement];[year][2017];[month][Feb];[page][2];[section][debits];[anchor][`[15`]];}}
Going past that has the tradeoff of requiring more typing which is not going to be well received.
To boil it down to one example, how do you solve the problem of someone setting up secure.citigroup.accountmanagement.com and have an end-user understand that that's a phishing site? I mean, for goodness' sake, authority in the DNS chain is read backwards. How many users are going to read that and see ".com" as the root and technically most important element, rather than "secure"?
I'm not commenting on any possible solution since this article doesn't even sketch one. I'm just trying to apply the principle-of-charity to the article and come up with the most plausible interpretation, and the one most interesting to have a discussion about.
My own commentary is that I'm not sure if there is an answer that's any better than beating on domain names until they work as well as possible. The only other alternative I see is a centralized authority of some sort, and while that is likely to potentially work better than what we have now for maybe about 5 years, the negative consequences after that as the central authority learns to spread its wings and exert control to extract money from people and abuse its authority to push some agenda outweigh the safety.