It seems to me that what they want to get rid of is URL display in the omnibar as identification of the current page, preferring to relegate it got being a machine locator and not the primary exposed content identifier.
I'd imagine you'd still keep a UI for extracting a sharing the locator unless whatever friendly identifier was adopted also came with a reliable and widely supported way of recovering the corresponding URL.
We build websites for small business, many biz owners:
- Do not know what or where the "address bar" is.
- To visit their website, they will "google" (the verb) their website address (or biz name) - which leads to newly launched website owners thinking their website isn't accessible/online.
Chrome and other browsers combining the address bar with the search box has only made this situation worse.
I hear you, except in reality there are plenty of places a new business might expect users to navigate to their website from, e.g. their URL could be listed in a common proprietary platform such as Yelp or Twitter, and it could also be in a marketing email or even a business card. Hopefully new generations will understand what a URL is, and perhaps some informative campaigns could keep the public aware. We learned how to describe directions around a cute town on a piece of paper when I was in the 2nd grade, so why shouldn't elementary schools teach basic internet essentials to kids at some fairly early grade level?
If they're on AdWords, they could be paying dollars-not-cents every time they google themselves and click on the first (paid) link. Just because they're happy to pay the racketeers when a customer does that, doesn't mean they should pay the racketeers even more because of their own poor understanding of browser use.
I'm talking about 20 minutes to several hours after launch.
Also, many won't "google" their website address, but instead their business name. For a newly launched website, many national business directory listings (manta, angies list etc.) will outrank the official site for quite some time.
I've seen a lot of this in business space and it is ridiculous. Business users should be trained/expected to know how to properly use browsers similarly how they are trained/expected to know how to use Word and Excel. This includes a reasonable understanding of URLs.
The web is everywhere. It's time to accept that web literacy is necessary for working in an office. This includes things like working with tabs, creating bookmarks and using in-page search.
Agreed, while I dont think everyone needs to be a car mechanic, the idea that we need to simplify and hide every component of the web is actively harmful.
Indeed. People usually spend 30+ hours operating a vehicle under supervision just to learn the basics of steering and moving around, before being allowed on public roads. And they don't think much of that, it's normal. Expecting a couple minutes of learning what is an "address" and where is the "address bar" isn't too much to ask.
My side of the phone call (sometimes multiple times with the same customer):
What do you mean "the site isn't coming up"?
OK, I'll take a look right now... yep, it loads just fine.
Can't find it? Just type the domain name in to the address bar...
No, that's the search bar, I mean, you can use that, but it's only been a couple of days and [search engine] probably hasn't indexed it yet.
OK, if you want to look at it right now, then type the name of your website into the text field at the very top.
What do you mean it still isn't coming up? It loaded fine for me.
...It's not in the list of links... OK, that's still [search engine] results. How about this, type the name of your site, plus the dot com, and nothing else. Got it?
What would "adjust your expectations" look like exactly? While these clients are the minority, it happens often enough that I'd like to find a solution.
You forgot the part where you have to e-mail them the link, so they can click on it--or cut-and-paste it, if they have a sysadmin who got sick of cleaning up after the execs get phished or spearphished.
Have you tried only guiding them through keystrokes? Like Ctrl+L-y-o-u-r-d-o-m-a-i-n-Dot-c-o-m-Enter?
Back in my tech support days, I found that it is surprising how often you get to the thing you need if you dictate things like Win+R "ncpa.cpl" this way instead of relying a non-techie user to find the next icon to look for.
A part might also be that the other side switches into "this is arcane magic, I have no clue and have to make sure I follow the directions properly" mode...
Maybe instead we can have little badges called "Googs" that'll direct you to the AMP version of a website. Obviously, you'll need to pay the Google for this privilege. They'll make the design open source, but since their browser and Firefox will only support the official "Googs" implementation, oss versions will be dead from the start.
Letting a commercial company define a breaking web standard change won't have any repercussions whatsoever.
Whatever Google comes up with I'm pretty confident that I will disagree heavily with. URLs is fantastic, solves the problem well and basically has little to no issues. There is no need to fix something that is not broken.
Thanks, but could you please stop trying to control the web Google?
It does make sense to me to at least change the pattern to something like protocol://com/domain/subdomain/subdistinction/specificresource and standardize the way these interact with all the parts of the web.
I don't think it makes sense. Most languages read left to right. The thing I'm most concerned with is what specific site I'm on. If I'm on facebook.com, the most important thing to me is "facebook", not "com". So it seems natural to me for that to be on the left.
The problem is that facebook.com.google-safe-pages.verizonmobile.evil-site.cn also displays the ‘facebook’ portion leftmost.
Also, due to the way DNS works you really are trusting ICANN, then the com registrar, then facebook (CAs add an overlay, but then CAs like Let’s Encrypt ultimately trust … DNS). Making that explicit would probably be a good thing (and might even be a first step towards a rootless, decentralised future).
It's not about getting rid of URLs, it's about not displaying them to most users. From the Wired article Ars probably based their writeup on (Ars links it):
"People have a really hard time understanding URLs," says Adrienne Porter Felt, Chrome's engineering manager. "They’re hard to read, it’s hard to know which part of them is supposed to be trusted, and in general I don’t think URLs are working as a good way to convey site identity. So we want to move toward a place where web identity is understandable by everyone—they know who they’re talking to when they’re using a website and they can reason about whether they can trust them. But this will mean big changes in how and when Chrome displays URLs. We want to challenge how URLs should be displayed and question it as we’re figuring out the right way to convey identity."
> It's not about getting rid of URLs, it's about not displaying them to most users.
And one of their incentives in doing so is that Google is an alternative to URLs. Already many users Google ‘facebook’ and click on the first link rather than just typing ‘facebook.com’ (or ‘face’ TAB ENTER).
Although I don’t believe I saw it in the article, it’s in Google’s interest to mediate all access to the Internet for consumers — this isn’t fundamentally different from Facebook’s VPN. It’s not in users’ interest, of course.
If they cared about security they could do something like display the domain & the path separately, maybe on different lines (with maybe colour used to distinguish HTTPs vice HTTP):
> If they cared about security they could do something like display the domain & the path separately
They've tried experiments but it's not as easy as it might seem at first thought. Consider what happens with someone setting up a hostname like bankofamerica.secureuserportal.com or www.gmail.personaluserinbox.biz – a fair number of people will look at the left part rather than reading from the right so even displaying it separately won't help, especially if they don't have a huge window with tons of room and all they see is the first part of "www.bankofamerica.comsecurecardholderservices.ru".
Only displaying the domain name will help with that problem but it has usability issues for any company which handles user data under subdomains since it'd be harder to tell user1.example.com from user2.example.com if there's any possibility of spoofing.
Agreed. Google's ubiquity coupled with the proposed change to Chrome threatens to morph a user's experience of the open Internet into something akin to AOL and its keyword feature. That puts the Internet back fifteen or more years.
People searching 'facebook.com' on google seems like a user education problem to me.
In fact, if I was Google (and I was less scrupulous), that's the kind of behavior I would encourage: train users to type destinations into Google, serve up the results using AMP, obfuscate the whole thing by eliminating URLs, then users will just stay in Google's ecosystem and never leave.
There needs to be some way for a user to be able to see something either online or, for example, out on a vendor's stall selling soap or honey, and go to it on their browser. The only thing I can imagine that's simpler than that is a QR code, but it requires you to have a phone that has a good camera, which isn't possible in some places that are developing because a phone is kind of expensive, whereas a URL just requires a pen and paper. A simple URL can be remembered without writing it down, like "blog.google".
I will be surprised if URLs go away completely in the next 50+ years, but a new way to verify the identity of the website will probably be developed, if it's necessary.
Sorry, but that is just such a bullshit quote. They want to have control on identity and that's it. URL as the article say stands for Uniform Resource Locators and is about locating resources, not proving identity.
They are trying to solve an issue which isn't even part of the responsibility of the URL. The domain is the truthteller here. If you can find a way to display to the user what actual domain he or she is on,you have solved the issue.
Yes, that's why I characterized it as "not displaying them to most users". They aren't proposing getting rid of URLs or changing how they are used in retrieving pages or etc., they just might stop showing them to users because people mostly don't get much information from them.
But the issue is that many also get much information from them. It's like removing info about air pressure in your car tires because "most people don't understand it".
I don't understand why we should view computer illiteracy as something we must cater to. You don't have to know everything about how URL works, but being able to change ?page=1 to ?page=2 and knowing what is probably going to happen and similar tasks is knowledge probably needed today and should be teached.
Why does people never learn this? If you teach people to be uneducated this is exactly what they will become.
> URLs is fantastic, solves the problem well and basically has little to no issues.
I strongly disagree. I do tend to think that they're useful and not obviously replaceable, but claiming they have no issues is dubious.
Spoofing, with or without the added level of sophisticated enabled by unicode. Special character handling (e.g. whitespace) is sometimes problematic. URL longevity is a real issue. Server-side security has been compromised in the past using "../" in URLs.
I'm sure I could come up with more, and I imagine there's a "top 10 fallacies programmers believe about URLs" list out there that would provide more examples.
URLs are useless for normal people, normal people don't know what URLs are. They don't have the time for learning what it means. If they want to access a website they will Google for it and click on the first result and don't look at the address bar. As a consequence of that they are easy phishing targets, just setup a domain that looks more or less legit and you're good.
Unfortunately the easy solution to that seems to be more walled gardens. I'm pretty sure we'll start seeing Google-certified websites. Registering your website with the Google Search Console will start to become mandatory to appear in the top results. Or implement AMP.
So I'm with you but I think it's important to understand that URLs are broken for most people. When you see a perfectly legible piece of text, their brain is automatically blurring it like some piece of flesh in a Japanese Hentai.
>URLs are useless for normal people, normal people don't know what URLs are.
This is a truism, but I'm not certain it's true. Is there actual data to back this up? What definition of "normal" is being used here.. the average person using the internet, or non-technically trained people?
The web has been around for decades now, and everyone including my nearly 70 year old mother uses it, and URLs have been pretty ubiquitous for a long time. Not knowing what a URL is seems about as likely as not knowing what a TV channel is, or that they have a bank account number.
It seems more likely to me that normal people do know what they are, but find avoiding them to be more convenient than using them.
Do we really need to change the url system? What if we make it super-easy to register a TLD?
What if there is an alternative system to verify that a website is owned by someone? For example, what if the icon needs to be registered with some kind of trademark-like entity, and the browsers made the icon more prominent?
That's for second/third-level domains (depending on the scheme of the TLD they're under). To run a TLD you have to apply to ICANN and provide evidence that you will actually be able to run the registry.
Given Google hasn't laid out any particular solution and they're still being criticized, it seems to me that HN is so cynical of large tech companies exercising their monopoly power (because of past practices) that they're afraid of any effort to rethink the fundamentals of the web.
Which on one level makes sense. It's good to protect things that have made the web great. However, it's also good to maintain a spirit of innovation and willingness to question those things that people assume has to work a certain way just because it's always worked that way.
When there's a specific proposal, and if that proposal is a bad one, attack it on the merits. But there are real problems of security and user friendliness when it comes to URLs and I don't see anybody else working on it. Does anybody really think that it's impossible to improve and the way we do things now is exactly the way we should be doing it 100 years from now?
It sounds to me like this is more of a problem with the domain system, and the way it embeds into a URL, than a problem with URLs as a whole. Browsers have already largely hacked off the protocol in the front, and even Google couldn't get rid of the path & querystring (though we can continue to work towards hiding more of it from the average user if that is desirable), so it seems likely this is all about the domain, and the difficulty of mapping what domains really mean to what end users think it means.
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.
Designing a browser to flag high risk domains seems to be a fairly easy though not cheap problem to solve. It's also separate from changing how URL's are defined.
"It's also separate from changing how URL's are defined."
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.
I don't like single quotes and double quotes as delimiters, as the start character and end character are not distinguishable, and can't be matched or nested. But I do like the backtick ('`') as an escape character. In general, I like being able to type as much as possible without using the shift key.
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`]];}}
It seems that some recent versions of Chrome are even hacking off the "www." from many URLs. Initially very confusing when I was testing some redirection the other day...
Well, browsers are trying to fix this with graphical clues. Right now, all parts of the url apart from ".ycombinator.com" are grey in my url bar.(using Firefox)
>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.
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.
"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."
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 Ａmerica? 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.
The problem with DNS is that it mixes a lot of almost unrelated problems together. Here are some things domain names solve:
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.
> Browsers have already largely hacked off the protocol in the front
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.
Maybe go back to lists and hierarchies of lists like the old days. With `UUID` behind it. Lists are at least navigatable.
So every URL would be part of at least one list and `URLs` point to lists. Or something like that.
Example: Sites-I-Use List can be shown in the address-bar instead of the url as green while a site I never used before can be shown as red. That’s not even taking organization into account, or all the other myriad of useful usecases.
This is one of the things that definitely can be improved on. Having something either in the URL or in page metadata to say "this is linkable". This doesn't warrant a replacement, however.
I'm not sure URLs have any major downsides. The full complexity is beyond most people but most people don't need to understand anything more than how to type www.something.com, it is the web application owner who has to understand them and where most security problems live. Security is only a problem if the server or web application have not been setup correctly.
It's no different than visiting a shop or a house where you should be able to expect certain regulations to be met (insurance, building codes etc) and I can see more countries starting to enforce country-wide codes for web sites, annual checks, registrations, whatever for people to be allowed to trade in that country.
It's a bit disingenuous ars technica ledes with a screenshot of a homograph attack that Chrome mitigated in March 2017, and really doesn't relate to the article. https://www.xudongz.com/blog/2017/idn-phishing/
Welp, time to be afraid then. Google does not wait to find a replacement when they don't like something. They destroy first, and then never get around to coming up with anything to replace it. So get ready to embrace a future with no address bar and with Google search being the only way to find and navigate to pages. Just look at what they did with vertical side tabs in Chrome for a perfect example. Google said they "didn't like how it looked" and "wanted to find a better solution" so, despite the option being a hidden setting you had to dig to even find and enable, they ripped it out of the browser. And to this day, years later, there is no solution at all to having lots of tabs open. The browser just rapidly fills the bar with tabs, shrinking them to utter uselessness.
But at least Google doesn't have to tolerate something they find aesthetically displeasing.
It makes a lot of sense to me to redesign how we display URLs. Right now, we show them as a singular identifier, where the only thing we can tell the user is to search for things inside that string of characters (look for https, or look for bankname.com). We don't need to show the whole string of characters.
It seems very sensible to me to take the URL for what it is and communicate that back to the user:
- The protocol doesn't matter much to most people, except the implications it has, so maybe show "encrypted" or "not encrypted" (and fallback to protocol name for FTP and the like, most people won't ever touch that without knowing what it is)
- The domain is interesting: there's the TLD, which doesn't _really_ matter, and the second level name, which matters a lot. Subdomains matter less. How about we show it as a much more prominent "[ domain.com ]" with a less obvious subdomain.
- Paths are pretty generic all around: incrementally deeper descriptors separated by forward slashes. Could definitely show that as a breadcrumbs-style thing (might also make people care more about readable paths, which is nice).
- The query string should probably be shown as "tags" with a key and value, since that's what they are.
- The hash is a bit icky, but it might be enough to highlight that you're linking to a place in the page.
The “World Wide Web” was based on only three concepts. A document markup language, an document “universal resource location” (URL), and a tool that could use the URL to retrieve the document and render the markup.
Breaking/obfuscating/demoting the URL is so fundamental I am shocked it would even be suggested.
I'm a bit late to the party here, and the following doesn't address a lot of the concerns in the article (nor does it actually get rid of URLs), but for anyone interested in alternatives to horribly long URLs or incredibly opaque URL shorteners I made a fun little tool [0].
It's called ShortestSearch and in essence could be looked at as a reverse Google in that you give Google search terms and it gives you a list of websites, but for ShortestSearch you give it a website and it gives you a list of search terms. All with the aim to perfect the art of "It should be the first result if you Google 'x y z' ".
Also found the part of the article where it describes its own URL strangely enjoyable.
82 comments
[ 3.0 ms ] story [ 152 ms ] threadSounds like Google is becoming a bully ;p. They shouldn't reset standards of World Wide Web.
I'd imagine you'd still keep a UI for extracting a sharing the locator unless whatever friendly identifier was adopted also came with a reliable and widely supported way of recovering the corresponding URL.
- Do not know what or where the "address bar" is.
- To visit their website, they will "google" (the verb) their website address (or biz name) - which leads to newly launched website owners thinking their website isn't accessible/online.
Chrome and other browsers combining the address bar with the search box has only made this situation worse.
I mean, practically, if it doesn't turn up when searched for, it _isn't_ accessible to 99% of the world.
Also, many won't "google" their website address, but instead their business name. For a newly launched website, many national business directory listings (manta, angies list etc.) will outrank the official site for quite some time.
The web is everywhere. It's time to accept that web literacy is necessary for working in an office. This includes things like working with tabs, creating bookmarks and using in-page search.
What do you mean "the site isn't coming up"?
OK, I'll take a look right now... yep, it loads just fine.
Can't find it? Just type the domain name in to the address bar...
No, that's the search bar, I mean, you can use that, but it's only been a couple of days and [search engine] probably hasn't indexed it yet.
OK, if you want to look at it right now, then type the name of your website into the text field at the very top.
What do you mean it still isn't coming up? It loaded fine for me.
...It's not in the list of links... OK, that's still [search engine] results. How about this, type the name of your site, plus the dot com, and nothing else. Got it?
OK, now press enter.
Tada!
Also, this is a story of success. Sometimes it ends with "trust me, your site is up, just give it time".
Back in my tech support days, I found that it is surprising how often you get to the thing you need if you dictate things like Win+R "ncpa.cpl" this way instead of relying a non-techie user to find the next icon to look for.
A part might also be that the other side switches into "this is arcane magic, I have no clue and have to make sure I follow the directions properly" mode...
Letting a commercial company define a breaking web standard change won't have any repercussions whatsoever.
Thanks, but could you please stop trying to control the web Google?
The arrogance coming off of this company is unreal at times.
Also, due to the way DNS works you really are trusting ICANN, then the com registrar, then facebook (CAs add an overlay, but then CAs like Let’s Encrypt ultimately trust … DNS). Making that explicit would probably be a good thing (and might even be a first step towards a rootless, decentralised future).
"People have a really hard time understanding URLs," says Adrienne Porter Felt, Chrome's engineering manager. "They’re hard to read, it’s hard to know which part of them is supposed to be trusted, and in general I don’t think URLs are working as a good way to convey site identity. So we want to move toward a place where web identity is understandable by everyone—they know who they’re talking to when they’re using a website and they can reason about whether they can trust them. But this will mean big changes in how and when Chrome displays URLs. We want to challenge how URLs should be displayed and question it as we’re figuring out the right way to convey identity."
And one of their incentives in doing so is that Google is an alternative to URLs. Already many users Google ‘facebook’ and click on the first link rather than just typing ‘facebook.com’ (or ‘face’ TAB ENTER).
Although I don’t believe I saw it in the article, it’s in Google’s interest to mediate all access to the Internet for consumers — this isn’t fundamentally different from Facebook’s VPN. It’s not in users’ interest, of course.
If they cared about security they could do something like display the domain & the path separately, maybe on different lines (with maybe colour used to distinguish HTTPs vice HTTP):
They've tried experiments but it's not as easy as it might seem at first thought. Consider what happens with someone setting up a hostname like bankofamerica.secureuserportal.com or www.gmail.personaluserinbox.biz – a fair number of people will look at the left part rather than reading from the right so even displaying it separately won't help, especially if they don't have a huge window with tons of room and all they see is the first part of "www.bankofamerica.comsecurecardholderservices.ru".
Only displaying the domain name will help with that problem but it has usability issues for any company which handles user data under subdomains since it'd be harder to tell user1.example.com from user2.example.com if there's any possibility of spoofing.
In fact, if I was Google (and I was less scrupulous), that's the kind of behavior I would encourage: train users to type destinations into Google, serve up the results using AMP, obfuscate the whole thing by eliminating URLs, then users will just stay in Google's ecosystem and never leave.
I will be surprised if URLs go away completely in the next 50+ years, but a new way to verify the identity of the website will probably be developed, if it's necessary.
They are trying to solve an issue which isn't even part of the responsibility of the URL. The domain is the truthteller here. If you can find a way to display to the user what actual domain he or she is on,you have solved the issue.
I don't understand why we should view computer illiteracy as something we must cater to. You don't have to know everything about how URL works, but being able to change ?page=1 to ?page=2 and knowing what is probably going to happen and similar tasks is knowledge probably needed today and should be teached.
Why does people never learn this? If you teach people to be uneducated this is exactly what they will become.
I strongly disagree. I do tend to think that they're useful and not obviously replaceable, but claiming they have no issues is dubious.
Spoofing, with or without the added level of sophisticated enabled by unicode. Special character handling (e.g. whitespace) is sometimes problematic. URL longevity is a real issue. Server-side security has been compromised in the past using "../" in URLs.
I'm sure I could come up with more, and I imagine there's a "top 10 fallacies programmers believe about URLs" list out there that would provide more examples.
punycode, similar-domain name squatting, SSRF/ generally parsing urls properly, parsing uniformly
probably 100 others but this was just off the top of my head. Some of these they intend to deal with, some they do not.
Unfortunately the easy solution to that seems to be more walled gardens. I'm pretty sure we'll start seeing Google-certified websites. Registering your website with the Google Search Console will start to become mandatory to appear in the top results. Or implement AMP.
So I'm with you but I think it's important to understand that URLs are broken for most people. When you see a perfectly legible piece of text, their brain is automatically blurring it like some piece of flesh in a Japanese Hentai.
This is a truism, but I'm not certain it's true. Is there actual data to back this up? What definition of "normal" is being used here.. the average person using the internet, or non-technically trained people?
The web has been around for decades now, and everyone including my nearly 70 year old mother uses it, and URLs have been pretty ubiquitous for a long time. Not knowing what a URL is seems about as likely as not knowing what a TV channel is, or that they have a bank account number.
It seems more likely to me that normal people do know what they are, but find avoiding them to be more convenient than using them.
What if there is an alternative system to verify that a website is owned by someone? For example, what if the icon needs to be registered with some kind of trademark-like entity, and the browsers made the icon more prominent?
Using it is more difficult.
Why would making that easy be a good thing, though? Seems like it would just lead to tld squatting and poor performance .
Which on one level makes sense. It's good to protect things that have made the web great. However, it's also good to maintain a spirit of innovation and willingness to question those things that people assume has to work a certain way just because it's always worked that way.
When there's a specific proposal, and if that proposal is a bad one, attack it on the merits. But there are real problems of security and user friendliness when it comes to URLs and I don't see anybody else working on it. Does anybody really think that it's impossible to improve and the way we do things now is exactly the way we should be doing it 100 years from now?
we'll need a protocol. and a port. and a host. and then a resource on that host. and to combine them together.
how about:
foo.html\80:net.host\\:http
totally cool!
https://news.ycombinator.com/item?id=17920720 https://www.polemicdigital.com/google-amp-go-to-hell/
There's a great comment about the link between these two over there:
https://news.ycombinator.com/item?id=17923156
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.
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
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.
Going past that has the tradeoff of requiring more typing which is not going to be well received.
https: //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`]];}}
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 Ａmerica? 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.
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.
Maybe go back to lists and hierarchies of lists like the old days. With `UUID` behind it. Lists are at least navigatable.
So every URL would be part of at least one list and `URLs` point to lists. Or something like that.
Example: Sites-I-Use List can be shown in the address-bar instead of the url as green while a site I never used before can be shown as red. That’s not even taking organization into account, or all the other myriad of useful usecases.
Anyway how often have you used URLs list-like?! And how often have you used Google(which offers List by Search)?
This is one of the things that definitely can be improved on. Having something either in the URL or in page metadata to say "this is linkable". This doesn't warrant a replacement, however.
(ref to Real Names, for those not old enough to remember)
It's no different than visiting a shop or a house where you should be able to expect certain regulations to be met (insurance, building codes etc) and I can see more countries starting to enforce country-wide codes for web sites, annual checks, registrations, whatever for people to be allowed to trade in that country.
But at least Google doesn't have to tolerate something they find aesthetically displeasing.
It seems very sensible to me to take the URL for what it is and communicate that back to the user:
- The protocol doesn't matter much to most people, except the implications it has, so maybe show "encrypted" or "not encrypted" (and fallback to protocol name for FTP and the like, most people won't ever touch that without knowing what it is)
- The domain is interesting: there's the TLD, which doesn't _really_ matter, and the second level name, which matters a lot. Subdomains matter less. How about we show it as a much more prominent "[ domain.com ]" with a less obvious subdomain.
- Paths are pretty generic all around: incrementally deeper descriptors separated by forward slashes. Could definitely show that as a breadcrumbs-style thing (might also make people care more about readable paths, which is nice).
- The query string should probably be shown as "tags" with a key and value, since that's what they are.
- The hash is a bit icky, but it might be enough to highlight that you're linking to a place in the page.
Could be displayed as something like this: https://i.imgur.com/RfJoP23.png
Breaking/obfuscating/demoting the URL is so fundamental I am shocked it would even be suggested.
The route could be displayed less prominently to the right.
Preserve normal omnibar behavior for input.
It's called ShortestSearch and in essence could be looked at as a reverse Google in that you give Google search terms and it gives you a list of websites, but for ShortestSearch you give it a website and it gives you a list of search terms. All with the aim to perfect the art of "It should be the first result if you Google 'x y z' ".
Also found the part of the article where it describes its own URL strangely enjoyable.
[0] https://oisinmoran.com/ShortestSearch/