Chrome's experiment of hiding the URL is great for security | Hacker News Reader

Chrome's experiment of hiding the URL is great for security

jakearchibald.com

190 pointsjaffathecake205 comments

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.

So this came from the same genius who came up with the "checkbox to show all your passwords in clear text without any further safeguards" feature? Man, you're a menace to the web.

Personal attacks are not allowed on HN.

That should probably go in the Guidelines if true - it's not there now.

If that isn't derivable from the guidelines' call for civility, nothing is.

It's completely possible to be civil to someone while attacking them for their actions. Politicians do it all the time, for instance.

> phishing is a very big problem

Is it? What are the numbers?

So many annoying things are done in the name of "security" without much justification (both online and in real life); Chrome removed the protocol for no reason and Firefox felt obliged to do the same, and now we're removing the whole url just to help folks who can't be bothered to read it?

Another comment suggests "source code highlighting" for the url, where the actual domain would be emphasized while still showing the whole url: what are your thoughts on this?

(Disclaimer: I have not tried the Chrome version in question so I very well may not know what I'm complaining about.)

> Is it? What are the numbers?

Providing more detailed background and better numbers on phishing sounds like a good idea. However, this is an experiment that is not on track to ship in any version of Chrome, so I wouldn't consider it a gating criteria for continuing to experiment.

> Chrome removed the protocol for no reason and Firefox felt obliged to do the same, and now we're removing the whole url just to help folks who can't be bothered to read it?

The decision to not display the HTTP scheme was not related to security (and it wasn't to my personal liking). However, it was done in such a way that it was effectively security neutral.

> Another comment suggests "source code highlighting" for the url, where the actual domain would be emphasized while still showing the whole url: what are your thoughts on this?

As I commented elsewhere, Chrome has been highlighting the origin since its inception. However, phishing is still a serious problem, so the team that's working on this is investigating clearer indicators like the ones in this experiment.

So you think crackers(>hackers) and people with bad intention will be unable to see the URLs and won't be able to do phishing easily.

So, through obscurity you will achieve security.

Edit: or you expect users to notice phishing attempts more clearly by only displaying the domain name?

I am not sure the "security/obscurity" logic applies here.

It's all just GUI change, nothing is really obscured (as in not accessible). It's just more radically highlighted.

It's the latter. By only displaying the domain name users are more likely to notice a scam domain name, e.g. the Halifax.co.uk case in the parent blog post.

Thanks for understanding former or latter iquestion which I wrote at once:-)

I'm not sure you quite understand!

The intent isn't to hide the URL from technical people like scammers... Its to hide it from nontechnical people. It's easier to train your grandparents to look at a shortened URL containing just the domain name, and having them verify that is what they expect - as all the distracting bits of the URL are gone...

(Also - "crackers" refers to a very different group of people....)

If black vs. light grey is your concept of "highlighting" then I have to tell that I didn't even notice the behavior until today. Maybe you should try actual color before removing functionally?

Seconded. The current situation doesn't appear to warrant the term "highlighting"...

I feel I'm fairly immune to traditional phishing because I never click a URL in an email. If namecheap sends me an email saying one of my domain names is about to expire, I don't use their "Renew Now" link I go to "namecheap.com" (not hard to type), log in, and renew the name. Banks and other organizations that send long complicated links in emails and encourage people to click them are part of the reason phishing is possible. These emails should look like:

Dear John Doe,

An automatic payment has been made from your checking account:

04-May-2014 $125.00 to Big Energy Utility Corp

For more details, please log on to your online banking account and click the "Recent Transactions" tab.

There is no need for hyperlinks in any of that.

plus it forces web sites to be designed in such a way to easily locate what you need, e.g. "recent transactions" shouldn't be buried deeply in the navigation tree.

Yeah, part of me wonders how bad it would be / what would break if email clients banned outside links (e.g. beyond fragments in the email). My suspicion is that the only useful use of a link is a confirmation email which have other potential implementations...

It could be interesting if Gmail did the Chrome experiment in email links in a popover, by displaying the domain of a link...

This would effectively break email verification, which would be pretty bad.

    To verify your email, please login at SiteYouHaveJustRegisteredAt
    and enter the following information:

    User ID: 1234
    Verification code: 12345678

>where the actual domain would be emphasized while still showing the whole url

This is already the case in Firefox. I don't know how long they've been doing it, but I think it's the perfect compromise.

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.

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.

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

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

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

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.

Agreed. It also solves another problem in Japan, namely that brand names etc are usually written in Japanese letters, but URLs in ASCII (yes, I'm aware of IDN, but haven't ever seen it used). This is obviously not limited to Japan, I wouldn't be surprised if other countries used the same trick.

That's sort of been happening in the UK. Instead of some companies giving out a URL, they'll just say "Search xyz for more information"

Aren't Google AdWords effectively "stable keywords for sale" today?

I agree that this experiment isn't demonstrating a perfect mitigation, but it's important to appreciate that it's currently vastly easier for a phisher to permute paths and subdomain components than it is to create a convincing ETLD+1. There are various reasons for this, including less text for a phisher to work with and registration requirements for ETLD+1 domains (which means they can't be iterated and dumped as quickly, and domain owners may have a more immediate legal recourse against phishers). That's the point of experimenting on features like this, to get an idea of whether or not the they would be beneficial.

