Hacker News Reader

Comment by jwr | Hacker News Reader

This is idiotic and harmful. We already lost information about the protocol, because somebody believed it is "too complex" for users. Now we're losing other parts of the URL. It's making a joke of the SSL/TLS padlock, too — what exactly is the padlock supposed to tell me? It used to signify that a "known authority" certified that I'm connected to whatever I see in the URL bar. But now that browsers take liberties with modifying the URL bar as they see fit, it becomes increasingly meaningless.

View on HN

You can still click and see the whole URL. This is just making it easier for the average user to see the most important thing to them, which is the domain name.

It's not like they're just changing stuff randomly. The TLS padlock change has been going on for a while now, and not without reason. As we get to a point where almost everything is served over TLS it doesn't make sense to tell the user every time. It makes more sense to only notify them of the exceptional situation where we're on an insecure connection.

The certificate authority system is terrible, but it's what we have for now. There's been some advances to help make it better though. CT for example, ensures that if anyone starts making fake certs we can all see it at least.

I suspect (and hope) that browsers will slowly transition to using trusted spotters to verify certificates in addition to (and eventually instead of) authorities. If you remember a few years back when moxie marlinspike made that promising, but underspecified cert verification system that relied on the user supplying a list of trusted verifiers and the browser basically goes to each of them asking "I see cert 88:A4:etc" for domain "google.com", do you see the same thing? The idea was to make it really hard to MITM someone since you'd also have to MITM every verifier the browser asked. Not impossible, but probably harder than getting a fake cert under our current system.

Clicking doesn't reveal the URL. You have to click and use the left arrow key, at which point the protocol and www prefix appear.

Just like when Chrome hid the protocol part of the URL, you can even click in the URL bar and copy it without seeing the protocol (or, now, www prefix) at all. I think it results in a confusing experience when you paste it. (Ordinary users will say: "I copied example.com but I pasted https://www.example.com … why??)

Or double-click - basically get into the editing mode of the URL bar.

What other mode would I be trying to access?

> You can still click and see the whole URL. This is just making it easier for the average user to see the most important thing to them, which is the domain name.

Thanks for adding a step when that user's most important thing is telling us folks supporting them what the actual URL they went to. From other folks in this thread[1], it isn't as simple as just a click.

1) https://news.ycombinator.com/item?id=17928598

> This is just making it easier for the average user to see the most important thing to them, which is the domain name. It's not like they're just changing stuff randomly.

Can you link to the user study or general cost/benefit analysis or something else saying it's not random? I'm having a hard time concluding that the cost of removing parts of a domain name only in some cases is outweighed by the benefit of removing a few characters from the user's address bar.

> "This is just making it easier for the average user to see the most important thing to them"

This is exactly the wrong way. The domain name system is simple, easy to learn, partly, among other, exactly because it is without ambiguity. It has been an essential part of our lives for several decades by now and users should be expected to undergo the effort of looking into how it works for 5 minutes once in their lifetime. (Arguably, parsing a URL is an important and essential skill nowadays, like adding.) Obscuring it and introducing ambiguity doesn't only not help, it is an essential hinderance to understanding.

99.9% of users have no idea what any of the words you just said mean. The change was made for them, not for you (the .1%)

So they can be hacked in serene bliss. A stupid decision.

Hacked how?

>The change was made for them, not for you

Except, those same users also don't care about things in the address bar. So the change hurts the group of users that actually do care.

They didn't care so far because it was so confusing. The hope is that by showing something that's user-relevant (the name of the website name and the security level), it will become more useful for the average user.

Why should a user see: https://www.wikipedia.org/wiki/Canada?utm=asdioasd&arg=j210d... when all they care about is "Wikipedia.org/wiki/Canada"?

the only thing you've changed is now those 99.9% users can't even find the information they need to ask the .1% for help

great work

According to Apple, they care about "wikipedia.org", only.

Because arguments aren't always useless like in your example. Might as well just do away with the whole URL bar and just have a green checkmark if Chrome thinks it's the site you want.

I mean, why should a user see "Wikipedia.org/wiki/Canada" when all they care about is "This is the Wikipedia Page for Canada"?

