“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.
I was against it, until this pun.
Just like email it is the most basic form of digital communication at the user level. Killing the URL will give browser manufacturers full control of what users can or cannot read. Welcome to the walled wide web
The history seems to repeat itself. Before open web was this popular, there were closed systems, like AOL and Compuserve. They not only had proprietery systems, but there was the “keyword”.
At that time the Internet was marketed similar to an appliance, and most of the population not having prior computer interactions, this seemed like a natural choice.
Then we had a long run of computer literate people who used their desktops for most stuff. At this point almost everyone knew what a URL was.
Now we are back to the point where main interaction with the Internet is thru specialized applications. Mobile ones have no URLs, they just talk directly to cloud services. Web based ones try to hide the URL, and only a few have proper back/fw navigation or bookmarkability.
We still have OSnews and others which have URLs for URI (resource identification). News sites, amazon product pages etc usually fall into this category. Nevertheless there is also a large body of web content where URL no longer works properly.
I’m not sure what the solution is. However at least in the short to middle term I would prefer keeping the URLs as is.
Edited 2018-09-07 02:44 UTC
> Nevertheless there is also a large body of web content where URL no longer works properly.
Indeed. Again this is not a URL problem it’s a CMS or authorship problem. CMS’ got cute and decided to abandon the strict hierarchy model. Ok, then the very least they could have done was generate a permanent and SHORT URL that would refer to that document in perpetuity or at least till the doc was deleted.
The problem we have is programmers are lazy, ignorant, and have no concept of permanence. I’ve talked to way too many who think ‘Google Search site:blah’ is the answer to everything. What percentage of the great unwashed even know that mechanism? 10^-18 probably.
I’d say that while people understand the whole .com part of URLs, there’s difficulty in dealing with the whole slash-this-slash-that part.
Essentially, URLs are hierarchical directory listings. For example, I like the way that Microsoft made the file paths in Windows an interactive breadcrumb list.
Imagine a similar functionality where you could find a section of a website without even touching the actual page. The website could provide some sort of modified site map for the browser to read:
“You are here: [OSNews] > [Stories] > [2018]”
To get to the 2017 list, you just click on [2018] and pick [2017].
Or what about about clicking “[OSNews] > [Search:]” and entering your query at the end?
Just a thought.
The sad thing is, that was envisioned early on and some browsers had a bank of first/prev/up/next/last buttons equivalent to structured document viewers.
The “first”, “last”, “index”, and “up” values for the “rel” attribute are gone in HTML 5, but “prev” and “next” still exist and a well-structured URL gives a natural way to intuit “up”.
https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types
As for search, that’s already there in some form. Visit a site with OpenSearch metadata (eg. a WordPress blog) and then, at a later date, type the domain name into Chrome’s address bar. A “Press [Tab] to search [domain name]” hint will appear on the right end of the address bar.
What you describe is mere navigation inside a website, but if you want to share a certain story from that website with other people or if you want to link to it from another website or bookmark it to review later, you need a way to point to that way to individually point to that story, something like a Uniform Resource Locator (in short URL). It may not have to look exactly like this, but it has to be universal, understood by each and every application.
Gopher FTW!
https://en.wikipedia.org/wiki/Gopher_(protocol)
(I miss it.)
Rather than adding another layer abstraction, couldn’t we fix the one we’ve already got, by phasing out the gibberish URLs?
URL Shortening is a disaster waiting to happen.
When you click on the URL you really have no idea where it is taking you.
You could suddenly find yourself on a Child Pron site and facing time in jail just for visiting it.
I know that this is a small risk but I refuse to take it.
I do not and will not ever click on a shortened URL.
No, it isn’t. It’s already happened, and disasters have struck from shortened URLs since it first started. All because a stupid social networking service (Twitter, I’m looking at you) wanted to keep things under 140 characters so it would be SMS compatible, which didn’t matter because nobody wanted to use the service that way anyway. Now we’re stuck with the fallout from that idiotic decision.
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.
So you see exactly zero problem with monstrosities like this:
https://www.amazon.com/Rosewill-1000Mbps-Ethernet-supported-RC-411v3…
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:
https://www.amazon.com/Rosewill-1000Mbps-Ethernet-supported-RC-411v3…
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:
http://example.com/wiki/Title
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.
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.
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 http://www.amazon.com/producs/product#
Even with giving human information, it doesn’t need to be that long in the first example. As I said, all the stuff in the query string, as well as the ‘ref=’ part right before it, is unnecessary to just display the product page.
The really ridiculous thing though is that what’s in the URL for the product name is shortened. The full product name on Amazon is ‘Rosewill 10/100/1000Mbps Gigabit PCI Express, PCIE Network Adapter/Network Card/Ethernet Card, Win10 supported (RC-411v3)’. And that’s a result of a completely separate issue with how Amazon’s search functionality works, namely that matches in the product name get prioritized over matches in the description, so pumping your product name for the listing full of keywords makes it more likely you’ll get a top spot in the search results (and it worked in this case, the exact search query was ‘pci express network card’).
The irony of all this is that the auto-conversion of URL’s to links done by OSNews made it much harder to clearly see what I’m talking about here, since it cuts off both URL’s before the point where they differ.
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
Hey…an 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 ???
The resistance to change in computing is natural, we are bombarded with changes made for the change sake, so people became circumspect.
Pretty much this.
Where many people wanting to change something fail is by not understanding the reason it is that way in the first place.
Take email. Some people hate the way email is designed. But expose all the problems it has to solve, and suddenly you find out that you’d end up with something similarly complex.
The “because it has always been done that way” is a first line of defense when you don’t understand something, and see that there is more to it than meets the eye.
Serafean,
However, because SMTP standard predates UTF-8 and expects 7bit ASCII, they had to find a way to “hack it in” by adding new lexical preprocessor that simultaneously adds complexity and removes clarity. This is just one of many quirks that caught me off guard when I was writing scripts to parse emails. So can you honestly say email’s complexity is intrinsic? No, I don’t think so, it’s the consequence of hammering new features into an old protocol while maintaining backwards compatibility. We can’t ignore backwards compatibility, but the truth of the matter is that email is far more complex and security is less effective as a result.
Edited 2018-09-07 14:47 UTC
Agreed, but the OP also makes a valid point. Yes, if we redesigned email right now, we could eliminate much of the complexity we see while meeting today’s requirements. But that word, today, is the key. Decades down the line as we are with email right now, you would find a similar hodgepodge of complexity as new requirements that were not foreseen at the start come to be necessary. After all, email started out simple, too.
darknexus,
And it’s true complexity does arise over time, yet a big difference between now and then is that when SMTP was published by a man in 1982, there was very little experience in digital mail systems, certainly not on a wide scale. Not only do we have tons more knowledge and experience today, but email is also more mature.
Taking the unicode example again:
ASCII, or the “American Standard Code for Information Interchange” had shortcomings with internationalization. This was bound to cause problems later on. Are there similar assumptions that unicode authors will have failed to consider for the next several decades? Perhaps, but due to maturity and hindsight I do think it’s fair to say that unicode is more future-proof than ASCII was. In a similar vein, I think there are things we could do with email that would help with long term stability. But of course the big problem is actually moving the world to that point without breaking compatibility with existing legacy software.
Edited 2018-09-08 01:01 UTC
> Here’s an email header I got from a recent purchase:
No, the problem is not unicode or utf-8 support or lack thereof. The problem is the RETARD who thought it was a good idea to put non-plain-text in the Subject of an email or anywhere in the body!
YOU DON”T DO THAT! Period. People who are too stupid to understand plain text is the ONLY correct way to do things do not belong in the chain of decision-making or programming.
If you want to get “fancy” then embed a link to a silly web page with pointless checkmark graphics and other such crap. Email body is not a web page. If you are sending out HTML in an email body you need to be shot.
It because people (marketing, artsy fartsy, young programmers with no concept of history) VIOLATE the rules that you have this problem with phishing and JS tricks to lie about the actual link in the “click me” emails.
URLs are just fine. That people cut/paste with the entirety of the query string still attached just shows they are STUPID. It’s the same deal with people complaining about a wrapped line breaking a URL and they can’t figure out how to put the pieces back together again.
Much software has been written to coddle stupid people by deliberately hiding all the “ugly” underpinnings. Not only does it deprive the ignorant of an opportunity to learn, it DIRECTLY leads to the success of phishing and related problems. When you’re doing something wrong, you STOP and UNDO the mess you created, not propose some different technology or “smarter” defense.
Its 2018… UTF8 is plain text.
UTF-8 is NOT remotely plain text. Are you telling me you can understand this as written?
\x6d\x79\x20\x6d\x6f\x74\x68\x65\x72\x20\x28\x77\x65\x6e \x74\x29\x20\x74\x6f\x20\x40\x6d\x61\x72\x6b\x65\x74\x21
Plain text means 7-bit ascii at most and is frequently reduced further to be the set of “printable characters”.
If someone wants to be stupid and send non-plain text in email then they are required to multi-part/mime it. That they put crap in the Subject header means they are dumber still.
How anglocentric of you.
RTFn RFC!
We (anglocentric) invented the Internet. We defined the term ‘plain text’. That other cultures use other languages which can’t be expressed in 7-bit ASCII is too damn bad. Use the methods expressly crafted to enable support of Unicode/UTF-8/JIS etc.
If you don’t use the correct and proper way to encode/encapsulate your datastream, the problem is YOU.
Edited 2018-09-07 19:36 UTC
Hm, the earlier French Cyclades network was very influential on the design of Internet. And World Wide Web was invented on French-Swiss border (with the part of the building where it was invented on the French side
)
No, because that isn’t UTF-8, that is a bunch of unnecessary escape sequences that don’t serve any purpose. I can understand “my mother (went) to @market!” though just fine, why didn’t you just type that? That is UTF-8 plain text, there is no need to escape it, because this website (and just about any piece of modern software) understands it just fine.
Best part is you could have typed “Τη γλώσσα μου Îδωσαν ελληνική” or “СтоÑл он, дум великих полн” or “ಬಾ ಇಲà³à²²à²¿ ಸಂà²à²µà²¿à²¸à³ ಇಂದೆನà³à²¨ ಹೃದಯದಲಿ” and if I spoke those languages I would have understood them too – and you don’t need to escape them, because they are plain text.
What you call “plain text” is what Unicode was created to fix. 128 characters is a bug, not a feature. Every character on this website is UTF-8… Are you telling me you can’t understand it?
Edited 2018-09-08 00:14 UTC
So I can’t write the names of my family members in an e-mail? You really want to go down that route?
> So I can’t write the names of my family members in an e-mail?
Nope! Declare the body of your email as a multi-part with mime and charset per the RFC and you’ll be fine.
But if you think the SMTP transport layer has any obligation to accommodate you doing it WRONG, or your email client to auto-magically deduce there’s some Unicode in the body and “help you out” you’re naive.
Follow the specification or reap the consequences.
I seemed to have misinterpreted your previous quote, then. I mostly agree with you, but I do believe the subject and other fields should support all characters in some form or fashion.
shogun56,
Congrats, I completely didn’t anticipate this sort of response. Instead of responding to your point though, I’m going to sit back and let others do that while I watch the show. Also, welcome to osnews
Edited 2018-09-08 01:16 UTC
LOL
I’m not against changes that make things more clear and easily understandable. Maybe Google will come up with something brilliant. It’s just that I’m jaded. Often “improvements” are of the kind that hides the ugliness behind a pretty curtain and the main problem still exists, but now neither average users nor experts have a clear view on what is happening.
The biggest problem with “modern” URLs is the 600+ character garbage after the first slash delimiting the domain. That garbage is machine readable and URLs weren’t made for machines. URLs were made for humans. It should be recognisable between every slash.
What’s kinda funny here is that Google is guilty of such URLs themselves, in search results and the ones you get sent to after clicking an ad…
Edited 2018-09-08 01:38 UTC
Yet another opportunity for a large for-profit organization to “filter” the raw information so we can see what they want us to see.
URLs (as originally designed) are human readable.
Google (and other culprits, ie PHP creators) have been f–king up the guidelines in their own benefit.
And now Google wants to, what, to “kill the URL”? Sorry, but no. You f–ked up your Search Engine with crappy refers, fix it, and leave the original URLs alive.
(Of course, with the exception by Berners Lee of killing off the “http://“ and maybe transform it into “web:”)
Edited 2018-09-07 07:33 UTC
I’d agree with that. I find a lot of my URLs need fixing to remove https://…ampproject.com from the start of them. I love the fact that they provide zero indication of what they perceive the current issues to be or what the replacement might look like. Reminds me of how certain email clients improve they interface by showing the sender name rather than the email address.
Two of the original, fundamental aims. Readability, Memorability.
Two histories: Actual and a brand new, more to the original philosophy.
My Guess:
Your site/My access-level request/My user-name/..
Followed by my own naming, mapping, indexing, etc.
Zero-level, anonymous access present Standard Persistent Name Location Mapping, and We need only:
Your site/
Every personalized tour should present also this Standard Mapping in machine and human readable form, for the navigator to use it as resource and for the user to share.
Every resource, object and query to have a link to a true, site-wide URL.
Even land slides, rivers change course, but Coordinates doesn’t DISAPPEAR. That’s the purpose of persistence. Nihl, is not right at a situational universe like the WWW.
If 3 years ago I bought that sofa, need access to that same info, at exactly the same URL, even if a big red bar at top saying “archive”.
That’s human. We are so.
That is the definition of laziness…not human.
“laziness…not human.”
Excuse Me?
That’s the reason of URLs, to begin with. Maybe you’re being -ironic. < /:) >
Edited 2018-09-07 19:17 UTC
“We want to challenge how URLs should be displayed” is very different from “Google wants to kill the URL”.
Want to display the URL in a different way? Fine. Want to write a title that has nothing to do with the article? Not fine.
Its an effort at abstraction. Per se, nothing wrong.
On it being hegemonic, we are at the same hole here, that a few decades ago, with Microsoft’s “active” pages:
Innocent in principle, profoundly damaging to the protocolary nature of the WWW.
I would rather not have huge corporations use their power to impose standards on us.
Especially laughable is that Google talks about protecting our privacy while they themselves are doing everything in their power to compromise our privacy.
I guess they want to protect our privacy against OTHER entities who would compromise it, so that they are the only ones with our private information.
Nothing in computing is Ever industry-wide, someone always wins and others are forced to follow.
The modern browser was basically led by Netscape and consolidated by Microsoft. How a user interacts with a browser today is basically the same as back in the 90s.
If google make the switch, they are gambling the bank on it. If consumers switch, they will lead the way people connect with internet for the next 25 years unopposed. However, that inherent inertia of users could also mean they move to more familiar systems like edge, leaving Chrome as the modern BOB
That’s a self contradiction. If someone is capable of winning, and the others are forced to follow, they are, by definition, industry wide.
On the Web, no one wins. There are two defacto standards bodies in the W3C and IETF, and they don’t even stand behind any of their own standards because at the end of the day they are merely recommendations or request for comments.
We need to find something to use these things for, other than crypto currencies
Technologies seem to have a path from created to replace something that’s too complex, become slowly more complex over time, to finally being replaced by something simpler. Rinse and repeat.
HTTP/2 with encryption, binary etc all makes sense in terms of better performance and security – yet – yet – try just writing a simple page with a text editor and hit reload on the browser reading from the file system – you can’t – something precious has also been lost.
Same goes for URL’s – just yesterday I told somebody – hey you can just add #t=1m30s to the youtube URL to get it to start at a specific point. Without URL’s the ‘hackability’ of the web goes significantly down.
Low barriers to entry for engaging with a technology is key to long term tech viability.
What current guru’s forget is that while it’s just a another small step for them, they are gradually pulling up the ladder for new developers which are the future.
These new developers then decide to reinvent instead of struggle to get on the first run and the whole process repeats.
Hackability – low barrier to entry – is a key feature that Google seems to be forgetting – too many gurus perhaps.
I’m wary of Google deciding this for everyone, but the alternative of having some industry committee decide is worse: what you end up with is a decision that is 10 years in the making, formed as a compromise between the financial interests of the companies that have paid to be on the committee, and which will be adopted with all he alacrity of 1pv6.
And you Know IT.
Deprecation is almost complete. Dedicated to all the Hippies that started your little Company. Now Monstrous Leviathan.
</Irony>
End the Works on persistence, redundancy, indexing, mapping. Instead of toying with hegemonic moves.
Edited 2018-09-07 15:40 UTC
3 of them easily solved with old, trustful P2P, but -alas, no “competitive” advantage.
Go and spread your virus on your own WEB.
As 1+1 = 2, URL is a convention.
If tomorrow I log on a site, like OSNEWS, and I got just an icon green to tell me it is the good one trusted OSNEWS site…. Ho, and I am trusted also by OSNEWS…
I am okay with it. Just one condition :
It must be an international convention !
All actors in the Internet must accept and follow the new norm.
And I don’t care if technically URL has been replaced by a SAML protocol with a third party trusting service. Until… Every actors respect the norms (sales, conditions, privacy, environmental norms, etc).
Ironic question : Does Chrome’s team has contacted W3C to talk about it ?
File Systems where created at hyerarchical Coms, for hyerarchically organized users. If You where no allowed to Know where a resource was residing, or what his name or alias was, thats was it, end of matter.
Spirit at CERN was exactly the opposite.
Departments wanted, needed tho share, open their research and allow others to build over it. The deeper research becomes, the more respected and trusted.
That’s how Science works.
File Systems of the time were mainly hyerarchical also.
Tim broke that. CERN at the time had the power to do that.
Of late, data brokers -Leviathans want a come back to the old Status Quo. Money pressure is beyond imagination.
Battle is already lost if -as usual- Users dont give a damn.
https://www.theguardian.com/technology/2018/sep/08/decentralisation-…
You can not build over foundations you cant touch. For this to work, digital rights has to be made the other front.
The issue is highly political:
Think of a water hole in dry season: Crocodriles digg dipper, lions and hienas round it day and mainly at night. Thats scarcity management. That’s capitalism abbreviated.
On differing from water, there is no reason info couldn’t be multiplied at infinitum.
The war is for you to use Their Wells, and no others.
That’s Why chains of trust are vital to any new efforts in this path.
The Shared Data could be digitized, but no, chains of trust are not going to be digital.
Edited 2018-09-09 14:33 UTC