What about doing something more like this: https://twitter.com/aripalo/status/462942544007929857

The issue isn't users recognizing path, it's the domain. It's also that they aren't taking special care while logging in.

Additionally, what about addressing insecure forms that fail to utilize https. Chrome is already detects login forms. So just warn users by turning the origin chip to a red background when they are on a login page.

On the whole, supporting secure logins would be better for the internet.

The problem with that is you can't detect all login forms. If you cannot detect all of them, there's a way to hide them from the browser.

> What about doing something more like this: https://twitter.com/aripalo/status/462942544007929857

The team may choose to do something like that in the end. That's really the point of experimenting with different approaches; they use them to get feedback, run user studies, and get a sense of what works best.

> Additionally, what about addressing insecure forms that fail to utilize https. Chrome is already detects login forms. So just warn users by turning the origin chip to a red background when they are on a login page.

That's actually very, very hard (as in np-hard). Chrome has heuristics for detecting login pages, but it doesn't even detect all legitimate login pages. And it's trivial for a phisher to intentionally make a page that appears exactly like a login page to the user, but will not be detected by Chrome's heuristics.

> That's actually very, very hard (as in np-hard). Chrome has heuristics for detecting login pages, but it doesn't even detect all legitimate login pages. And it's trivial for a phisher to intentionally make a page that appears exactly like a login page to the user, but will not be detected by Chrome's heuristics.

Well, it wouldn't have to detect all login pages, it could just detect most of them. That would add soft pressure to encourage regular websites to use HTTPS in the vein of

https://www.eff.org/https-everywhere

Hopefully we can push the web towards https everywhere, and users begin to ask the question -- "Why is this page not secure" when performing a login.

This soft pressure worked wonders in a number of places: When Google started doing sitelinks, many websites became much more concerned about making those available on their website. In a similar way, hopefully they would be concerned with getting out of the red for their login pages.

It's not even NP-hard, because it's not well-defined and thus isn't even a decision problem.

You could detect forms that have more than one user provided input field as they are submitted. This wouldn't detect most search boxes or forms that use hidden inputs to transmit values to the backend.

But `input[type="password"]` would cover the majority of login forms. At the least, it would force the con-artist have to mimic a native password box, which is more likely to get caught by the end-user.

Yes. Anything that doesn't use a password field is normally a giant hack anyway.

So facebook's mobile login page wouldn't trigger, for example.

It's not as simple as peolpe think of it. It never is.

> Additionally, what about addressing insecure forms that fail to utilize https.

FWIW, Firefox detects insecure login forms and emits a security warning to the web console. This is aimed at developers, however, not users (because the developers are the only ones who can improve the situation).

Our heuristic is imperfect as well. We simply detect <input type="password"> fields on http pages. This works well enough. Trying to detect when developers are abusing <input type="text"> for a password field is non-trivial.

How long has Firefox been logging security warnings (in the web console) for insecure login forms? Do you know of telemetry about how prevalent the problem is or whether the security warnings have helped? I assume, for compatibility, Firefox will never be able to simply reject insecure login forms.

It looks like it's been around half a years¹. There's also a reference to the Chromium bug² for implementing the same there.

There's also mixed content blocking³ which is a similar but user facing feature.

1: https://bugzilla.mozilla.org/show_bug.cgi?id=762593

2: https://code.google.com/p/chromium/issues/detail?id=327032

3: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-bloc...

I'd say that is the best solution, possibly with more work done on the certificate button left of the url. The button currently highlights “good“ sites: https with an Extended Validation certificate. It should be the other way around. Highlight as warning when the site falls short: no SSL or SSL without EV.

I really like that. Preserves all the benefits of hiding the path entirely without... hiding the path entirely. However, how would the browser tell the difference between editing the path and entering an entirely new url or search? It wouldn't be intuitive if you have to click the domain chip to go to a different site. Most of the time a user is going to click the path area in that screenshot, since that's what we're used to. But then, how do you edit just the path?

One solution would be that if you click any part of the url and you get fully editable text so you can change the domain or any part of the path.

I don't know if such a thing already exists, but perhaps a way for a user to define 'secure urls' that go to their bank (or other important site) would be useful. Chrome could then warn when a user goes to a site that looks too similar.

