
Chrome's experiment of hiding the URL is great for security - jaffathecake
http://jakearchibald.com/2014/improving-the-url-bar/
======
justinschuh
As a member of the Chrome security team and one of the original instigators
for this experiment, yes the whole point is to prevent phishing. The fact is
that phishing is one of the most common attack vectors for most people, and
the way the URL is currently displayed does very little to protect them. So,
we're experimenting with ways of displaying the essential information (origin
and TLS state) as clearly as possible, while removing the components that are
not security relevant and are currently being abused to trick users.

No one has any intention of diminishing usability or making it hard manipulate
URLS. The team working on this is still actively refining things and studying
what works and what doesn't. But, phishing is a very big problem, and this
change to the omnibox shows real promise in countering the attacks. So, I
think we would be remiss in not pursuing the investigation further.

~~~
altcognito
So phishers buy domains with a levenshtein distance of 1 or two. It solves one
problem, but creates an entire class of users that don't understand what a URL
is. Who benefits? Google and search engine providers because now they can
manipulate future internet users to believe that search engines _are_ the
internet. We've reverted to AOL in 1995.

There is nothing more that can be productively argued about this topic. There
will be analogies about how complexity is hidden in various domains (cars,
computers) and how beneficial it has been and how users are happy with it.
Those arguments are fine and maybe they are being made in good faith, but it
doesn't change the underlying future truth:

Marketing will now be changed to reflect Google keywords, not URLs. "www." and
".com" will become meaningless. Google will have put one more level of
distance between what the users type in the URL and even what they click in
the browser and what is reflected in the address bar.

~~~
pbz
Well, if www and .com become meaningless then advertisers will use "type xxx
yyy into you bar" instead (which goes to the search engine) or hash tags
(already doing this). Then Google could come up with "associate permanent
keywords with your URL" (for a small fee of course) to guarantee that those
keywords won't shift under you when your Google ranking changes.

~~~
ojii
I already see this happening in Japan. Rarely do I see ads include URLs, they
have a search term.

~~~
johncoltrane
Which IMO is a smart idea. URLs are too often hard to remember and/or type
correctly if not too long anyway.

~~~
cpeterso
Until a competitor's SEO outranks your site for those keywords or buys similar
Google AdWords.

~~~
johncoltrane
Those keywords are not supposed to live long: they are used as part of
marketing campaigns. But your comment is still valid. Such a strategy would be
very risky in the long term.

------
edanm
There are a number of people in this thread posting things like "the average
user should be educated" and "why break things for us technically savvy people
just to please people who can't be bothered to read a whole url".

I really con't stand this behavior. Not everybody, not even most people, want
to understand "how to web works", "how urls work" or anything else along those
lines. _Insisting_ that people are somehow wrong to not want to understand
this is just ridiculous - as ridiculous as if I had said "we're not going to
let anyone drive a car unless they know how to tune an engine" or some such.

I for one am _very happy_ that the creators of automobiles have bothered to
make the process so simple, even a moron at automobiles like me can drive in
car and have it work 99.9% of the time, and the rest of the time - it's clear
I need to take it to an expert.

We as the software developers, product designers and UX experts of the world
should stop trying to tell the world what it _should and shouldn 't_ care
about, but rather, use that as input to decide _how to build our software so
actual people can use it_.

Do I love this Chrome experiment? I don't know. But I know that I'm willing to
trade a few seconds of discomfort of my own, which can probably be stopped by
tweaking one configuration setting, in order to save the majority of the
population who _aren 't_ tech savvy from the problems of phishing and just
generally giving them a better user experience.

~~~
pdkl95
> Not everybody, not even most people, want to understand "how to web works",
> "how urls work" or anything else along those lines.

There are also a surprising number of people that don't want to be _literate_.
In the modern world, we have generally regarded such views as _wrong_. Basic
literacy is such an important skill to have, we have even created various
mandates to provide the necessary education to all children.

