chrome Burying the URL

[+Frank B. Subscriber²]

Burying the URL

 

Today, a Canary build of Google Chrome removed something kind of important from the browser: the URL.

 

Of course it still supports them, but the time where users actually see URLs is ending. With Chrome?s ?Enable origin chip in Omnibox? flag, Location becomes a write-only field. Clicking there no longer reveals the URL for the user to edit or share, but instead waits for you to search Google.

 

I realize that URLs are ugly to look at, hard to remember, and a nightmare for security. Still, they are the entire point of the web.

 

Tangled

There was a recent round of debate about what the term ?web? even means, where many people shared a common idea.

 

John Gruber put it so:

 

The web has always been a nebulous concept, but at its center is the idea that everything can be linked.

 

Putting it more directly, Boris Smus said:

 

To me, the critical thing is that content be addressable by URL, and cross-linkable in some reasonable way.

URLs are the essence. They make hypertext hyper. The term ?web? is no accident ? it refers to this explicitly.

 

Unlike other modern technologies that have hidden as much complexity as possible, web browsers have continued to put this technical artifact top center, dots, slashes and all. The noble URL caused a revolution in sharing and publishing.

 

It is also a usability tarpit that directly competes with search.

 

Six years ago, Chrome and Firefox enabled search in the location field. Where previously typing ?ruby? would send you to ruby.com and dump you on the Kay Jewelers site, now it directs you to ruby-lang.org by way of a Google results page. Of course this benefits Google, but it?s also better for users. Usability 1, URLs 0.

 

More recently, browsers started hiding the URL scheme. http:// was no more, as far as most users were concerned. In iOS 7, Mobile Safari went even further and hid everything about the URL except the domain. With the Chrome ?origin chip? change, the URL will move out of the field entirely, to a tidy little button that many users will never even realize is clickable.

 

I suppose burying the URL like this will probably have some usability and security benefits. I know older users intimidated enough by the location bar in its traditional form that they never click it at all. For these same users, maybe this change will finally make clear the security implications of putting their banking information into www.muricabank.biz/bankofamerica.com/securelogin.asp. And of course, it will drive searches.

 

Trading places

As large JavaScript ?single page app? development has become popular, the rallying call has been to not break the web, and make sure these apps still work via URLs. Native apps, meanwhile, have been fairly dismal in terms of linkability, creating silos of content that have no sensical URL. If you agree that the web is about linkability, I?m not sure how you can think the current native app ecosystem is web-like.

 

To this end, Facebook today announced AppLinks, a documented standard for app-to-app linking that has the backing of other big names like Dropbox and Pinterest. While Google is taking the web out of the browser, Facebook is putting the web into apps.

 

Perhaps URLs are just destined to be an implementation detail that the next generation of users won?t even know exists. Maybe I was crazy to think that URLs were a permanent part of our culture. Still, I?ll miss the damn things. Let?s pour one out for the URL.

 

Source: allenpike.com

 

Curious as I am I checked chrome://flags in the current Chrome dev build (36.0.1964.4) and found the following two new flags:

 

 

 

After enabling these Chrome looks like this:

 

I went with the 'hides on click in the Omnibox' setting. To see the URL so you can e.g. copy it to the clipboard you have to click the button on the left.

[Raa]

I remember when they dropped showing http:// on the URL field. Silly idea that one was...

What's next, removing the scroll bars? :laugh:

[duoi Veteran]

I'm glad they removed http://, and was hoping for them to remove www as well. But this seems like a step in the wrong direction and could lead to an increase phishing attacks.

 

What happens if, say, a user has the ability to customize a page in the subfolder of some website? ie the user is given free reign over http://www.example.com/~user/.

 

Based on your screenshot, it appears that Chrome is not displaying that /~user/ subfolder, meaning that the user could set up a fake login page at http://www.example.com/~user/login.php, and deceive people into thinking it is the official login page for http://www.example.com.

 

Websites that often do the above are free hosting websites, as well as university websites.

[+Frank B. Subscriber²]

I'm glad they removed http://, and was hoping for them to remove www as well. But this seems like a step in the wrong direction and could lead to an increase phishing attacks.

 

What happens if, say, a user has the ability to customize a page in the subfolder of some website? ie the user is given free reign over http://www.example.com/~user/.

 

Based on your screenshot, it appears that Chrome is not displaying that /~user/ subfolder, meaning that the user could set up a fake login page at http://www.example.com/~user/login.php, and deceive people into thinking it is the official login page for http://www.example.com.

 

Websites that often do the above are free hosting websites, as well as university websites.

You're making a good point here. You still can see the full URL by clicking the button on the left side of the Omnibox. How many users are going to bother with it though?

 

Part of me is thinking they're still experimenting with this feature, which is why it's hidden in chrome://flags. I'm not too sure whether it's going to make it into the stable channel in this shape and form.

[.stan]

It's just an experiment and as long as I can turn it off, they can experiment all they want :) Also it has been there for months, just some blogger found it yesterday and now it's getting hyped...