Good summary, basically the inter web linking will become:

google://keyword

or better

google keyword

or even simply

keyword

Reminds me of AOL

no it wouldn't. You might put that in an ad (and as people above note, this is already happening), but this only changes what's displayed in the location bar. It would be stupid to link to another site through a web search when you can just link to the site.

although, I'll note that once again, the internet is already on the case. The link you were looking for was http://lmgtfy.com/?q=keyword

We've seen this before:

http://www.musicman.com/00pic/credits.jpg

Great link... Seeing people communicate "google yourbank" and address bar becoming a search box, I thought href could be extended as an innovative technology to allow intermediated linking through a search engine.. (or Url shorteners with keywords)... But AOL already had it...

Hah! "Edwaed Burns"

I've already experienced this with a vendor who sends me links to his own site as parameters of a Google search.

e.g. google.com/search?q=http%3A%2F%2Fexample.com%2Fdemo3.html

I don't even know how he generates those URLs and he didn't respond when I asked why he does it.

He probably searches for his website, and then copy the link directly from the google page, rather than jumping into his page and copying the URL.

There is more that can be productively argued about this topic, at least for parties who decide to not insist otherwise. URLs won't go away as long as people are still sharing websites on social networks or their own websites. I don't see the problem with not displaying the entire URL at the top of the browser window, if no actual functionality it lost. I this case, there's not even any additional clicks required to perform the same operations with URLs.

I agree with the possibility for productive debate, my comment is probably a bit too cynical. I just see a lot of redundant arguments, bad analogies and strawmen coming up soon and jumped the gun.

Came here to say similar. In addition I dont see any problem. The URL bar is a redundant usability smell. Needs to be cleaned up in the fashion they have.

On security, I feel its a problem sure, but teaching users about URLs is a bandaid fix, a hack and completely irrelevant to this change. You can't fix the phishing problem by showing URLs. It needs to be tackled in the proper manner and solved silently from the user.

Google already does the right thing when you use them for DNS (redirects on mispelt). They also implemented blacklists of dodgy content, not ideal and doesn't scale but its a good start. Better than claiming the user is at fault.

Basically if you need to claim the user is at fault your design is wrong whether you like it or not.

> but creates an entire class of users that don't understand what a URL is.

Most people have little idea what an URL is, nor how to use an address bar.

Watch a few people navigating to http://www.example.com/example.html to see what they do.

I personally have never understood the huge sums of money paid by some people for some URLs. I can't remember URLs; I can't remember keywords. What I can remember is some fragment of a page title, and I hope that's enough to find it in my bookmarks or in a websearch.

I wish Google would just release some numbers about the numbers of people who get this stuff wrong, because learning how many people use (correctly) the + operator made that change much easier to cope with.

>There is nothing more that can be productively argued about this topic.

Is that ever a good thing to say?

The change is good. I never saw any mention of people disliking this in Mobile Safari, and it's an option power users will turn off. There's plenty of them already.

As a developer, if this is going to hide any useful information on first glance I am not sure how I feel about that. I already feel like Chrome has started shunning developers with that over the top annoying pop-up any time I open a new window (Ctrl+N, type, stop typing because I have to move my mouse to close the popup), and moving towards forcing developers to distribute their extensions through the play store (which kills any small-time extensions for tiny communities & friends).

I appreciate trying to make Chrome more secure, but please don't forget about the developers. Annoy them too much, and they might move their development to another platform.

A big part of the problem is that while there are competing browsers, we just don't see any real competition these days.

Firefox and IE have started copying Chrome in appearance and philosophy. Opera is now based on the same code. Safari is based on similar code, and is unusable by anyone not using a Mac of some sort.

Firefox is perhaps the most viable alternative to Chrome for web developers or advanced users. But due to that lack of competition or original thought, it really isn't much different from Chrome at all. This has become very apparent with the release of Firefox 29, where they both now look nearly identical, and both suffer from the same dumbing-down that has harmed the experience for more advanced web users.

What is the popup you're encountering? Because it sounds like a bug, and I'd like to make sure someone is working on fixing it (or has already done so).

The popup that urges me to disable the extensions I am developing: http://i.imgur.com/4tBDrVw.png

I just tried to reproduce it, and it doesn't seem to actually happen for every new window I open, so I am not sure what I am doing to trigger it, but I do encounter it several times a day.

edit: Incognito seems to do it, which makes sense because I often enter/leave incognito to make sure I have a fresh cache & no cookies when testing.

If you use the dev channel, they no longer show this popup (or color the extension icon orange).

How common are usability bugs in the dev channel?

The custom extension popup, and you dont want to fix it(status is wontfix) ,where a simple checkbox in the settings could have fixd it... you made our lives miserable.