Technology has simply added a handful of additional details. Nobody is
suggesting that every has to learn all the subtleties of URLs or read RFC
1738. Much like tuning the engine in a car, these are technical details safely
left to experts.

Anybody who wishes to participate in this new, technology-filled world (i.e.
~"everybody") will need to make a few minor additions to their skill-set[1].
One of these is to know what a URL _is_ , in concept, and be able to
differentiate between the host-part and the path-part. Being able to parse the
path/query-string is not necessary. The necessary skill is being able to
recognize that "example.com/foo/bar/baz" is more specific than "example.com",
or being able to guess that "example.com/2014/04/18/the-great-quux" is
probably a specific article posted last month.

This skill is important to have _to participate in the modern world_ , not
just to use a "web browser". You see URLs everywhere. Many print ads now have
a URL in them, for example. This is the new literacy, _de facto_.

[1] Other skills might include understanding that text shaped similar to
"foo@example.com" is probably an email address, how to use a mouse, and what
terms such as "password" or "login" mean.

~~~
edanm
That's a really great point, thank you.

My only possible objection is to observe that clearly some things are
important/necessary to teach, others aren't, and all we're arguing about is
which of these URL's fall into. Nobody here is (currently) arguing against
such basic things as login's and passwords, or that "foo@example.com" should
obviously to everyone be an email.

The reason I think URL's are over the line is because everything after the
domain name is _usually_ an implementation detail. Some sites will have
"id=234234234", some sites will have complicated paths, some sites will have
nice, readable URL's, and a large part of the difference is the specific
framework or approach that the Web Devs decided to use. Do you really think
it's important for people to understand the decisions behind this? That's over
the line IMO.

Also, another knock against URL's being required is that, _de facto_ , people
don't understand URL's and seem to use the web just fine. That's because us
selfless developers have been working hard to abstract away the issue from
users. I think most users _don 't_ understand URL's, and this doesn't bother
them in the least until you get to issues like phishing attacks. So all Chrome
would be doing is _recognizing an existing situation_ , and helping make it
better.

Lastly, I'd like to point out that even the easy examples you mention, e.g.
passwords, are something that most users _don 't really understand_, and for
exactly that reason, developers have been trying to get rid of passwords for
many years. And IMO, one of the big benefits of Facebook is that it makes the
"send a message to someone" game _much easier than email_ for real users, so
that's a knock against email.

I really _don 't_ think that understanding URL's is akin to being basically
literate. I think the bar is much lower, and that we as developers forget just
how much specialized knowledge we already know, and how much the average user
_already has_ in order to use a computer these days.

That said, it's a great analogy so thanks for bringing it up!

~~~
userbinator
> _de facto_ , people don't understand URL's

Here is evidence that shows a lot of "average users" do have some
understanding of what URLs are, and even if not the technical details, then at
least the concept (which is definitely more important than the details):

