Honestly, I suspect the motivation is either the Chrome team is too big and people are bored and looking for changes to make, or someone is angling for a promotion and wants to make a very visible change so they can show "impact" when they put together their promotion packet.
There are lots of developers who like distinguishing these subtle topics. I can tell you in a larger enterprise deployment most of these changes will be welcomed (yes, people do still click on bogus URLs believe it or not - FAR more often than I would expect). Or think that the url amazon.lowprice.com is an amazon website in a search result.
Folks claiming google is hiding the owner of the website forget that the actual owner of the website is reflected by the END of the domain name, not the earlier parts. In some shared hosting situations this is confusing, but in the end whoever controls the end actually is in control.
Before the change: www.google.com
After the change: google.com
Before the change: google-secure-payments.google.via.net
After the change: google-secure-payments.google.via.net
Now do it like Firefox:
Grey: www
Black google.com
Grey: google-secure-payments.google
Black: via.net
How does hiding www help with that?
It seems to me that a decent scheme to make the domain-owner more visible would be to separate out the domain and display it separately from the entire URL, the way that Safari does.
I'm not a fan of Safari's changes, but at least its easy for me to see how they could improve security -- it's a decision with real benefits, and the only question is whether they outweigh the downsides.
But it's difficult for me to imagine a phishing scenario where hiding `www` will make things better. The only scenario I can think of (where `www` redirects to a different site) is made worse by hiding it from the URL.
via.net -> google -> secure-payments / whatever/whatever.html
I mean, I'd hate it, but at least it puts the public suffix up front and centre^Wleft. And it doesn't hide and part of the URL from the user, it just mangles it (but in a way that arguably enhances the user's ability to understand WTF they're looking at).
Perhaps this distinction could be made more clear by switching to reverse domain name notation.
We've seen their influence on Chrome in the past by their devs lying about performance as justification for crippling adblocking in extensions.
Joking, but surely it's in Google's interest for the omnibar to just be a keyword search tool. Plebes don't need to know about urls.
Curious what Apple's position is.
Identity and payment are extremely important to any ordered system of social interaction. More than content itself,controlling them helps one control everything else.
I am trying hard to avoid believing conspiracy theoris about Google.
Maybe a legal requirement for intetnet standards compliance makes sense?
there is no internet standard for how a URL should be displayed in a browser.
google-payments-secure.via.net is not a google payment website despite the google in the domain name. The key part that signifies the ownership / identify of the person hosting the site is the END of the domain, the google.com part. That is the owner of the web property, not whatever appears before that.
The problem here is that Google is in control of the solution and the solution is designed by them without consulting everyone else and in a way that would be advantageous to their long term dominance and prosperity.
I don't trust google and they certainly don't have my consent to shape the way I and the society I live in interact with each other.
I will say it a million times if needed. I do not trust google. Period. They ask forgiveness instead of permission and they love slipperly slops and bait-and-switch psychology tricks to get their way.
Educating people should not hide information, but instead present information in a way that is more understandable. I think the Chrone team is making URLs harder to understand.
So, you fully admit to making a slippery slope argument?
I don't like the change either, for a variety of reasons, but I don't think I'm their average user either. For the average user, seeing the domain and nothing else likely improves security.
By hiding between 1 to 3 letters?
It seems much more secure to do it like Firefox using grey for the unimportant part and black for the important part.
If anything, if "m" is hijacked (by a feature actually to use subdomains), it's less secure because now he thinks he is somewhere that he isn't.
Tried to pay off my contract & upgrade my phone on O2 UK's (mobile network operator) website.
Card transactions failed multiple times because of a blocked popup.
Ended up having to wait a week for the pending transactions to be released (£600 worth. Rang up Monzo, my bank, and they'd tell me I'd get the money released in pending state the next week which was true!).
There was an article recently about "hostile architecture" and this is similarly a "hostile software design" to prevent users from doing something the developers don't want them to do.
chrome://flags/#omnibox-ui-hide-steady-state-url-scheme
chrome://flags/#omnibox-ui-hide-steady-state-url-trivial-subdomains
chrome://flags/#omnibox-ui-hide-steady-state-url-path-query-and-ref
This is just another tiny step in that overall plan, and it is 100% evil.
Don’t waste your time trying to talk the Chrome-team into reason. You are not their customer, nor their employer. They will not listen.
If you don’t like what Google is doing, use other products. Firefox, DDG, iPhones etc.
yeah, if you don't like this change switch to a browser that has behaved this way for years
Safari added the setting "Show full website address", which does just that. I wouldn't have a problem if Chrome followed suit and defaulted to the new scheme, but gave us the option to show the full URI.
And this is why modern technology sucks.
The next change will be that it will trick users into thinking they are on are on a real site like example.com but will instead be on Google.com/example.com.
But chrome will remove google.com just like http/s.
This is really sad and dangerous for the web. I don't know why people aren't up in arms over this kind of devious behavior from Google.
If Microsoft had pulled this in the late 90s early 2000s there would have been senate hearing and talks of breaking up their monopoly.
The question is more a philosophical one. If it’s wrong that the URL doesn’t point to where files are “actually” stored. Or rather that the package delivery and package creator aren’t the same party. In my mind this hasn’t been the case for a long time now anyway.
https://amp.dev/documentation/guides-and-tutorials/optimize-...
The issue is deceit and fraud. A browser should _never_ ever under any circumstances be able to display one companies domain differently than all others. Especially when it's their domain.
Google.com, or any of Alphabet's domains, should not get special preference or treatment. And they certainly should not be trimmed out of an address for the benefit of Alphabet/Google to the detriment of all others.
I still prefer Firefox: protocol, subdomains and path are greyed out but still clearly legible. This way I can eyeball "on which site am I?" quickly (and read google-secure-payments.google.via.net as via.net for example) and still have access to the full URL in 0 clicks.
I need the whole address when copying.
I don't know if there are any scenarios in which a properly-configured website (mine isn't) needs to differentiate example.com from www.example.com. But I liked the ability to do so easily.
this requirement is handled by the "not secure" badging, which is much more obvious that requiring users to pick out the "s" in the middle of a string.
https://security.googleblog.com/2016/09/moving-towards-more-...
iframe URLs are hidden. That's great and all until you need to verify that your iframe is loading the correct content.
Yet people don't complain about these. They are happy using the dev tools to access this information that is sometimes useful for developers and almost entirely useless for ordinary users.
It's entirely reasonable to choose to host http/https traffic on a www subdomain and host entirely different services at the non-www domain.
The internet is not just http traffic. Full fucking stop.
There are plenty of systems and industries where the actual web front-end is an after-thought.
You can't cname example.org, which makes it very hard to use a CDN to serve it unless the CDN provides anycast ips or you delegate DNS to the CDN.
If they're intent on making the address bar useless, they may as well go full hog, like Apple does in desktop Safari -- the address bar shows the domain only, until you click.
Edit to add: if you type in an almost url from the screen or a screenshot, it's likely to not take you to the same page, and you'll be confused as to why. If you type in the domain only and go to the home page, that's not that confusing.
Heck, if you use `fr.example.com` and `en.example.com`, those would also work.
This change is the complete opposite of simple. Simple is showing the real URL. Complex is trying to remember in what cases Chrome hides part of the URL and trying to guess what website you're viewing.
Of course it isn't. URLs are largely made of useless and incomprehensible information for most users.
My previous employer [redacted] had its marketing site on www and actual SaaS application product on www-less. Again a case where mis-typing would be made more confusing by Chrome.
And when the person phones up tech support “ma'am, does it show the www. in front of the website?” “no” “sorry you need to retype” “it still doesn't show www.” is going to happen.
Or someone will write down the URL from the screen, and when someone else types it in, it won't work.
Oh, right, and there's the same issue with sites where https:// has a different site to http://!
If they share it from Safari with default options, the address is mostly useless, it's just the domain (and www may elided), but it doesn't even look like a url, so whatever.
If they share it from Chrome with these new options, if it's like the last time Chrome released this, it looks like the full url, but it's not:
When you go to https://example.org/some/deep/url it may very well not be the same as https://www.example.org/some/deep/url and adds an extra layer of confusion to figuring out whatever the issue is.
chrome://flags/#omnibox-ui-hide-steady-state-url-scheme
chrome://flags/#omnibox-ui-hide-steady-state-url-trivial-subdomains
chrome://flags/#omnibox-ui-hide-steady-state-url-path-query-and-ref
I just disable all of these.
There's also just no reason for this. It's unnecessary overhead to showing the full URL and there's no benefit.
"This change is beneficial." "No, it isn't." "Yes, it is." "But it isn't!" "We respect your feedback but we're implementing it anyway."
Firefox does something in the middle where it makes the "https://www." and path lighter gray, while the domain name is black.
I think this is just about ease of use and displaying the most relevant information. Regular users think of it as "google.com", not as "https://www.google.com". And the full URL is still there whenever you click through to select or copy.
Mobile browsers often elide the protocol and trivial hostnames from domains in order to economize on precious screen space of phones. Desktop browsers do not face the same constraints. A desktop browser can play to the strengths of desktop computing—taking a "desktop-first" point of view—and display the full URL with the abundant space available. See Firefox's display of the full URL with a highlighted color for the domain. Alternatively, they can be made subservient to mobile and adopt conventions established from constraints that do not exist in the desktop space.
Mobile-first is frequently damaging to new desktop software projects, but in my experience it's atypical for mobile limitations to be back-ported to established desktop software.
I introduced him to a new tool I built for internal development, and wanted him to access the locally running instance of our codebase.
Took us some time to figure out that chrome was trying to connect to https:// instead of http://, which wasn't enabled. I think it said something in the error message about that, but who reads these anyways.
I had to laugh when they started parading thier fake-human avatar "to call and lie to people".
But really, their big value item is language engineering.
"As a ____, I want to get users to our []-controlled version of our site, without alerting the user aware they are on our []-controlled version of our site."
So in this sense there are points for filling it. It's still the correct domain, so this is quite a niche user story.
It's a pretty trivial issue that has sat around for a while. While I run Firefox, I would normally distinguish what version of the site a user is on by the green lock.
While http does show a "Not secure" segment next to the URL, everything just shows as black and white in dark mode, making it harder to distinguish at a glance.
SEO departments in my experience still insists that the www subdomain is necessary (e.g. they have no idea so better not touch it), yet Google instead of publicly coming out saying that it's pointless goes as far as hiding it. I don't get the point.
To get there they have to disassociate what’s shown in the URL bar with how and where the content comes from.
Meanwhile most URLs around the web have UUIDs or other garbage appended to the end for the sake of tracking, which I doubt they intend to do anything about any time soon, so what even is the point of hiding the protocol and a single subdomain? Just leave the URL alone.
Hiding the protocol is also stupid if it's still shown for other protocols, like ftp or http.
Its great chrome will do the same. Every browser should. Low level technical details and historical artifacts should go die in fire.