
After 19 years, http:// prefix is getting ditched (in Google Chrome) - portman
http://code.google.com/p/chromium/issues/detail?id=40865
======
roder
I agree with the sentiment on the thread that removing <http://> is a UX bug.
Copy & Paste in this case is paramount over UI simplification. Keep it
simple... do not make it a configurable option and do not remove <http://>.

~~~
wyday
I'm using the latest dev release that has this feature implemented. Let me
tell you how it actually works. The location bar looks like this:

    
    
        news.ycombinator.com/item?id=1263512
    

When I select it and press Ctrl-C it copies this to the clipboard:

    
    
        http://news.ycombinator.com/item?id=1263512
    

Nothing is broken.

~~~
Groxx
Useful to know, but I have to agree with portman. What about switching to an
https: URL? Loads of sites default to http when they _should_ be secure.

~~~
nailer
Perhaps it would be better to add a white 'Not identified' badge in the place
where the green Certificate Name (or red broken certificate name) goes?

Clicking it would reveal a message that the site is not identified, and
information being sent to it is viewable to third parties.

Nobody in my immediate family know what <https://> means. They especially have
no idea what its absence means.

~~~
Groxx
_... They especially have no idea what its absence means._

Oh, I wholly agree, this makes sense for the average user. It's just wasted
space to most people. They've already dimmed everything but the domain name (a
_brilliant_ idea in every single way), making the prefix' "cognitive impact"
rather minimal already. To _that_ end, I don't personally see that removing it
is necessary, nor helpful. So at best it maintains the status-quo, and
arguably lowers it slightly.

But, since these decisions are largely made for the majorities, it _does_ make
sense that they're going that route; I'm not really annoyed, I'm just mildly
disagreeing with the decision.

As to the white non-secure flag, I'd _tint_ it slightly yellow so it raises an
eyebrow for people interested in their own privacy; white is too ignorable,
and much harder to see at a glance. On the whole, it's an interesting idea, as
it'd effectively turn the whole http/https battle into a slight-but-real push
to move to https entirely.

~~~
nailer
> As to the white non-secure flag, I'd tint it slightly yellow so it raises an
> eyebrow at people interested in their own privacy; white is too ignorable,
> and much harder to see at a glance. On the whole, it's an interesting idea,
> as it'd effectively turn the whole http/https battle into a slight-but-real
> push to move to https entirely.

Exactly what I'm thinking. Just raise it as info, then change it to a warning
progressively over time, with some advance warning to web developers.

------
adamsmith
I wonder how this will effect spdy://, Google's potential replacement for
HTTP. Maybe it will be good; you can hide spdy:// too and make the difference
transparent to the user.

------
weilawei
I commonly use file:// and other protocols. How will it handle those?

~~~
mbrubeck
Every URI scheme except http: is still displayed.

