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%)
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.
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"?
great work
I mean, why should a user see "Wikipedia.org/wiki/Canada" when all they care about is "This is the Wikipedia Page for Canada"?
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?
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.
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.
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.
Yet neither company runs a search engine. I don’t suppose it’s possible this is just better for most users?
[1]:https://www.techworld.com/download/internet-tools/firefox-63...
Now you can go to menu -> Customize and drag it where you want.
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.
Expecting users to use the URL bar to detect phishing via homoglyphs is insanity.
There's still value to be gained from having easily readable urls.
https://en.wikipedia.org/wiki/Canada
https://fr.wikipedia.org/wiki/CanadaThe 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.
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").
Wikipedia FR > Canada
Repeat. This is not sarcasm.
Dark roads ahead, friends.
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.
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 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.
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.
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.
The third and ninth comments in the linked bug present real world examples of this behavior.
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.
Often these separate groups aren't part of the same organization. They're a different organization or contractor paid to maintain a web presence.
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.
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"
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?
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.
This happen fairly often in universities and some other organizations that can have convoluted structure.
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...
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...
Browsers don't use SRV records for HTTP. With them one wouldn't need www subdomain CNAME hacks.
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.
/end sarcasm
Should chrome redirect all DuckDuckGo queries to Google.com because 99.9% use Google anyways?
Did you ask anyone? Did you do any research?
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.
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.
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.
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.
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.