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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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?).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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...
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".
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.
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.
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."
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.
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.
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.. :)
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!).
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.
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
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.
> 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.
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.