My first reaction when I saw this change was, 'Oh, good, this website uses HTTPS now'. If I wasn't tech savvy, I would probably not have noticed that I was wrong. Given that, when I learned what had been done, the first thought that popped in my head was, 'Phishing only has shifted from one form of deceit to the next'.

Also, while reading Jake's post again, I realized that having the URL path colored in grey was already a big hint that something was off. Going all the way to white doesn't make a valuable difference; maybe using blue rather than grey would make the difference more striking.

I'd love to know exactly how the experimentation works. Do you perform user surveys? How do they work? What is the criterion that decides that any particular experiment failed and should be scraped off?

respectfully ...

chrome is already breaking half of the copy/pastes i do because it's from my history and not a page that's already loaded.

do you have any idea how many people actually use copy/paste? i would venture that ctrl-c/ctrl-v is probably the only key binding that the majority of computer users of all walks of life use.

half of the places i seem to be pasting links into don't pick up the links without the http. Including things like markdown in github issues, many chat systems.

Messing with the url bar when you did it last time has been a constant daily sense of irritation to me. So no. I don't want you to mess with it any further.

just please stop.

Something similar happened with various other of Google's properties a while back — Google's use of intermediate redirector URLs that broke cut-and-paste.

I'd prefer to reference the destination URLs and wsites in the documentation and related materials I was creating, and the only way to do that with various Google web properties was to visit the destination site and cut and paste from the browser from there — otherwise I'd end up with a Google "link shortener" obfuscating the domain, and possibly also eventually interrupting the connection if (when?) Google decided to discontinue or update the redirector service.

Further, this Google practice filled the browser history with intermediate URLs, which rendered the browser history far less useful.

I would not expect Google to stop these behaviors, though. Switch search engines. Vote with your clicks and with the data you (don't) expose to Google.

Why should it make copying, pasting, or editing URLs more difficult? Right now in stable Chrome, you click once on the URL bar and it selects the entire URL. Then you can Ctrl-C to copy, Ctrl-V to paste, or click again to put the cursor in a specific place to edit it. That shouldn't be any different with this new Chrome feature they're testing.

Indeed, or make it even simpler: F6>CTRL+C

The F6 functionality is the reason I welcome this, Chromium devs aren't really taking control from us more tech savvy users, they're making it easier for regular users to spot the relevant part of a URL.

I already use F6 for all interaction with the omnibar as it is. Also, I'm not sure which browser it was (Opera or Firefox), but I distinctly recall either of those a few years ago having the exact same functionality discussed here, where only the domain was shown unless the URL field was active.

you can show the entire url while highlighting the root domain. its a design issue, lets hope the solution isn't hiding the entire url

Firefox solves this rather elegantly by making the subdomain and the part after the domain light grey, with the actual root domain in black.

The URL is intact, and the root domain stands out clearly.

It's a start but I hadn't noticed this feature and wouldn't notice if the whole URL were in black. Using different colours to highlight different parts of the URL would be a big improvement.

Chrome has done this since 2010: http://chrome.blogspot.com/2010/10/understanding-omnibox-for...

Firefox's implementation of this feature is at least partially because of its usage in Chrome and other browsers: https://wiki.mozilla.org/Firefox/Features/Locationbar_Domain...

There's not enough contrast between them to really tell the difference unless you look closely.

It was done once back in 2007 but there were a lot of complaints:

https://bugzilla.mozilla.org/show_bug.cgi?id=388135#c5

OK, but my current build of Chromium also has the subdomain in black, leaving it susceptible to the trick described in the article.

The main point is that there are ways of going about this without having to kill the URL bar.

You want to help people feel more secure? How about you downgrade every https website to Yellow color, unless it uses PFS (only with a few good cipher-suits) and the latest version of TLS. Requiring HSTS would probably be good, too. They should also be required to have 100 percent of the site under https, before getting the Green color. No mixed content.

Right now you (and other browsers, too) give the "safe" color Green to to the bare minimum of https security, even if it uses TLS 0.9.8 and RSA 1024-bit. Sites are not going to upgrade their security policies as long as you, the browser vendors, keep showing them to the users as "perfectly safe". There's no incentive in it. I think it's on browser vendors to push some of the incentives.

What percentage of big websites (say, top 100 sites and top 100 e-commerce sites) use HTTPS without PFS? If it's significant, then the yellow will just become meaningless.

Does the kind of person who falls victim to a phishing attack pay attention to anything on the URL bar anyway? Are they going to have any idea what the green padlock thing or "secure connection" even mean in the context?

"...the whole point is to prevent phishing"

URLs are the bread-and-butter of the web. Surely, you don't have to hide the whole URL? Why not simply show the whole URL but visually emphasise the domain in some way so it stands out. Make it easy to read the whole URL while emphasizing the domain (i.e. don't fade out the rest of the URL so its too faint to read).