I know you’re being sarcastic, but if chrome could, with perfect accuracy, indicate if this was “the site you want”, why not do away with the url?

Mind you, I’m not suggesting to do away with linking, as some rando suggested this implies. (While chrome doesn’t show the protocol prefix, it still copies the prefix when you copy the url, so imagine a similar ui.) But for most users, wouldn’t a ui that shows “server identity” in some more user-coherent way be what they want?

In particular, do subdomains help or hurt phishing detection?

If we could, I'd be all for it. Have an option that says "show URL bar or not" and by default hide the URL bar, optionally show the whole thing. Especially on space-constrained devices like cell phones where every pixel counts. Just show the page's title.

I think we're a long way away from that ideal, though, and some web pages may not be designed with this ideal in mind.

You're making a hypothetical based on "with perfect accuracy"... but the much simpler change here (www vs. no www) is not done "with perfect accuracy", as clearly outlined by a bunch of comments in this thread.

So you're saying we should show all users www., just because that one site in a billion that shows a different non-www. page, for that one user in a million that would even notice that difference? Chrome is a browser for the mainstream people. The feature you're asking for is for power users and extreme edge cases.

I like how HN cuts off the end of that url.

http://www.example.com

https://www.example.com

http://example.com

https://example.com

do not have to be the same website and there are cases where it isn't the same site!

Which site you visit does matter and not just for internet banking. If it becomes that easy if we hide things maybe we should hide the half of the traffic lights as well.

Those examples don't prove anything. First off, the http ones would appear different, they would have no lock. And 99.999999% of websites don't have a different www. and non-www. page. Showing www. for that 1 in a billion site, for that 1 in a million user, is insane.

I wonder if there is any research or evidence that users actually find “www.” confusing enough to go through the trouble of removing it.

What if the user sees "Wik1pedia.org/wiki/Canada"? Or "аррӏе.com"?

Hiding random parts of the address isn't going to make browsing the web better. The main purpose of URLs is for hyperlinks, not as a highly intuitive user interface. Users who don't know how URLs work don't care what is up there. They only care that what they are looking at is what they expect, and a way to get to where they want to go. And that's a complicated problem.

The URL bar hiding thing isn't for users, it's for Google to push Google search. That's why they attempted to remove the URL bar entirely four years ago and replace it with a search bar.

Don’t Firefox and Safari also have a single bar for searches?

Yet neither company runs a search engine. I don’t suppose it’s possible this is just better for most users?

Firefox will allow you to search via the address bar, but it still has a separate search bar to the right by default.

This doesn't appear to be the case?

[1]:https://www.techworld.com/download/internet-tools/firefox-63...

It still exists, but the default changed.

Now you can go to menu -> Customize and drag it where you want.

Also, if you go into about:config and turn off keyword.enabled, the address bar will no longer search.

It's very useful if you don't want to Google internal/client URLs just because you accidentally copied a space at the start or the hostname doesn't resolve in your current environment, etc.

Users don't see that.

Expecting users to use the URL bar to detect phishing via homoglyphs is insanity.

Right. So messing with the URL bar is pointless. If people actually don't like it, get rid of it, but provide some other means to establish authenticity of what you're looking at.

That has nothing to do my argument. Just because people can't detect homoglyphs doesn't mean we should keep overloaded urls and shouldn't strive to make them more user friendly.

There's still value to be gained from having easily readable urls.

Because there is a huge difference between those two:

  https://en.wikipedia.org/wiki/Canada
  https://fr.wikipedia.org/wiki/Canada

If the browser absolutely 100% of the time knew that difference and showed "Wikipedia FR > Canada", wouldn't it be much simpler for the average user?

The browser could even show specialized UI such as "FR" as a clickable dropdown menu to allow users to switch languages. Chrome already does this for searching a single website through the address bar (type domain.com TAB)

Basically these changes are not thought for you. You are not representative of the average Web user.

Maybe it could show "Canada - Wikipedia" like the page authors intended as a title. Maybe if the page authors want to have links between languages, they could code that in a standard markup language themselves.