[https://news.ycombinator.com/item?id=7678729](https://news.ycombinator.com/item?id=7678729)

------
DanielBMarkham
I think we are confusing the fact that phishing takes place with the purpose
of the web.

Even if 80% of the time I was trying to be phished, I'd still want the URL.
Why? Because the URL is my ownership of the web. It's my address book. It's
what domain owners pay to have. It's the roads that connect one spot to
another.

So sure, phishing is a problem. Figure out some way around it that doesn't
involve Google locking up the entire internet behind a UI element somewhere.
Mobile phones is one thing -- my main browser is another.

I don't doubt there is a problem. I seriously question the ethics of actors
that use the existence of a problem as a reason to exert further control over
my e-commerce activities. If it looks wrong, even if most people probably
don't care, it _is_ wrong. This isn't hard stuff, guys.

I'm also already getting impatient with the seemingly endless parade of folks
who are ready to play defense for Google. If Google thinks this is a good
idea, let them defend it on their own.

~~~
altcognito
Many people in this thread will confuse a clean interface with convenience and
sloppy conclusions for protection.

~~~
DanielBMarkham
Agreed.

Sorry for the cranky post today, but this purposefully (in my mind) obfuscates
the issue. Clean UIs are awesome. Taking away the friction between my wanting
to go somewhere on the net and getting there? Also awesome. Effectively
killing the idea of the URL and giving yet more control to Google for my
movement around the web? A disaster.

------
zdw
I don't get the benefit to cutting off the rest of the protocol handler and
path. It may be noisy and not useful to the average user, but it's useful for
people who know what they're looking at.

An alternative would be highlight the domain portion of the URL in the
appropriate color, ala source code highlighting. This would accomplish both
goals nicely.

~~~
justinschuh
Chrome has been highlighting the origin component and de-emphasizing the path
since its initial release, but the fact is that the vast majority of users are
still very unclear about the security relevance of origin and easily fall
victim to phishing attacks. So, the team that's working on this is
intentionally investigating larger departures from the current URL display.
Accepting that, what you see right now is an incomplete experiment, and no one
involved would be happy with the result if it damaged the utility of URLs or
made Chrome less useful for web developers.

~~~
chr1
chrome keeps both domain and subdomain black, which makes this kind of
phishing easy. Firefox have a better approach of keeping black only the main
part, and graying out everything else. Yet better solution would be to
highlight domain with green color instead of [https://](https://), and to
scroll urls with very long subdomain to make domain viible.

I rather liked how this[1] firefox addon added a bubble around domain, but
kept url as selectable text.

[1] [https://addons.mozilla.org/en-US/firefox/addon/smart-
text/](https://addons.mozilla.org/en-US/firefox/addon/smart-text/)

~~~
leoc
An approach like greying out the path would be a good idea if it were in any
way desirable for the path to be user-visible by default, but it isn't.

------
artursapek
I don't understand all the resistance to this. It's doing the work that
currently all non-programmer users of the web (the vast majority) have to do
themselves every time they look at a URL - parse out the meaning.

For example, when my wife is checking our credit card charges, she isn't using
"[https://online.americanexpress.com"](https://online.americanexpress.com").
She's using "Amex's website". That's how she would tell me what she's doing;
that's how she thinks about it. She doesn't give a damn what the URL is, and
that's why phishing works in the first place.

This new UI simply reflects how most people think about the web.

Everyone on HN who has been arguing against this is missing a huge point:
_this isn 't for you_. We still do everything in our terminals for Christ's
sake. Nobody has taken that away from us. Nobody is going to take URLs away
either. But just like the terminal application they will be shuffled away into
a "utilities" drawer where you have to look for them because they were
designed for machines, not people. Those of us who work with machines can
still have them.

I can't wait for this to ship.

~~~
mnutt
I got it about a week and a half ago in Canary, and I stuck with it for about
a week until it was disabled. I didn't like the idea but I'm interested in new
UI experiments.

I hated it. Not only for the reasons other people mention (it makes copying
and pasting cognitively more difficult, and even after a week it didn't really
get any easier) but also because I would argue that on sites with halfway-
decent URLs, it's a navigation device. We already lost the title bar, and
apparently the URL bar was acting as secondary indicator of what page I'm on.
It was really, really disorienting.

I do wonder whether Google only planned to display the feature for a week, or
if it got feedback from my navigation habits and disabled it. And what, if
any, indicators they're using to measure success. (or at least non-failure)

~~~
artursapek
> but also because I would argue that on sites with halfway-decent URLs, it's
> a navigation device

I agree, but I will argue that websites that suddenly seem disorienting
without a URL are poorly designed. If we take away the crutch they will have
to stop relying on it and improve.

------
rdl
I hate this behavior in iOS 7 Safari so much. Whenever I want to modify the
URL, it's a huge pain (on HN specific links, usually) -- there's no way to
edit the parameters at the end of a URL (that I've found), and typing the
whole long url on a phone or tablet isn't fun (especially when it includes
lots of parameters, rather than just a simple path). It's one of the few
things an alternate browser on iOS actually fixes.

~~~
itsravi
In Safari, you can tap the address bar and hold down on the url to bring up
the pointer and scroll over to whatever you want to edit/copy. It's the same
behavior in Chrome on iOS7 (apart from the fact that the pointer is at the
beginning of the URL in Safari and in the end in Chrome, which albeit, is
preferable).

~~~
rdl
Ah! I didn't realize you could hold down and scroll left/right. Thanks!

------
aviraldg
While I agree that this will be great for security, with changes like this I
always wonder: what happens when we idiot-proof and hide implementation
details of almost all consumer products? How does the next generation of
hackers pop a path into a URL and learn about path traversal attacks, or code
into query params and learn about XSS when we've hidden all that away from
them? There's some value to that, too.

For me, that was exactly how I got interested in software development, first
learnt about application security attacks, and even some scripting languages.
I'm not sure any of that would've happened as well, or at all if my first
device was a locked-down iPad (which it frequently is, for kids these days.)

~~~
ardemue
Maybe that's the regular path of any technology. At first most of the
community is small and technical so you don't need (and don't have the means
anyway) to idiotproof. Then it grows and eventually there are more casual
users than technical ones. Since the technology is more stable you have more
ressources that you can dedicate to figuring out how your casual users use the
technology. And since they have no interest in understanding how it works, you
idiotproof.

The beauty of it is that it regulates the number of potential technical users.
At first, your technology needs a lot of technical users, and since it's not
idiotproofed yet, and users are exposed to low level details, you attract a
lot of them. But then, low level details are progressively hidden, and only
the users that have a strong interest will become technical. Essentially
filtering out the users that don't have a strong enough interest to dive
deeper than what they're exposed to.

Maybe the internet doesn't need as much technical users as before. So yes,
there will be less kids getting interested in its technical side, but that's
okay because it doesn't need them.

------
spindritf
_I followed the link, entered my username and was about to enter my password._

This is the problem demanding a real solution, not some cosmetic change around
the URL. Your browser should be entering the credentials.

The computer is not fooled by an ugly URL. If the domain doesn't match, no
password for you. If the protocol is different from the one you used the first
time (https hopefully), no password for you.

Yet instead, we get autocomplete="off" and a butchered URL bar.

~~~
runn1ng
I don't understand why do banks often have autocomplete=off. (At least my bank
does.) What is the reasoning?

Luckily, LastPass ignores that.

~~~
boobsbr
to prevent login and password from being automatically filled, so someone
using your OS user or browser user can't login to your bank account.

~~~
runn1ng
True. I actually forgot people let other people use their computers. (And I
really mean it, I just didn't realize it.)

------
eknkc
A native breadcrumbs display might be a great addition to this.

I mean, show the domain first, and show a subsection that the website
provides, so I can click on that to navigate. If I click on the domain name,
provide a standard url input field.

Google already does that with search results:
[http://d.ekin.io/bOdk](http://d.ekin.io/bOdk)

~~~
jaffathecake
That'd be great. But so few URLs are breadcrumbable, in fact, I should fix
this on my own site,
[http://jakearchibald.com/2014/](http://jakearchibald.com/2014/) is a 404.

~~~
eknkc
Using URL itself as a source would not work most of the time I guess, or would
require assistance from Google servers.

In any case, I believe breadcrumbs should be parsed from the page html:
[https://support.google.com/webmasters/answer/185417?hl=en](https://support.google.com/webmasters/answer/185417?hl=en)

~~~
Excavator
Some years back there was a proposal on one of the Mozilla blogs to use
breadcrumbs when a sitemap¹ is available. I think that's a bit more reliable
and would solve the 404 issue.

1:
[http://en.wikipedia.org/wiki/Sitemaps](http://en.wikipedia.org/wiki/Sitemaps)

------
jalfresi
Phishing is an attack vector promoted by email. Email clients should not
create automatic hyperlinks from email content and email senders should not be
providing links in the body of the email.

This is entirely a problem that should not be solved by breaking the web. This
is basically an attempt by Google to insert itself between the primary
connecting mechanism of the web and should be rejected wholesale.

The URL contains everything the user needs to determine the origin of the web
site they are visiting. This doesn't provide users tools to ensure their
safety only the illusion of safety.

------
aw3c2
So I will register "benefltaccess.com" as "Morgan Staniey". Would the people
who fall for phishing actually notice? I think removing URLs just feeds into
Google's "door to the internet" monopoly and really dislike it. People should
rather be educated about how websites actually work.

~~~
acdha
> So I will register "benefltaccess.com" as "Morgan Staniey".

Have you actually tried doing this? Getting an EV certificate with the
business name involves actual checks, not just having registered a domain.

------
Jugurtha
I don't like it. I like control, and this hides stuff from me.

It's basically telling you: "You don't need to see this, kid. We got it".

~~~
hugi
That's the point. And for most users that's great.

~~~
sergiosgc
No it's not. URLs enable users to link to content. People blog, email, post to
Facebook, do all kinds of linking. And no, it's not always using the
FB/Twitter buttons. They do know that a url is an address and what an address
is for.

If you tell me the url is still accessible, you are contradicting yourself.

------
MzHN
As the article states, this is likely good for the non-tech-savvy people, but
what it needs is a button to copy the URL as easily.

If the problem is misleading subdomains, would some kind of a detection and a
warning be a better solution to the problem?

~~~
eknkc
Did not try it, but apparently if you click on the domain label, it provides a
standard url field so you can copy / modify the url.

~~~
Springtime
In this case I'd be more open to the idea, although having some advanced
preference to disable it if needed would be helpful, should it become the
default.

------
monochr
Surely I can't be the only one here who has dealt with actual flesh and blood
average users?

This would do nothing form them. It requires that you pay attention to the
tab, which most don't do, read where they are, again something the majority
don't do, and be savvy enough to realize that "site.com" is now different to
"[https://www.site.com/somthing$%else/and&&a+lot_of[]crud"](https://www.site.com/somthing$%else/and&&a+lot_of\[\]crud")
something that I doubt 1 in 100 will figure out.

Unless it's in red, has a klaxon attached to it and flashes enough to give you
a seizure either the majority or a very large minority of your users will
ignore it.

------
adventured
Couldn't the browser easily slice off the domain and display that in a non-
editable field somewhere to the left or right of the url? Seems like an easy
solution, while not hiding the url.

------
suprgeek
The path to hell is paved with good intentions.

Hide URL to make phishing harder -> URL is no longer understood by anybody
->Keyword based navigation->GoogAOL->Keyword based phising

~~~
Terr_
Ahh, but keyword-based phishing is _profitable_ to the people who own the
association-engine...

------
eridius
Trying to prevent phishing, and hiding the URL such that you only see it with
an explicit action, are two separate things. The first makes sense, but it by
no means requires the second. iOS is a perfect example. Everyone talking about
this says how iOS 7 does the same thing. Except _it doesn 't_. You cannot
interact with the URL bar, say, to search for something else, without first
making the URL visible. And that's fine. But this Chrome experiment doesn't do
that. It makes it so you can trivially search without ever seeing a URL. And
that's the part I disagree with.

If you want to experiment with making phishing obvious, you can play with much
more obvious separations between domain and path. I see no reason why you
can't use the same origin chip that's being experimented with now, but simply
show the rest of the URL in the field next to the origin chip. You could even
hide the URL until the user interacts with the bar, the same way iOS 7 does,
except I don't think there's any good reason to do that (that's hiding
potentially-useful information with no benefit [assuming that the visual
distinction between domain and path is large enough, such as it is with this
new origin chip]).

------
dbg31415
What a shock, first post on here is, "Let's do this for security reasons..."
#PatriotAct #TSA #IraqWar #NSA

Sure sure, it's not the same thing... but it is. Why don't we just educate
people to use a password manager (LastPass prevents this shit), or maybe learn
to read the URL bar.

Let's not go back to 1995 AOL please. URLs are good things.

------
NaNaN
I need an option to disable this feature (for web developers), or show me the
path after the host:port at least.

------
taeric
Here I was expecting numbers. The cynic in me doesn't think this will really
have any impact at all.

------
leoc
People want to find a way to continue showing the path portion of the URL, but
this is really undesirable. The URL's path should contain no information,
beyond its role in making up the unique identifier of course; it's a virtual
guarantee of link-breakage in the future
[https://news.ycombinator.com/reply?id=7679423](https://news.ycombinator.com/reply?id=7679423)
. Making it invisible will help to ensure that people stop putting information
in it. User-friendly document names and tree-structured site guides are all
well and good; they just don't belong in the URL. The query string, on the
other hand, should probably remain visible.

------
leephillips
I was a little surprised by this. I bet most people here refrain from clicking
in urls in emails, and would instead enter the company's url themselves in the
browser, and follow the path to renew the domain or whatever needed to be
done. If I _do_ follow a url in an email like this, I at least look at the
email headers, or actually look at the url first. I'm not saying I'm immune
from any possible phishing attack, but these defensive behaviors have become
just a reflex by now, and I guess I assumed that anyone with this kind of
knowledge and experience shared these reflexes.

------
Nux
While I agree the URL for the "normal" users is just meaningless ballast, I
don't understand how this is great for security.

So what, now "normal user" Joe will still input his Paypal's user and
password, because the web page clearly displays a very nice PayPal logo and
has the same look&feel as the original page. What is to be gained?!

I feel like it is just an attempt to dumb it down and put even more power in
Google's hands, transforming [http://](http://) into google://

No, thank you.

------
gweinberg
It seems to me that the entire benefit to this scheme could better be achieved
by say bolding the domain part of the url, or perhaps displaying it in a
different color.

------
lurchpop
This has a nice "accidental" benefit to Google where users handle URLs less
often and lean even more heavily on search to locate things on the Internet.

------
snarfy
Apparently the less you know, the more secure you are. Fishing is a problem
with the web, not the browser. Please quit trying to fix it with the browser.

------
dep_b
The cynic inside me thinks that this is just a step to remove those pesky open
URLs from the user and gradually push something propietary Google to replace
it in the future. Google now controls about all search queries done on the web
but does not control people going directly to a URL yet. That's what a big
firm's marketing department would describe as a place to realize growth.

------
userbinator
"It's great for security, therefore we should do it."

One of the most secure places to live in is a prison. Is that really the
direction we want software to go in? I can't help but be reminded of that
infamous quote: "Those who give up freedom for security deserve neither."

As for this hiding of the URL, I'm not so convinced it'll help the situation
any better. From the article itself: "To the average user, the URL is noise."
In other words, if you assume that they already can't understand URLs/aren't
bothering to, then what's to say they'd be able to notice the difference
between a real URL and a phishing URL in those examples? To this average user,
one is shorter, the other is a bit little longer. "The page looks real, that
bunch of stuff up there I don't normally pay attention to anyway, so I
wouldn't mind if it changed length." The one with the EV cert vs regular HTTPS
is more obvious to me too since it's a different colour, but once again if you
"assume illiteracy", anything could happen.

The other aspect of this is that it's only protecting "cross-domain" phishing;
this is probably the majority of cases, but consider the situation where the
real login page is at somehost.com/site1 while someone is trying to phish and
creates another account at somehost.com/site2 . Now hiding the path to
"prevent phishing" has the completely opposite effect! You could argue that
this is an edge case, but it still seems to be an awfully discriminatory
practice to me; I personally have password-protected accounts on various
servers where the login is located at somehost.com/~myusername , and a
phisherman with somehost.com/~otheruser could do this quite easily with hidden
URL paths.

The real solution to preventing phishing? _Education._ Educate the users.
Empower them with the knowledge to understand what URLs are and how they
relate to where they are on the Internet. We should not continue to keep them
ignorant, as they will become even more so, and that will have negative
effects on the future of the Web and continue to propagate the notion that
computers are "impossibly difficult to understand". I have worked with people
who are otherwise very intelligent and sensible, but whose brains appear to
completely leave their skull the moment they need to use a computer; and feel
that this attitude may be partly responsible for that.

------
Pym
I have the new UI and... it's awful.

I get the whole "it's for preventing phishing, etc." but I believe that it
shouldn't be done by hiding the URL from the user.

Furthermore, it's a real pain to have to click to see it. And guess what
happen if you go to another tab and then go back to the first one? The URL is
gone. You can't even compare 2 tabs URLs.

IMHO: good problem, wrong solution.

------
koala_advert
I keep getting this error, in Firefox and Chrome:

<Error> <Code>AccessDenied</Code> <Message>Access Denied</Message>
<RequestId>3CB1F41D7DFDC794</RequestId> <HostId>
wHCPzEYPDsmkMJX+YIgjU40YPrGYytHrk5B44dApi7663NkQQI0RKx9A/6EX7Iph </HostId>
</Error>

------
relate
I just hope it will still be easy to prepend urls, such as when entering
reddit.com/s/URL_OF_CURRENT_PAGE

~~~
justinschuh
This is an in-development experiment, so its current state is a work in
progress. Anything that would ship to users (assuming it even does) would do
so in a way that does not damage the general utility of URLs.

~~~
DerpDerpDerp
After dealing with YouTube for the past year, I'm very skeptical Google won't
mangle a UI/platform for "the good of the common user".

------
nnx
That's an interesting experiment. How about showing breadcrumbs (as seen on
Google search results page) next to the EV/domain badge?

eg. Registrar Inc [US] | registrar.com › SSL certificates › Renew

------
qwerty_asdf
So, on the HN front page, for each thread, only the top-level domain is listed
in parenthesis, next to the title, and no other part of the URL is shown.

Am I expected believe that this is "secure"?

------
daemonize
I believe banks would be better served sending emails with links that open
their mobile app instead of popping up a web browser.

------
Touche
I find it to be evil to release a feature that is about security aside a
feature that highlights the fact that you can Search Google. Separately we
could debate the merits, but putting them together you've totally placed focus
on security.

------
Grue3
Obscurity is great for security. Mostly bad for everything else.

------
johnchristopher
> To the average user, the URL is noise. It's a mix of protocol, origin, and
> path. It's a terminal command, echoing it back to the user is weak UI. We
> should focus on the security of the URL, without harming shareability.

Powerful words.

------
jfaucett
interestingly, cookies would not work for this url in IE.

------
personZ
Surprised to see so much attention to this: Isn't it exactly what Safari on
iOS does on hundreds of millions of devices worldwide?

EDIT: And given the seeming _confusion_ by some, no, the "article" (if a
couple of screenshots and some guy giving an opinion is an "article") is
utterly irrelevant to this comment. Noting that it mentions iOS is
meaningless. We continually see front-pagers voted up by people who seem
blissfully unaware of trends in the industry.

~~~
kylemaxwell
Did you even read the article, where that comparison is made explicit?

~~~
Pacabel
Not only is it explicitly stated, but it's done so in the very first sentence.

~~~
personZ
How could you have gone ahead and posted such a banal, irrelevant comment long
after I made it clear that the linked content doesn't matter? Sad attempt at a
dogpile?