This includes https: as you can see in the screenshot:
[http://chromium.googlecode.com/issues/attachment?aid=-277348...](http://chromium.googlecode.com/issues/attachment?aid=-2773481718577223512&name=Screen+shot+2010-04-12+at+4.33.14+PM.png&inline=1)

------
lurkerperpetual
Not only the <http://> prefix but the whole idea of URL is a notion that
should not be user-facing in an ideal world. Even the pretty REST ones are the
internet equivalent of the command line voodoo many non-technical users just
don't get and type in or copy paste without knowing what it means. If the URL
is too long only geeks understand its components, let alone edit it in place
to go somewhere else.

It's debugging info for sure, but for most newbies is wasted vertical screen
estate.

Bookmarks and web navigation via links are already hiding the fact that 'you
go to URLs' now, entering a URL in the bar is the corner case because not
everything is easily accessible from everywhere else in very few steps.

In the future the internet will be distributed and content addressable and not
have a certain thing only available at a certain URL you have to remember, and
then the URL will really go away. HTTP is client server, IP networks are peer
to peer by nature.

~~~
rbanffy
In an ideal world, users would look at something they don't understand and
figure it out. Not to a level of mastering all the underlying concepts, but to
the level of becoming functional with it. In an ideal world, we don't feel the
urge to hide something we think the user will not understand. Instead, in an
ideal world, we _teach_ the user. Be it by presenting the subject in ways the
underlying concepts become clear and obvious, be it in showing them
progressive levels of functionality and abstraction. In an ideal world, users
are intelligent, curious and do not feel the urge to run away from things,
they feel, are too complex for them.

It's disturbing when someone advocates the idea of dumbing down what is a
powerful idea in order not to upset those who think they would be upset,
preventing them from learning something useful.

I use URLs for many things, from describing database connections to navigating
hierarchical datasets in data-driven visualization tools. There is a lot to it
beyond HTTP.

The Internet is not a blue "e". It's not a place of consumption, but one of
sharing.

And when it becomes distributed, like you say, URLs could really serve us
well, not by mapping to server:port/folder/document.html but to content and
letting the underlying, non-http protocols, work out what's the best place to
get the resource you need. You say "in the future" but p2p file-sharing
networks use URLs in the form of network://hash-to-what-you-want.

If you assume your users are stupid, not only will you limit you product to
those who know little, but you will rob them the possibility of learning
something.

~~~
lurkerperpetual
By ideal world I meant 'a better internet user experience within the next a
decade or two' not 'all people are intelligent' as you meant. In the latter we
would not be crouching over a browser anyway but do more evolved stuff :)

We do not teach users what an URL is when all she wants is to read her emails,
just as you do not teach them how that browser is written or how the data
travels to and from destination. I share your wish that people would be more
inquisitive and learn but some people are just not like that for various
reasons or do not have time for that and trying to teach them stuff they do
not care about flies in the face of good user experience.

You use URL for many things including DB connections, this makes you a
technical person. One of the reasons user experience is still shit in many
applications is that many techies are convinced the user should be exposed to
all the wonders of the underlying technology and consider this the noble quest
of teaching them.

Yes - network://hash-of-what-you-want is the content addressability I
mentioned. So the 'locator' in URL is not going to be meaningful. You do not
locate a resource, you get some stuff wherever it may be located - assuming it
is in one single place and not built from bits located in various parts.
Anyway it was a tangent to the main topic - even if we denote the content
someway it should not be exposed to your users.

Try asking around your non-tech relatives and see if they understand what the
components of simple web url-s are. My mom sure does not, and I have no
intention of teahcing her that .com is some silly legacy from when it was
thought that if you are a company that is what your webpage address, will be
named like or what is with the slashes or even worse the ampersands.

I do not assume users are stupid, they just don't give a shit about stuff that
is cruft and that has little bearing on what they actually do on the web.

The fact that tiny URLs are such widespread also underlines the fact that URL
is a necessary evil by which you send someone to a resource and not something
to inspect by people. There are complaints about them being opaque but much
less then you'd expect given their massive use.

So do not try to teach people who do not care about learning because they will
not learn and you'll have wasted your time on them.

~~~
rbanffy
> trying to teach them stuff they do not care about flies in the face of good
> user experience

The worry about "user experience" is the cholesterol-rich fast-food of design.
It's terrible, dumbs users down, but, somehow, it's addictive. Imagine a world
of immediate gratification and zero frustration. That's what many people are
tying to build.

> they just don't give a shit about stuff that is cruft

Not everything you don't grasp, or that was decided before you were born, is
cruft.

> The fact that tiny URLs are such widespread

Tiny URLs are a reaction against poorly-designed, overly complex URLs that
convey little or no meaning. Nobody needs Bit.ly to go to
<http://www.google.com>. I'm all in for not failing when a user fails to type
<http://>, but I am completely against hiding it under a magical hood that
will protect users from the dangerous unknown techniques under it.