These aren't decisions for a useragent to make, and there aren't enough browsers out there that people have a reasonable choice.

Bastardising the url isn't a solution to anything, it's a step towards something that Google, not users, want (in making AMP "trivial").

A useragent is literally a user's agent, it is supposed to help its user browse their target website. It is not supposed to help the target website show things to the user.

Hiding the URL would be a terrible idea, no matter how much "simpler" it would be for the average user: it would either only be enabled for a handful of websites chosen by Google (which would mean having an inconsistent UI) or create a lot of security issues (what if someone creates a website and manages to also display "Wikipedia FR" with a similar layout?).

No, it's really important to retain all those dots and slashes. This is not sarcasm. I'm being completely serious when I say this. It's really easy notation, and the differentiation of context for dots, slashes, question marks and hashtags is really useful.

  Wikipedia FR > Canada

I look at that angle bracket with the white space, and I get chills. And I'm not even drawing attention to that oh-so-glaring omission of the /wiki/ context. Truly horrifying.

Repeat. This is not sarcasm.

Dark roads ahead, friends.

It matters because deep-linking is possible on the web.

Hiding it just seems like a trivial UI matter that makes things slightly more obnoxious when you do care.

I'd be surprised if only showing the domain vs domain+path made any difference on phishing results.

I don't think these little tricks do much for the user. For example, browsers now highlight https websites with green in the url bar and show a little lock icon. But how is that actionable information for the user? To what extent does that mean you can trust that website, and how does the average person interpret it? Phishing websites use https, too.

I would avoid stealing any pages from Safari's UI. That browser doesn't even show favicons on browser tabs to let you quickly distinguish them.

All they actually care about is "Wikipedia - Canada". Which is right there on the page.

99.9% of motor vehicle users have no use for airbags. We still keep them for the .1%.

This is a very bad analogy. Anyone in a car crash potentially benefits from airbags without knowing anything about them (or even if they exist at all).

The 99.9% of people who don't even know the difference between www and non-www will never directly benefit from seeing www, ever.

We must avoid friction between two types of user, 99.9%er and 0.1%er. We could have separate browsers aimed at each.

One browser should be dead simple, secure, and streamlined, aimed at the 99.9%s. Maybe it could be named after a metal.

Another browser, for the 0.1%s, should include technical arcana on screen and have more mutability, perhaps even at the cost of some performance and security. This one could be named after some kind of canid.

> The 99.9% of people who don't even know the difference between www and non-www will never directly benefit from seeing www, ever.

You don't need to know the difference to be able to read the URL off, potentially to someone who does.

It's not impossible (though it's not a good idea) for “example.com” and “www.example.com” to both host web content, and whether or not they know or care about the meaning of the domain name, someone accessing one should be able to, in the event they have a problem, be able to read off which one they are accessing to the person trying to help them resolve the problem.

unless they need help and get one of those .1 percent to help them out

Airbags have utility for 100% of motor vehicle users.

Well technically that includes planes and motocross also.

and bicycles!

There are lots of airbag clothes for motorcyclists now. Apparently they work quite well.

Let's dumb down the internet even more because non technical users feel confused. Maybe we can actually remove the url field and just let the isp decide where they should go? They could offer a choice of 10 popular sites, like TV channels.. :)

Actually Google's long term plan is to do away with the URL completely, they just haven't figured out how yet.

https://www.wired.com/story/google-wants-to-kill-the-url/

We're always going to need to see URLs. They're not going away. They're just talking about a better default view to show the user relevant information about where they are, which would be a good thing.

Being generous, maybe half of users can look at a URL and immediately identify the domain they are on. That's terrible, and goes a long way to explaining why phishing attacks are so prevalent.

I'm actually pretty excited to see what they come up with. If it's even marginally better than what we have now I'd be all for it. I'm guessing they'll end up showing some combination of the domain and page title by default (which might incentivize more sites to FIX THEIR GODDAM TITLE SCHEMES!).

> We're always going to need to see URLs.