There are other ways of tackle phishing too. If most phising occurs when you click links in your email, then email providers could display an intermediary page before you're taken to the destination link. The intermediary page tells you the domain you're being taken to: you click a PayPal link and the intermediary page states you are about to be taken to sharkventures. This could of course be very annoying for every web link and some users won't read email re-direct messages, but it's another approach.

That's what I'm thinking too. Why not make the domain rainbow colored and blinking if that's what it takes to stand out. It doesn't mean the rest of the url has to be absent entirely.

Calling this a phishing mitigation is blatantly dishonest. Hiding the URL does nothing to stop phishing. UX improvements are great, and this is clearly a UX change designed to perform great on metrics Google cares about (like search traffic), but it is not anything resembling an attack mitigation.

Here are some things that actively mitigate phishing; many of them available in Chrome and actively used by many web properties (including Google's).

HttpOnly cookies (introduced in 2002!)

'secure' cookies

Content Security Policy

iframe sandboxing

input sanitization

isolating user input to low-privilege domains to protect unsecured user information

clear, identifiable URLs that increase the odds of users recognizing something wrong

two-factor authentication

What is an example of a phishing attack or XSS attack that would be stopped by this change? Is there at least an example of an attack that would be mitigated? I cannot for the life of me think of one.

Not one of the things you list helps phishing. I think maybe you are confusing phishing with other types of attacks.

Phishing is when an evil website tricks you into typing your bank password into it. HttpOnly cookies (as an example) are not going to do anything to prevent an evil website from looking like your bank's website.

"No one has any intention of diminishing usability or making it hard manipulate URLS"

Except that's exactly what's being done here. You mean that no one is twirling their moustache saying "muahahaha, soon we will make search the only way to navigate the web!" like a bond villain. Of course not, that's stupid. That's not how things happen.

People are concerned that the intention is to make changes to chrome that value the primacy and visibility of URLs fairly low compared to other factors. Everyone involved is well meaning (especially with the "won't somebody please think of the elderly!"-ness of the anti-phishing agenda), they just have an unavoidable institutional bias. It's not a coincidence that these all make the google search bar more prominent. That's valued very highly.

If your criteria value X relatively lowly and you evaluate a bunch of things which are judged with those criteria you end up diminishing X. No one cares that you didn't "intend" to do it, they care that you are doing it.

Why not just colour the domain?

I'm not sure how this would prevent phishing. 99% of people affected by phishing don't know much about URLs anyway, and legit sites routinely use weird domains like "onlinecredit6.com" or "xyznetaccess.com" which are indistinguishable from phishing ones.

I know one thing though it would prevent - if Chrome keeps doing such things that actually may force me to switch back to Firefox. Hiding URLs IMO is a horrible idea.

I would prefer if the hostname was clearly separated and highlighted with the path after. I don't really feel the need to be able to instantly enter a new url outweighs my desire to see what URL I currently am on.

@justinschuh: what's the best way to provide feedback?

In particular, I generally like the change, but it bothers me that I need to hit the new button in order to see the URL, instead of clicking anywhere in the omnibox. I'd rather see a better-phrased version of "Search Google or interact with URL" in the omnibox, and get the whole URL on click anywhere in there. I could imagine then making a click on the button pull up the security details, just like what happens when you click the lock currently.

Also, it'd be nice if you showed the whole URL when hovering over the button.

As the person who reported issue #337746:

http://googlechromereleases.blogspot.com/2014/04/stable-chan...

I agree that this would be a big win.

If this type of rendering were in place it would protect the user in most cases even when a secondary issue like the one I reported exists in the full rendering code. Well worth the minor inconvenience of having to click the 'chip' to show the full url if you happen to need to see/copy it.

It's bad enough that google makes it impossible to cut-and-paste links from search results (try sending the URL of a pdf you've found using google to a colleague, especially nice if it is longer than the maximum bit displayed as text).

Getting rid of the URL makes users effectively out of touch with 'where' they are on the web and within a website.

A browser is a navigation device, a browser without a sense of location is the digital equivalent of being lost.

As usual I put my foot in my mouth on the last HN thread. This sounds like a good idea.

My point in the last thread is that for me, personally, I edit the URL a lot. I'm writing HTML5 games. During dev I use the URL to edit/set parameters as in `http://mygame.com/numPlayers=3&ai=true&runSpeed=47`. Having the URL hidden will make it harder to edit that. Sure I can click the "show me the URL button first" it will just be annoying because I can't directly target the `47` like I can now since I won't be able to see it until after I click "show me the URL".

So, just like only devs use dev tools I'd prefer if there was a way to let me see the URL constantly. Like maybe if devtools is open the URL shows? Or maybe it's another options in dev tools just like 'disable cache if dev tools is open'? I'm sure people working with history.pushState would also like to be able to see the URL live.

