Chrome hides www and https:// in the address bar again
bleepingcomputer.com
bleepingcomputer.com
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.
If you want it to stick out awkwardly I feel like they just need a opened lock in red icon.
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
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.
shadow files (._*) and directory clutter (.DS_Store/desktop.ini) are one solution, but they're ugly and frustrating, having separate areas in the filestore (like a resource fork, but designed to be ephemeral) are a much more sane solution.
At this point, it might as well be a "resource fork" or whatever you want to call your secondary file contents at the fs layer shrug
The only real reason i care is for vim file detection (in Linux). How sad is that? :'(
APFS has good extended attribute support. Whereas linux extended attributes might be limited to 64k, APFS extended attributes can be significantly bigger (I just created a 32MB one).
The xnu kernel has some ugly hacks (pre-dating APFS) which make the "com.apple.ResourceFork" available as a file ("/..namedfork/rsrc").
On HFS/HFS+, file/..namedfork/rsrc will always exist (and usually be empty). on APFS, file/..namedfork/rsrc will generate an ENOENT error if the resource fork/attribute doesn't exist.
Files had a type code and a creator code. The type code told application whether they could open the file. The creator code told the Finder which application to open when the file was double-clicked.
It was impossible for the user to change either (in the stock OS).
That's... much, much worse than dot extensions.
The type codes were editable, in the sense you could choose the default app you wanted to open files of that type, which is really what you'd want to modify most of the time.
BTW, I think you're referring to the 'creator' code, not the 'type' code. The 'creator' code determined which application would open a file when it was opened. And it was per-file; I don't remember any mention of a system-wide 'default application' or anything like that.
This was actually rather nice in practice. It meant a JPEG image created by e.g., GraphicsConverter would be opened by GraphicsConverter when double-clicked; whereas one saved by a web browser would be opened in the web browser. But either could be dragged into either application in order to open the web-browser-saved image with GraphicsConverter.
The Finder maintained a 'desktop database' which, I believe, was used by the operating system to determine which Applications were able to open files given their type. This was updated automagically, so given a floppy disk with an application on it, and a file that could be opened by that application, the user could insert the disk, double-click the file and the application would be launched to open the file--even if the application was previously unknown to the machine in question.
Power users could use ResEdit or some other tool to change such attributes of a file.
http://vintagemacmuseum.com/macintosh-type-and-creator-codes... has some more info about the system. Also https://tidbits.com/2009/09/06/snow-leopard-snubs-document-c... which remarks on the system's retirement in OS X 10.6.
Reminiscing about all this makes me remember fondly how much better the experience of using a Mac back in the 90s was compared to computing nowadays!
I find it amazing that despite the industry's trend in recent years away from string-typing and towards static-typing, metadata-in-file-name just won't die.
I'm all for removing old ways of doing things that were bad, when we have a better way to do them. What we have here, with type-in-extension (and visibility-in-prefix), is a legacy system for which there is so far no workable substitute (on any system, much less all systems). A person can't be fully computer literate and not know what extensions are.
UTI has some nice features, but it's still based on extensions (which are keys into the database with the information you really want). This weird halfway point, where every user has to be a "power user" of the filesystem in order to not break their own files, will live on until either types are made primary again, or until we're all reduced to using standalone "apps" with app-specific storage and we can't share any data except as the app author decided to allow.
That's fine, not every task that is possible must be directly supported by the OS - third party apps to fiddle with data that is considered non-primary workflow like that is OK.
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.
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.
Perhaps this distinction could be made more clear by switching to reverse domain name notation.
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).
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
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.
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?
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.
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.
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.
there is no internet standard for how a URL should be displayed in a browser.
So, you fully admit to making a slippery slope argument?
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.
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.
"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."
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.
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.
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.
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.
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.
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.
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.
Heck, if you use `fr.example.com` and `en.example.com`, those would also work.
To get there they have to disassociate what’s shown in the URL bar with how and where the content comes from.
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
More like thin wrappers around Webkit. You can actually install alternate browsers on Android, you know.
On Android Google will spy on everything you do, no matter which browser you install.
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.
There's also just no reason for this. It's unnecessary overhead to showing the full URL and there's no benefit.
You probably mostly know technically fluent people, and think ‘my mother’ is a euphemism, but it's not. If we can get to a world where she can see an unfakeable padlock and read ‘facebook.com’, rather than remember whether it was ‘https:’ or ‘https.’ in the URL bar, and which parts of the string of letters to skip, we've made her life less hostile.
The corresponding problem you're complaining about is incredibly trivial in comparison. If you're actually editing the URL, you see the whole URL. If you need to know these implementation details, they're vastly easier to find than, say, HTTP headers.
If you copy the URL, the fact that what you copy is literally different than what you're looking at is confusing. You copied "example.com", so why does the clipboard now contain "http://www.example.com/"?
> If we can get to a world where she can see an unfakeable padlock and read ‘facebook.com’, rather than remember whether it was ‘https:’ or ‘https.’ in the URL bar, and which parts of the string of letters to skip, we've made her life less hostile.
Whether the URL bar shows "https" or a padlock has nothing at all to do with the unnecessary confusion inherent in Chrome requiring a second click on the URL bar to reveal the full URL.
Nothing in your comment even begins to explain the benefit in presenting a fully-editable text field that allegedly shows the URL, except it's still hiding information that is only revealed once you try and perform another text editing action. If someone looks at the URL bar and sees "example.com", and they click on it and it immediately turns into "https://www.example.com", that doesn't harm them in any way. In fact, that's exactly how mobile browsers such as iOS Safari have worked for years and nobody's complained. Chrome is deliberately doing something different than all precedent and there's no obvious reason for this beyond their desire to be unique.
Hiding the protocol is also stupid if it's still shown for other protocols, like ftp or http.
Just put it in the OS certificate store? It's worked like that since Chrome was released.
(One such issue were certificates with a common name and no subject alt name.)
Some people hit these which I had to solve for them because it was pretty opaque until Google started indexing the error message properly: https://security.googleblog.com/2016/10/distrusting-wosign-a... and this one https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
There are people whose entire workflow is constantly bypassing self signed certificate/browser warnings, and the interface to undo an override is persistently changing as well. The method to get the certificate details of the site you are connecting to (which helps for self signed soup) has also been changing constantly over the last 5 years for Chrome, but for browsers like Firefox have basically been the same thing. e.g. Chrome 56 https://www.ssl2buy.com/wiki/how-to-view-ssl-certificate-det... has a totally different procedure to what you can do in Chrome 75, where it is back in the site details drop down (where it was before Chrome 56).
Really it's any case that you navigate to a site and get the Chrome error page for a TLS related reason. Many people who administer enterprise applications are not technical people and so they don't even know this sort of thing is coming. They get other people to do the technical/software updates but are generally just there to keep the system alive and get value from the system, but Chrome doesn't clearly explain to them what happened and they go to IE/Firefox and it works fine. For most people this is the limits of their troubleshooting and they have no recourse. Then on top of it the procedure or documentation that they used last time (often generated by a technical resource they may not have anymore) no longer works and they are stuck. It's a very frustrating experience for a lot of people and I wish they handled it better.
The only way a Chromium fork works is if the team is willing to stop merging after they fork and take over development themselves.
Brave isn't a fork, though, it's a downstream consumer of Chromium.
> The only way a Chromium fork works is if the team is willing to stop merging after they fork and take over development themselves.
I mean, that's what a fork is, so yeah?
I don't think Brave demonstrates much about that situation.
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!).
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.
>there seems to be a disconnect between the chrome devs and users
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.
It will consider google-payments as being trivial and hide it? I may have misunderstood something, the article mentions clearly only "www" and "m" and if anything it made me read more and it seems like they no longer hide "m" (which make it much better because now the only mistake can be made only between www and without it, which should be quite rare).
> What I'm saying is that this has nothing to do with Google being out of touch with users as the GP suggests.
You said that:
> seeing the domain and nothing else likely improves security
Sorry but you are arguing that it will improve security. I'm asking you to prove that it does improve security.
I'm not arguing whether it's in touch or not with their users, it's meaningless, security is not an esthetical choice.
My opinion on that bit isn't cemented in yet (why I used "likely"), but people are fooled by real-sounding domain names. They don't know what TLS is and they don't know what the prefix is, but they do know the difference between "google.com" and "avs.net".
Sure but hiding www won't make google.com or avs.net more obvious.
This is an example that I wrote in another comment.
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
The dangerous one didn't change... the not dangerous one did change but doesn't matter really. They are just as similar.
Its great chrome will do the same. Every browser should. Low level technical details and historical artifacts should go die in fire.