I can see the future now: User enters his target (mybank) into the Google search bar on his Google Android device, the device opens Google Chrome with the Google amp page form mybank already loaded. The user never has to worry about urls or where exactly he is entering his banking information and login critera. Google makes everything a clean and seamless experience and user never has to leave its warm embrance.

Add eyeball tracking into this mix, and we can "allow" users to "experience" unskippable ads.

In all seriousness, I have no doubt this is due largely to Google's frustration at Ad Blockers. If there is no URL, and you're in the Google Garden protocol, there is no way to block ads, or at least no way to NOT download them.

AOL keywords all over again. It's all about building a moat.

I also wouldn't put it past the average consumer to prefer 'installing' a website/webapp into their browser as they do an app..

Great idea! Hey, since these are non-technical users, why don't we just eliminate those pesky hard-to-use computers and just put the whole thing inside their TV? Y'know, kinda like 23 years ago... https://en.wikipedia.org/wiki/MSN_TV

You're missing jwr's point. He's arguing that this is harmful for users, especially the ones who don't know what the words mean.

If I were solving this, I'd instead push to eliminate "www" altogether, not sweep it under the rug. It was useful circa 1996, when users might plausibly be using something other than the WWW with a browser. But it has become entirely vestigial.

How can you eliminate "www" altogether? It's just a subdomain like any other now

It's actually very useful for isolating access to the root of the domain. Say for instance you use a third-party SaaS/CMS to host your website and have other services on other subdomains. If it's hosted on the root of the domain it had more power than if it's on a subdomain.

Why not drop .com then as well? Most sites are on .com domains after all.

It is exactly the same issue.

A domain is a domain. Google is arbitrarily dictating your CNAME from the user's perspective.

What if you don't serve your site off of mysite.com is google going to automatically try again at www.mysite.com?

What if you have distinct content at both domains?

This decision is stupid.

It's not the same issue at all, in that domains with different suffixes are controlled by different people while foo.com and www.foo.com are controlled by the same people.

If you have an example of somebody who needs to serve different web content for foo.com and www.foo.com, I look forward to seeing it. But I've never seen one, and when I've seen it happen accidentally it's due to idiocy.

> while foo.com and www.foo.com are controlled by the same people

Sometimes. Far from always.

In some environments, `www` may be under an entirely different administrative domain, with lesser authority than the top level domain which is delegating web services to the `www` group by way of creating a dns record and/or adding an http(s) redirect to the parent domain.

Having some string values arbitrarily considered trivial is dangerous.

See: lbl.gov has address 128.3.41.146 vs www.lbl.gov has address 35.196.135.136

The root domain points to hosts at the lab. The subdomain has been delegated off to Google.

Isn't that simply due to internal politics? Whoever owns foo.com might delegate www.foo.com to someone else, but they ultimately control both.

Either way, www.example.com and example.com can differ in terms of IP address, underlying hardware, actual website content, and probably other things I don’t know. They are different URLs. It seems problematic to assume they are the same.

Not at all. People already assume they are the same. And they have for 20 years. Nobody reasonable serves up different content on the two URLs. Anybody clueful redirects one to the other. The only reason they're separate is that a) the web wasn't dominant when it was introduced, and b) technology of the time made it hard to manage traffic in ways we can now.

> Nobody reasonable serves up different content on the two URLs.

The third and ninth comments in the linked bug present real world examples of this behavior.

The 9th comment is explicitly described as "bad results"; it's about somebody who doesn't have a redirect. So that for me is in the "unreasonable" category.

The 3rd is about pool.ntp.org, which is a random ntp server, and which shouldn't be serving up web content. They did happen to pick www.pool.ntp.org as the URL for the docs on the NTP Pool Project, but if "www" never was a thing, the would have happily picked something else. E.g. poolproject.ntp.org or ntp.org/pool/ would have been fine.

It's due to different groups controlling different parts of the infrastructure, allowing for separation of privilege -- and is the whole reason www even existed to begin with.

Often these separate groups aren't part of the same organization. They're a different organization or contractor paid to maintain a web presence.

Yes, but those are decisions made by whoever controls foo.com. This may not be a good decision by Google, but I don't think they should be held responsible for a decision that was made by whoever controls foo.com.