Knowledge is power and, therefore, it belongs to the people. The better it's
distributed, the better.

------
macrael
MobileSafari hasn't displayed <http://> since its inception.

~~~
frou_dh
Yes it has. I remember the hiding of it being one of the changes in an iPhone
OS update.

~~~
macrael
Alas, then I remember wrong. Regardless Safari has done it for a while. If
someone can find discussion of its removal I'll edit my original post.

~~~
jgranby
[http://daringfireball.net/2008/11/treating_url_protocol_sche...](http://daringfireball.net/2008/11/treating_url_protocol_schemes_as_cruft)

~~~
macrael
I can't seem to edit my post, looks like mobile safari has done this since
2008 for what it is worth.

------
Major_Grooves
Tim Berners-Lee's "one regret" was the addition of the // to web addresses:
[http://bits.blogs.nytimes.com/2009/10/12/the-webs-
inventor-r...](http://bits.blogs.nytimes.com/2009/10/12/the-webs-inventor-
regrets-one-small-thing/)

Just think of the paper we'll save!

~~~
tekhammer
It seems to me that this comment was the driver for this Chrome "feature."

The problem as I see it is that the Chrome devs are fixing it at the wrong
place. Changing one user app, when the standards state it's necessary to
include just breaks things.

They need to change the standard, not the app. Until then, they've just got a
broken implementation.

------
InclinedPlane
I'm surprised there's so much discussion about this topic. This seems a very
straightforward and logical UI improvement.

I suspect commentary on this has become basically a bike shed color argument
at this point.

------
X-Istence
I am still unsure as to whether or not I like this.

One of the first things I do when I get to a page that requires my credit card
information or any kind of username/password login information that can lead
to a compromise of accounts that hold personal information is look at the
address bar for the <https://> in the URL.

~~~
wmf
Chrome still displays <https://>, and these days you should be looking for the
company name anyway. See
[http://chromium.googlecode.com/issues/attachment?aid=-277348...](http://chromium.googlecode.com/issues/attachment?aid=-2773481718577223512&name=Screen+shot+2010-04-12+at+4.33.14+PM.png&inline=1)

~~~
X-Istence
EV certificates don't solve anything besides the fact that now the cert
companies get to charge more for an SSL cert.

Checking for [https://<name](https://<name) of company> means I don't have to
go hunting for where the EV cert sign is posted these days, the URL bar is
still in a uniform location.

------
kingkilr
Ugh, I run chromium nightlys and this change has caught me off guard, I really
don't like it.

~~~
kennu
I have been running the 5.0 dev channel builds for a while and I didn't even
notice this change until I read about it now. I think it's OK. It has been
done in such a way that it never bothers the user.

~~~
kingkilr
Honestly, I thought it was a bug until I saw this thread.

------
Bjoern
This makes absolutely no sense. Why try to fix something which is clearly not
broken?

EDIT: Spelling

------
c00p3r
the 7 of 8 chars in prefix is irrelevant, so, replacing them with an mini-icon
in UI saves space and improves readability.

The better question is - where are all favicons? =)

~~~
blasdel
Favicons only in the tab bar. If you have too many tabs for the window's
width, they stop getting displayed first on the selected tab (making the
progress indicator invisible too) and eventually none of the tabs will have
favicons as they get narrower.

The stupid globe icon they added opens a useless focus-stealing "Page Info"
popup window that's missing most of what should actually be shown in it (like
cookies). They moved the bookmarks star to the right of the address bar to
make room for it.

------
proee
might as well axe out the 'www' while you're at it.

~~~
there
not while there are still stupid websites that don't work without it.

~~~
derefr
So let it be the browser's responsibility to try both with and without it.
They'll either be the same, or one will be nonexistent or a not-found page;
it's not like people put one site at www.x and another at x.

~~~
mbrubeck
You would hope so, but unfortunately you'd be wrong - a tiny fraction of the
time, but still...

