Linked by Thom Holwerda on Thu 6th Sep 2018 23:34 UTC

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

Judging by the reactions across the web to this news, I'm going to have the minority opinion by saying that I'm actually a proponent of looking at what's wrong with the status quo so we can try to improve it. Computing is actually an incredibly conservative industry, and far too often the reaction to "can we do this better?" is "no, because it's always been that way".

That being said, I'm not a fan of such an undertaking in this specific case being done by a for-profit, closed entity such as Google. I know the Chromium project is open source, but it's effectively a Google project and what they decide goes - an important effort such as modernizing the URL scheme should be an industry-wide effort.

Thread beginning with comment 662053
To read all comments associated with this story, please click here.
speedy -> http/2
by jimmystewpot on Fri 7th Sep 2018 05:23 UTC
Member since:

while I don't personally see any problem with URL's and I suspect that many of the problems with URL's are from generations that it won't matter for.. i.e. if young people don't understand or find the URL difficult then that's a failure in the education system/family unit as opposed to a technical problem. Trying to solve social problems with technology is all the flavor at the moment.. when really we could be solving much more pressing issues.

I have some level of confidence with Google on this project given the "success" they have had with Speedy/HTTP2 compared to some of the other "standards" that have been superseeded by these standards.

Reply Score: -1

RE: speedy -> http/2
by ahferroin7 on Fri 7th Sep 2018 13:03 in reply to "speedy -> http/2"
ahferroin7 Member since:

So you see exactly zero problem with monstrosities like this:

That's an Amazon product page URL for a link in the search results. It's functionally identical for most purposes to this direct link to the product page for the same thing:

Which while not perfect, is at least readable and something that could be typed by hand without significant fear of mistyping it.

The only practical difference between the two is that the first one pre-loads the search box with the search query you used to find the item in question in the first place, yet the first one is indisputably less readable than the second one, just to provide a feature most people don't actually need.

The big problem here is not a lack of education. Even though I can tell you what most of those parameters in the query string mean, that doesn't make the first URL any more readable for me than it is to someone who has near zero background in computers. The issue here is that sites are overloading the URL to do a lot more than it really needs to. It should not be referencing information from the previous page (that's what the 'Referer' header and/or cookies are for), It should not be embedding huge amounts of information that are not going to be used by actual users, etc.

For an example of things done sanely, take a look at how MediaWiki uses the URL. All the pages on a MediaWiki wiki can be accessed directly with a URL of the form:

Where 'Title' is the title of the page (possibly with a few modifications to make sure it's valid for a URL). From there, you can get direct links to sections by just adding a fragment with the name of the section. No need for query strings, no special magic numbers, just the exact titles of the page and section you want to go to. It's simple enough that even people who have essentially zero background with computers can understand it. If the rest of the internet handled things like that, there would be no need for what Google is trying to do here.

Reply Parent Score: 5

RE[2]: speedy -> http/2
by kwan_e on Fri 7th Sep 2018 13:14 in reply to "RE: speedy -> http/2"
kwan_e Member since:

It should not be referencing information from the previous page (that's what the 'Referer' header and/or cookies are for), It should not be embedding huge amounts of information that are not going to be used by actual users, etc.

It's part cargo-cult programming/designing, and part this:

"Many websites log referrers as part of their attempt to track their users. Most web log analysis software can process this information. Because referrer information can violate privacy, some web browsers allow the user to disable the sending of referrer information.[7] Some proxy and firewall software will also filter out referrer information, to avoid leaking the location of non-public websites. This can, in turn, cause problems: some web servers block parts of their website to web browsers that do not send the right referrer information, in an attempt to prevent deep linking or unauthorised use of images (bandwidth theft). Some proxy software has the ability to give the top-level address of the target website as the referrer, which usually prevents these problems while still not divulging the user's last-visited website.

Many blogs publish referrer information in order to link back to people who are linking to them, and hence broaden the conversation. This has led, in turn, to the rise of referrer spam: the sending of fake referrer information in order to popularize the spammer's website. "

As far as I know, browsers, firewalls and proxies aren't so free to chop off or change bits of a URL they don't like. So if a website really wants to track you, they are forced to do this.

Reply Parent Score: 4

RE[2]: speedy -> http/2
by bn-7bc on Fri 7th Sep 2018 15:57 in reply to "RE: speedy -> http/2"
bn-7bc Member since:

Wow that has got to be the most verbouse product name in histoey what us wrong with «Rosewill 10/100/1000Mbps PCIE Ethernet NIC», and just put any other info in the description/specs. But i get your point urls tend to becone long very quicly but that might just be a result of amazon to have their urls give human readable information. The url could just have been

Reply Parent Score: 2

RE[2]: speedy -> http/2
by dionicio on Fri 7th Sep 2018 16:06 in reply to "RE: speedy -> http/2"
dionicio Member since:

Your 2nd Exmpl. is an URL, ahferroin7.

Your 1st Exmpl. is a Non-Uniform Negotiating "Commit".

If Well Remembering, Microsoft -and lot others- handle DB sessions through persistence. What we see at the navigation bar is just for our "tranquility".

Not even right to use the Navigation History at such places, You could crash or turn to a room whose doors already "expired". Even the room could "expire" a minute after you left. Created to the interest of that particular "your punctual reality".

When There, We are not in the WWW, anymore. Isn't so, Tim?

Edited 2018-09-07 16:12 UTC

Reply Parent Score: 1

RE[2]: speedy -> http/2
by dbox2005 on Fri 7th Sep 2018 18:09 in reply to "RE: speedy -> http/2"
dbox2005 Member since:
2017-11-22 URL can also be dinamically generated. You cannot change that. I would actually prefer to be able to still dig into sites hidden pages or content by manually changing the URL address myself. Why do you want to take that from me ???

Reply Parent Score: 1