This is completely backwards, because Google just made this decision _now_!

This may be true for LBL, but it's not necessarily so. They don't serve different content, and I don't see anything running on lbl.gov that couldn't be handled.

These string values are already considered equivalent, which is why Chrome is making this change, and why every reasonable site has one redirect to the other.

I realize it is an important distinction, I'm glad you do as well.

Just as ftp.mysite.com is not mysite.com and mysite.com in not mysite.io and http://mysite.com is not https://mysite.com. You get the point.

They are all different and important in my opinion. Any argument that hiding the "www." part makes it easier for the user is equally applicable (and wrong) to ".com"

You can keep repeating your point, but if you want to convince me, you'll have to actually address my demonstration that the two are in fact not equal in practice.

From the bug report that started this thread:

http://www.ntppool.org is not http://pool.ntp.org

and

https://citibank.com.sg is not https://www.citibank.com.sg

and

https://m.tumblr.com/ is not https://www.tumblr.com/

Yet Google makes them all appear to be the same.

There are lots of other odd filtering behaviors in the issue if you want to check out the comments

For example, should:

www.www.www.subdomain.www.www.www.domain.com show as subdomain.domain.com

How is that right?

How does making those two destinations appear to be the same thing make the user "safer" under any stretch of the imagination?

I'm not arguing for Chrome's implementation. I'm saying we should do the more useful but harder thing of just not using "www" as a thing in browser URLs. They have correctly identified it as redundant, but instead tried to fix it by being too clever.

As I mention elsewhere, the first two are bad examples. (In fact. ntppool.org and www.ntppool.org are the same thing.) The third is a hack from the era where responsive design, browser sniffing, and polyfills didn't exist. It should probably die too, but doesn't have to here. The m.tumblr.com name is distinct from tumblr.com and is of the form I think better. Note that they didn't use www.m.tumblr.com.

> domains with different suffixes are controlled by different people while foo.com and www.foo.com are controlled by the same people.

This happen fairly often in universities and some other organizations that can have convoluted structure.

Yes, why not drop URL's altogether then? Why display such "technical" things for the plebes?

Sure, "I'm feeling lucky!" should suffice /s

> Most sites are on .com domains after all.

Most sites in English, and even that is doubtful.

There's a full world out there of people and businesses using ccTLD like .fr, .nl, .co.uk, .hr, .rs, .es, .jp...

With "only" 46.5% of all domains being ".com" I guess you are technically correct. When the next highest TDL (.org) rings in at only 5.1%, I think we can agree the the overwhelming majority of sites are based on .com.

Of the TDL you mention the top one is .jp at less than 2%. If you remove the qualifier under the .uk TLD you get an additional 2%. The rest don't make the chart.

https://www.statista.com/statistics/265677/number-of-interne...

As I recall, there are some reasonable dns-related reasons that one might prefer www (or any subdomain) to the bare name.

Modern solution to these issues is having SRV record on appropriate protocol sub-domain which AFAIK (and somewhat surprisingly) is honored by most modern browsers.

Do you have more information about this?

https://jdebp.eu/FGA/dns-srv-record-use-by-clients.html

Browsers don't use SRV records for HTTP. With them one wouldn't need www subdomain CNAME hacks.

> If I were solving this, I'd instead push to eliminate "www" altogether, not sweep it under the rug. It was useful circa 1996, when users might plausibly be using something other than the WWW with a browser.

No, it was useful when abstracting machine identity from domain names such that there was a many-to-many relationship was less common, so “www” was the most specific domain name element for the server being accessed. (And a system that needed more than one server might have a homepage on “www”, and various subsites and apps on “www1”, “www2”, etc.)

OTOH, there may be places that still allocate servers that way for simplicity.

Citation needed.

Did you ask anyone? Did you do any research?

Presumably your question is for the Chrome team, and I'm gonna assume the answer is: yes, of course they did research. They did research for the padlock, etc too.

This excuse is used far too often to justify why things have to suck.

This makes me think that developers should start moving away from Chrome. Firefox, for instance, still supplies the full URL.