Do what's best for users in general. Just please help us devs to dev too :)

Why not, instead, show an ellipsis in place of the majority of the subdomain leading up to the domain and increase opacity of the domain compared to subdomains and the pathname.

This is similar to what happens when the path is too long for the omnibox, but simply the effect of putting the domain as far left (in the omnibox) as possible.

i.e. instead of seeing:

[ www.mybank.com.credicards.wt3_segment_secure.login.html.evil-site.com ]

You see:

[ ...html.evil-site.com/ ] (where "...html." are semi-opaque).

I mocked up what I'm suggesting here: http://remysharp.com/2014/05/04/on-chrome-hiding-urls-to-pro...

So what I'd like to see eventually is some sort of indicator about the SSL chain itself.

I've put together a quick repo to PoC an idea that maps a chain to an html color, but I have no idea where to incorporate it into a UI.

https://github.com/Fitblip/Fingerpaint

Ideas?

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.

Nobody is asking people to understand the HTTP protocol. This is understanding how information is addressed in the 21st century.

The more apt comparison might be physical mail addresses. People should understand (and it is taught in schools!) the basic format and the structure of it. We don't ask them to understand (in the states) the layout of zip codes, but we do expect them to understand that the first line refers to street address.

Similarly, we can do the same education for information today. We can explain the design behind the structure, the beauty and simplicity in URL design. (not always, I get that) Or, we can just continue on the path we're headed and tell users: "just type this into the search bar (Google), and a website comes back, along with some ads (probably)".

While I would love for the simple idea of the URL scheme to be something everyone understands, I highly doubt it's every going to happen. I'm sad about this, but I live in the real world with real people, and I've seen the kind of stuff they do and don't learn, whether by ability or by inclination.

What's sad is that we've had URL schemes for 20 years and they aren't taught in school. Also sad is many people think we teaching algebra and calculus secondary education is a given but basic concepts like domain names in a URL are "too complicated" for the real world.

I get where you're coming from, and I'm not sure whether I agree or not.

Personally, I think modern education is wrong-headed time most of the time, but I'm not sure I'd switch to teaching URL schemes if I was overlord of the universe. I'd much more likely insist on teaching the basics of economics, finance, logic, rationality, human psychology, etc.

URLs would still be far down my list.

Basic URLs take literally a single day to teach. The people you're teaching them to already have more contact to them than almost anyone else. Schools already have computer classes (or should have anyway).

Then you want to teach them basic finance so they can't throw away their money, except on a phishing attack? We should make users more powerful, not take away everything that can hurt them like hiding pointy triangles from kids.

You might not be giving people enough credit, people without CS degrees have been using URLs in emails and forum posts to link to information for years.

If there was some level of abstraction/automation to allow addressing physical mail without knowing street numbers, zip codes, etc., I would be fine with that. I imagine there is actually a lot of problems with mail delivery because of the messiness of addresses. I've encountered it a few times in the USA (some carriers want "Route P" but some want "Highway P," and some want "Suite 404" but some want "4th Floor"), and I bet it can get even messier, especially in poorer countries.

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

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!

> 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

Just as it would be unreasonable to require that anyone who drives a car roughly understands how an engine works, it would be similarly unreasonable to require that anyone who uses the internet roughly understands how addressing works. It is of course true that your car ownership experience will be greatly enriched by understanding roughly how an engine works, and that your internet experience will be greatly enriched by understanding how addressing works. But neither should be a prerequisite.

You underestimate how subtle the concepts underlying addressing are, probably because, like many technical people, you have understood how URLs work for so long that you can no longer remember what it is like to not understand them.

There's a rich irony in your avoidance of the most obvious car analogy possible: between internet addressing and street addressing.

Understanding URLs is in no way similar to even a rudimentary understanding how an internal combustion engine works.

What it's most similar is understanding how we address and route physical destinations so that you can get there in your car.

As I said in another comment:

Try and explain to the average user why URLs on HN look like this:

news.ycombinator.com/?id=123123

Whereas on CNN they look like this: http://edition.cnn.com/2014/05/04/world/africa/nigeria-abduc...

Whereas on another news site (Israeli) they look like this: http://www.ynet.co.il/articles/0,7340,L-4516118,00.html

Whereas on Reddit they look like this:

http://www.reddit.com/r/pics/comments/24p3tm/japanese_photog...

Each one of these is a completely different implementation detail which the average user doesn't care about and, honestly, won't necessarily understand without understanding the underlying technology behind these sites.

Remember: Most users barely understand, if at all, what a browser is! And if you want to see a comparable challenge, try to explain to someone just one thing - why do some sites have www vs. not.

The parent's sentence was really great:

"You underestimate how subtle the concepts underlying addressing are, probably because, like many technical people, you have understood how URLs work for so long that you can no longer remember what it is like to not understand them."