Well, might as well drop then entire stuff after the domain.com/{dump all this out} (the file path) since non-techy people don't really care about it. All they care is about clicking links and navigating...

/end sarcasm

Doesn't Safari on macos do this?

I'm a Firefox user so I don't typically use Safari, but I just did try it right now and I guess they do!

There thankfully is a setting to show the full url, but yeah, Safari on macOS does that by default. The change occurred around Lion (give or take a major version) if memory serves me well.

Maybe the address bar UI will next hide query string parameters because they are an implementation detail? So Google News would be displayed as "news.google.com" instead of "news.google.com/?hl=en-US&gl=US&ceid=US:en".

From the business point of view that would make perfect sense. The user wont be able to remember the url and even second guess it so that would need the "help" of google, cause everyone knows that "google is your friend".

TBH, so long as there always remains the option to show the full URL, I'd be totally fine with completely hiding it by default. Safari all but does that right now.

After 20 years, the number isn't 99.9%. But:

Should chrome redirect all DuckDuckGo queries to Google.com because 99.9% use Google anyways?

Yes, and it should also pretend that you searched on DDG by imitating all interfaces and developer console records.

99.9% of users don't know either way. The change neither improves nor harms their experience, it merely obfuscates what's actually going on under the guise of "user friendly."

Anytime the "average user" or numbers like "99.9% of users" are mentioned, red lights should go off. These kinds of claims are condescending, often untrue, and rarely based on facts.

> It's making a joke of the SSL/TLS padlock, too — what exactly is the padlock supposed to tell me

That's why they're getting rid of it.

https://blog.chromium.org/2018/05/evolving-chromes-security-...

The team that implemented this change, also talk about how women confuse the padlock with an icon of a purse...

https://www.wired.com/2016/11/googles-chrome-hackers-flip-we...

It's a sign that the Chrome team is too large and should be assigned more meaningful work.

Google wants to destroy the URL so the only way to find something will be via Google... They also want to tie your identity to each webpage that you author via a certificate so that all governments can clamp down on fake information or have the opportunity to in the future.

Given the adoption rate of SSL, I imagine the padlock itself will become useless even without Chrome's changes. Does it mean anything if almost every website has it?

ideally it means no passive snooping

The clearly announced intent of at least Mozilla and Google (and I'd assume Apple and Microsoft but I don't pay as much attention) is to focus on highlighting the insecure state because that has much better security UX. Labeling one site you visit today "Not Secure" stands out. With luck it might be enough that you don't type in your credit card details.

That's why Chrome is moving away from showing the padlock to displaying "Not secure" for sites that aren't secure. The padlock will be going away entirely; secure is the default state.

The padlock was already meaningless.

It started being meaningless thanks to Let's Encrypt. Before it meant you had to show your ID and banking info to a "reputable" corporation for them to make a cert for you. Yes I know I know, not always the case, but...

LE means that the mantra "if it's https then it's a secure and reputable website" is now outdated.

> Before it meant you had to show your ID and banking info to a "reputable" corporation for them to make a cert for you.

No it didn't. Let's Encrypt made free certificates easier to get, but Let's Encrypt doesn't do less verification than some other CAs/some of their products.

> Before it meant you had to show your ID and banking info to a "reputable" corporation for them to make a cert for you.

No, it didn't. DV certs never meant that (EV certs did and still do, but LE doesn't offer EV and EV isn't and never was necessary for the padlock.)

are you that Comodo guy?

No, the padlock means that you are likely connected to the website that the URL bar shows you. This is useful and should not be discarded because of condescending ideas about "average users". It also has the advantage of being easy to explain.

Some people assign additional meaning to the padlock, which should not be done. It doesn't mean you are talking to your bank, it only means that you are talking to the website shown in the URL bar and that reasonable (simple) checks were performed to make sure that is the case.

I'd suggest we invent something better before we start breaking it.

How do you verify the authority owns the content? For instance: AMP urls serve content from a different authority than the one that produces the content.

Google wants to introduce Web Packaging to solve this: https://youtu.be/pr5cIRruBsc?t=543

Yikes. So long first party serving.

Reply on news.ycombinator.com