> Try and explain to the average user why URLs on HN look like this:

That's easy. "The information following the domain name is used to route your request to the appropriate destination".

> Each one of these is a completely different implementation detail which the average user doesn't care about and, honestly, won't necessarily understand without understanding the underlying technology behind these sites.

Why do they have to understand the "underlying technology" at all?

If you think physical addresses are simpler, you'd be wrong:

   Sgt John Smith
   Headquarters Company
   7th Army Training Center
   ATTN: AETT-AG
   Unit 28130
   APO AE 09114-8130

or:

   Mr John Doe 
   CMR 333 Box 2345
   APO AE 09903-0024

or:

   John Doe
   C/O Acme, Inc.
   STE 12
   123 Main St NW
   Placename, State  12345-1234

or:

   Jane Doe 
   P.O. Box 562 
   Placename, State 12345

or (this is dual addressing, guess what it means? it doesn't mean the P.O. box is at 123 Main St NW):

   Jane Doe 
   123 Main St NW
   P.O. Box 562
   Placename, State 12345-1234

or:

   Don Johnson
   Professor, GIS Studies and Internet Arguments
   UCIA Computer Science Department
   5th Floor Rockefeller Building East
   C/O UCIA
   12345 Main Address Street
   Placename, State, 12345-1234

These are complicated, and we haven't even delved into common abbreviations, street layout consistency, relative addressing, or, god forbid, international addressing.

Yet somehow people write, address, and successfully send mail, every single day. They get in their cars and navigate the interstates and the weird street grids and one-way streets that they're unfamiliar with, and eventually wind up at the right place.

Or, they plug the address into their GPS and get there, without ever really understanding how the GPS performs the routing, just that it does, but still fully cognizant of what the addresses mean, even if they don't understand the system under which they were allocated.

I don't think your argument holds water; not even a little.

Well, you're absolutely right that I don't understand most of those addresses.

You're right that I could still send them mails though, in exactly the same way people use URL's - rote copying them, then letting the technology (or mail system) work its magic. I don't need to understand your PO box example to get it working.

> Try and explain to the average user why URLs on HN look like this: > > news.ycombinator.com/?id=123123

Easy. All most people need to get out of that is the fact that there's a domain name there, and something to make each page unique. I suspect most people would also quickly recognize that each page has it's own number, similar to street addresses or the serial number found on just about everything these days.

They don't have to actually parse it as a query string. The fact that some URLs reveal a lot more information (like your CNN example) is a bonus.

> Remember: Most users barely understand, if at all, what a browser is!

Remember: 14% of adults[1] in the U.S. are illiterate.

Nobody said that we have everything solved. That doesn't mean we should give up and pretend the problem doesn't exist by saying that "most people don't need to read".

[1] http://www.statisticbrain.com/number-of-american-adults-who-... (original source: Dept. of Education)

I'm very surprised at that statistic, so thanks for bringing it to my attention.

"They don't have to actually parse it as a query string. The fact that some URLs reveal a lot more information (like your CNN example) is a bonus."

Well, what you're saying is exactly what Chrome is doing - make people only care about the domain, don't bother with the rest of the information as it's "only there to make a page unique". What exactly are we disagreeing on?

I think grandparent's point was that the part after the domain serves simply as identification of the information that is requested from the domain. Just like the foo in foo@bar.com identifies the user at that email domain. The user doesn't need to understand the particular implementation of the identification, just the principle "same string, same page". This is important to understand that URLs can be copied and used as links on the web. I've seen people not understand this: e.g. someone uploading a video to Youtube, then when I suggest to add a link to another video, or their Facebook page, not knowing that this can be achieved by copying the URL of the relevant pages out of the address bar. This is the missing internet literacy, and it seems unlikely that moving away from the "URL is just a piece of text" principle would make the understanding easier.

Sadly the simple principle of "same URL, same information" breaks down somewhat because of cookies (and, to a lesser extent, IP localization and user agent). http://facebook.com/ shows completely different information dependent on the logged-in account, and in fact that same person mentioned above was aware that URLs without a path part is the home page of that domain, and was thus expecting that http://facebook.com/ would show the same information to everyone. I'm not sure whether he/she really believed that the whole world should be seeing his/her posts, but it surely is a bad move by Facebook, it actively breaks the premise of URLs and is thus arguably damaging for internet literacy (and perhaps they are purposely doing it to mislead some people into a false sense of personal importance).

I agree with the first point, but it breaks down for me when you suggest that the principle of "internet literacy" is more important than making things easier to use for the user. I would not want the people building my car to have never invented the automatic gear, because they decided somehow that it removes me from understanding how a car works.

The difference is that understanding what a gear is is not essential to the functioning of a car at all. You can completely remove it without loss for that particular user nor for the community of car users.

Whereas not knowing that a URL is a piece of text which specifies a particular content on a domain and can thus be copied and used for linking is a loss both for the user and for the community.

You'll have to reinvent the principle of linking in another form to avoid the loss (e.g. every web and local app would need special GUI functionality to use instead, and the need for specification what to link would not be completely removable, unlike the gear).

A mistep with urls is that they're encoded when shown in the address bar. If spaces etc were just shown as is they'd instantly become more readable. Given that possibility you might find that developers drop a lot of the noise like hyphens (which really is a hack to have readable spaces in urls anyway).

"Try and explain to the average user why URLs on HN look like this"

You're missing the point, you don't have to understand that anymore than you have to understand why my street number is 4 digits long or my street name ends in "street" instead of avenue, crescent, drive, lane, etc.

It's not literacy, it's more like knowing car's engine error codes. Arcane knowledge which is very useful if you're mechanic but would be mostly useless trivia for anybody else. Guessing "example.com/2014/04/18/the-great-quux" is a date-based URL is a nice parlor trick but most sites don't even have this URL scheme or any URL scheme at all. Next to none of the phishing-relevant sites does. No print ad would have URL of any complexity - if it would have anything beyond domain name it'd be a single keyword.

I would liken more to like the readouts of the car. Say we hide the fuel gauge behind a menu and replace it with a "need gas" symbol. A clueless user might say "I don't want to learn how the fuel gauge or recirculating air button work. I just want to know if I need gas right now."

But knowing how to plan your trips/stops is important, as is knowing where your air is coming from.

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

I still want to support those that do, and prevent them from having unnecessary burdens on their way. Understanding how things work is hard enough already by itself.

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

On the other hand, you are required to get a driver's license before you are allowed to drive, because if you don't know the rules, you can harm yourself and other people.

Perhaps that's the direction we need to go: an Internet User's License that teaches people the basics so that they don't harm themselves and other people. They don't need to know how the Internet works to use it, but they should be expected to know how to keep themselves and others safe.

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.

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

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.

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.

View-source & devtools are also useful for people who know what they're looking at. Those things are not shown by default.

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.

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://, 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/

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.

> Chrome has bee 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.

Barely. There's very little contrast between the two parts, not enough that you would notice that there is a difference unless you look very closely.

Everybody is complaining about the lack of contrast between the root domain and the rest of the domain in the URL bar. I reckon, both in Chrome and in Firefox, there is quite noticeable contrast between the root domain and the path/subdomain. If the contrast was bigger, then the path would be unreadable, which undesirable too.

In Chrome the domain is black and the path is grey. You could make one red and the other green and that would be actual contrast. Or give the domain a background and border. There's more ways to contrast things than adjusting the lightness of black.

More contrast might be good, but I'd not take it in expense of ugliness.

Why does it need to be ugly? I'm not a designer, but I have a hard time believing that the only way to contrast two elements without making it ugly is by having them be a slightly different shade of the same color.

Devs can just press ^L to select the URL, I think. That's what I do when I need to change/manipulate/view it anyway.

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

I like how myself and my (not all technical) friends know what URLs are and can copy them if they want to link me to something.

Now they probably won't be able to figure out how.

Have you even tried using this feature? You can enable it in chrome://flags. You can still copy and paste the URL just fine. Thanks for the downvote. I'd love to hear you refute my argument, rather than spew nonsense complaints.

chrome://flags/#origin-chip-in-omnibox

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)

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

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.

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

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

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

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.

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.

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

Luckily, LastPass ignores that.

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.

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

We also shouldn't be sending our credentials to any site where we authenticate. Passwords are just plain wrong.

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

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

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

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

Having comments on the 404 page is a brilliant idea. More websites should do this!

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.

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.

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

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

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

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.

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?

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.

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.

Also, cmd-l cmd-c works as it always did.

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

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.

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

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

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]).

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.

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

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

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

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.

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:// into google://

No, thank you.

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.

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.

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.

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.

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

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.

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>

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

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.

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

Judging from the current state, it won't. Currently, that operation requires 1 click to switch to text mode, a loong second waiting for the fucking animation to finish (who the hell puts animations in the way of user interaction?), then another click to unselect the automatically selected URL.

Chrome isn't hotkey capable?

Ctrl+L -> Home key -> Type reddit.com/ -> Enter key

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

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

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

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.

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

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

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

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.

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

No, I didn't read the article, nor did I claim or indicate that I did in any way. Yet here is yet another front pager about Chrome experimenting with something that Safari on iOS has done for some time, as if people just discovered fire.

Well, a 'sunday' front-pager. Meaningless. Monday morning all this lint will be swept away once more than a couple thousand readers turn their attention back to HN.

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

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?

Reply on news.ycombinator.com