I use Firefox anyway and I would be fine with hiding the https:// and the green lock shows its https anyway but I do not get the subdomain hiding, not on desktops, tablets, phones with enough screen space anyway. If its really limited then maybe with some symbol that indicates that there is something missing there.
This is extremely annoying for a project I'm working on that involves subdomains. If I set nginx to redirect `example.com` to `www.example.com` I want to verify it in the browser.
my chrome hasn't updated yet, but my understanding of this change was that you could display the full unmolested URL by simply clicking in the address bar. is that not the case?
I absolutely do not want it to hide any URI schemes or subdomains at all. (I am able to change these settings in Firefox, at least. I could also disable Unicode rendering for the domain name, but to disable Unicode rendering for the filename I had to write an extension.)
By default, Firefox's address bar hides the http:// scheme but shows the https:// scheme (to emphasize that the connection is secure). Firefox users that want to see the http:// scheme can set the "browser.urlbar.trimURLs" about:config pref to false.
Google must really hate URLs. My search results recently stopped showing the full path of the URL, just the domain name. It was a huge pain because I was looking for an item at Ikea and couldn't tell if a result went to their American site or to their UK, Saudi Arabian, Qatari, etc. site (apparently the same item can have small differences in different countries— I almost bought the wrong lightbulbs because the UK version of my lamp uses a different size bulb).
Google sees folks falling for google-secure-payments.google.via.net type URLS. They see all the gaming people do with URLs in search results (including abusing the names of other brands like Amazon).
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.
I'm wondering how the particular address bar change helps alleviate this though. As I've seen it implemented, the only subdomain they'll "elide" is www, so if it is google-secure-payments.google.via.net it will still show as such in the address bar, not as via.net. So I don't understand their reasoning in how this will help from a security standpoint.
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.
> 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.
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
Seems to me like the same trick is available.
Now do it like Firefox:
Grey: www
Black google.com
Grey: google-secure-payments.google
Black: via.net
Warning: Check the black portion of the URL and make sure it's the right one!
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.
URLs represent and identify content,controling them means you control content. In the short term these changes mean little but in the long term this will benefit google immensely. Google just loves slippery slopes.
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?
The focus of this change is to improve the identification of content. This coupled with payment has been subject lots of fraud where users misled about the owner of a website.
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.
There are other ways to do this that do not hide parts of the URL.
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.
That's what google uses as an argument too and I am too familiar with the problem.
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.
Legally requiring internet standards compliance would help in some ways, but imagine the hurdle that creates for future startups who have something different and maybe better in mind
Well, claiming that it is compliant even though it isn't, is false advertising, so that is how it should be applied, rather than requiring compliance even for the thing that isn't supposed to be. They already require warning labels on some stuff, so it should be required that warning label too, then, maybe.
They can propose the change as an internet standard like everyone else before lettig users interact with that product? Hurdle? Yes,but the cost-benefit analysis seems obvious here.
Off topic : there seems to be a disconnect between the chrome devs and users. Another instance was the automatic signing in to chrome incident. I've lost trust in the chrome team and have switched to Firefox full time and honestly there's nothing that I miss. The firefox devs seem to better understand their users, frequently blog about changes that positively impact users. I have a lot more faith in firefox even though it's not perfect (mr. robot incident and others).
I think the chrome team just considers its users to be your average corporate america employee, and no longer considers developers or tech literate people to be their main market.
I doubt that, because the number of times they completely ruin chrome as an intranet browser in the last few years with TLS handling, self signed cert handling, and general settings window changing malarkey shows that they are not even catering to that market very well, especially when they add a workaround and take it away in a very short window which for better or worse is often much shorter than most large organization's change control windows. Firefox generally keeps most workarounds working for as long as I've needed to worry about it, but Chrome's timelines seem arbitrary and the UI changes make keeping Chrome configuration guides a constant churn.
I think the issue the upper poster is referring to are things like when chrome deprecated ancient certificate features, which enterprise-solutions still happen to use by default 15 years after they were deprecated.
(One such issue were certificates with a common name and no subject alt name.)
That issue bit me in the ass, but my biggest complaint about it was the horrible error message that Chrome gave making it impossible to figure out what the problem was.
Yes, the common name and the no SAN was one of those problems. It didn't help that 90% of all tutorials to do a self signed CA only set a CN, and sometimes you had dependent internal systems. How this appears to people who end up servicing tickets are just 'Chrome doesn't work anymore' and having to answer many people that 'Chrome won't work any more until a larger business process resolves, and there's nothing we can do about it' really sucks. Also to an end user who might be a nontechnical administrator of a enterprise application there was no indication that it was going to become a problem, they just show up to work one day and they can't work.
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.
Brave (https://brave.com/download/) is a good alternative too. It doesn't have the terrible UX (IMHO) that Firefox has. But it is built with Chromium (TMK).
I use Brave as my daily driver, but this trickled down into Brave as well this morning. I was confused for a minute what I had done with a subdomain on one of my sites, and then got very frustrated when I realized the Chromium team had put this back in place. A few #omnibox... tweaks later and I have it back, but it is certainly annoying.
This is why forking Chromium is not a solution. Unless a team is committed to maintaining that fork, eventually they'll be forced to merge in any of the changes that Google wants to push.
The only way a Chromium fork works is if the team is willing to stop merging after they fork and take over development themselves.
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!).
Have they though? How many of their users understand what "www" or "https" mean? For those that have a vague idea, how many ever look?
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.
This isn't about users, it's about a scam to trick people into thinking that something is being served from their site, but it's not, it will be from Google. (ie, AMP)
It's not always 1-3 characters. google-payments.sbc.net for example. For the third time, I'm not arguing in favor of Google's implementation. What I'm saying is that this has nothing to do with Google being out of touch with users as the GP suggests.
> It's not always 1-3 characters. google-payments.sbc.net for example.
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.
>Sorry but you are arguing that it will improve security. I'm asking you to prove that it does improve security
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".
> 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
In the past, I guess the second URL would have included www at the beginning.
The dangerous one didn't change... the not dangerous one did change but doesn't matter really. They are just as similar.
I'm certainly not a fan of the new URI scheme, but it is worth pointing out that Safari has already made the same change. Furthermore I'm not convinced said change is a net-negative for the average consumer.
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.
I was reading your comment thinking, "What? No!" and then kept reading. I apparently checked "Show full website address" when the change was first made.
Google wants nobody to know URLs exist, and that everyone is forced to search Google for everything, even sites they know, and there visit fake AMP-sites portraying to be from a server they are not, all while Google tracks every single keystroke you make.
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.
Firefox and Safari already made similar changes. Safari made the exact same change, and Firefox hides http:// already, but not https://, chrome is just using a lock icon to represent the https:// instead of the actual string.
From the company whose mobile line of business started with an music player that hid file extensions. I can still remember when I first started running into people that didn't know that the songs on their ipod were files. Certainly builds a "moat."
If I have one webpage with different languages and want my visitors recognize it from url, what are the options?
Previously I could have www.example.com/en/ and www.example.com/fr/ etc
If subdomains are not possible there's no hope that visitors using Chrome would see it?
This is great and all until you (like me) need to be able to differentiate www.example.com from example.com and https:// example.com versus http:// example.com. My website doesn't forward example.com to www.example.com (due to errors on my part that I don't know how to fix, my email is in my profile and if you can help I'd greatly appreciate it).
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.
>need to be able to differentiate ... https:// example.com versus http:// example.com
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.
Based on your certificate, are you using Cloudflare? If so, this shows how to handle these redirects: https://www.bybe.net/cloudflare-enforce-ssl-redirect-http-ht... I use Github pages+Cloudflare to host my page and that's how I do it, free and quite resilient.
HTTP headers are hidden. That's great and all until you need to examine them for some development task.
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 just so bizarre how strongly the Google product people continue to insist that this change is beneficial to users when so many users themselves simultaneously insist that it's not. Combined with the fact that their explanation is dubious at best (i.e. www is not a technically a "special case"), I find it very hard to believe they do not have additional, confidential reasoning for making this change.
What a slippery slope. I imagine a future when the entire URL itself has disappeared and we live in some sort of Google-controlled walled garden environment, like what they're trying to do with AMP[0]. Some sites only work with WWW prefixed as the APEX DNS record is misconfigured and points to nothing. I've even seen some sites point to `0.0.0.0' but had a CNAME record for WWW and I could then view the site.
This reminds me of how Windows frustratingly hides file extensions by default.
This sounds low-upside/high-downside to me, but it's the sort of thing with simple arguments-for (easier for clueless users! Cleaner!), and nuanced arguments-against (eliding rarely-useful details in special cases causes ambiguity, and can lead to confusion is some cases, particularly for clueless users).
And, there is a setting to tell it to not do that, but even then, for some files it is hidden anyways. But, it is possible to use regedit to change it so that the extensions are not hidden even for those cases.
On windows? I've never experienced/noticed this, what extensions are still hidden? Hidden files is a separate setting from hiding extensions (which is good), but I've never noticed a file that wouldn't display the extension after changing the setting. I can't remember specifically for any of the earlier versions, but this has been my experience on 7 & 10.
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.
Yeah, I have to google it every time I want to do this. It should be easy to find. Like maybe right click, show hidden files. Could be in the "View" menu. There's several obvious places it could/should be, but it's not. It's horrible ux.
https://github.com/sneak/osximage - i encourage you to snag the user setup scripts from here. the complete nbi building is out of date as it’s fallen out of favor with current releases but the configuration scripts can all still just be batch run on a fresh install to make osx sane.
Oh macOS is worse. It shows or hides extensions based on whether the user chose to include it in the save box or not. Command-line apps' output will always have the extension included.
Its hostile for power users but it prevents grandpa from renaming 'IMG_144.jpg' to 'Idaho_grandkids', hammering enter on the 'are you sure you want this' nag screen and then wondering what broke his picture.
It's not the picture that broke, it's not the user that is dumb, but the system that is broken. Dot extensions is a concept that should never have seen the light of the 21st century. Or at least it should be a last resort for the system to guess the file format for those formats that don't have magic numbers in their headers or for lesser known formats.
Or more generally the header should contain the metadata of the file: date modified, filetype, comments, icon, etc, rather than spreading that between the filesystem (with different filesystems having inconsistent dates), the OS, etc.
I disagree, locality data such as ownership, modified date, comments, permissions even, should not be part of the file, it breaks things like repeatable builds, version control and anything where the contents of the file are considered static.
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.
I don't think it breaks anything. If the world had gone this way, all the functions you use to read a file would read the data from the first byte after the header.
In that situation the metadata is no longer part of the 'file' then, and would be lost by a 3rd party copy function unless extra API functions are used to copy the metadata.
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
Does Mac still have resource forks? Either way, I'm sure it still has decent magic number decoding. Who (except family members in windows?) would care about the missing extensions?
The only real reason i care is for vim file detection (in Linux). How sad is that? :'(
Resource forks are still supported. At least they were with HFS+. They might be gone in APFS. In any case with each release Apple makes it harder to access them.
APFS still supports resource forks. (They're not as baked-in as HFS/HFS+, though.)
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).
Wait a tic - so the creator code forced the opening program to always be the same for a given file? There way no way to declare a preference that `.csv` files should now be opened with textedit or some such?
He's mis-stating it slightly. You couldn't fiddle with a file's creator code, but there wasn't much reason to.
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.
I don't remember this being the case. I don't think it was possible to change either a file's type or creator code without a tool such as ResEdit that wasn't included in the OS.
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.
It worked well enough and ensured the example 'grandma' problem above could not occur.
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.
On Macs before 2001, that used to work! We didn't used to cram pieces of file metadata into file names. File type was stored its own slot. The hidden-ness of a file was stored in its own slot.
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.
Apple used to be the innovator in file metadata. They stopped when Steve came back because proper metadata made it more difficult to share files with Windows and Unix. And we're still stuck with crap metadata to this day.
Given the implementations I've seen of file metadata outside of the extension I'm okay with this - every time OSes (especially windows) tries to strip away the extension it ends up switching the file type from being a description of "what am I" to "what can open me", I really dislike "what can open me" especially when we get into a lot of common office work file formats. Knowing the difference between .rtf, .txt, .doc and .docx is important because of the special attributes of those files - additionally I frequently run into issues with character encoding and that should be an even easier problem to solve so... my outlook is not very optimistic.
Agreed. Apple's pre-OSX metadata system was two pieces: "What am I" and "Who created me." This was an amazingly flexible system that just worked and was the best of both worlds.
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.
I like the design principle "it should be easy to do easy things and possible to do hard things". Showing the extension, but requiring terminal use to change it would a decent compromise.
Can someone help me understand why this is a big deal? Safari has had this change for a while and I haven't felt like I'm missing anything. Where's the slippery slope? Does have to do with AMP?
It has nothing to do with AMP. There's a lot of reasons why, but one reason is for example, two different sites can technically be hosted on www. and the non-www version, if the site isn't set up to redirect the www to the non-www, for example. So this could, in certain scenarios, pose a security risk in that if you pretend that www and the non www are the same sites -- when they're not -- it can make it easier for those that hijack one or the other to get away with it. Now, that's fairly extreme and esoteric. But there are actually times in development when you use subdomains, which this makes more difficult, and there's other subdomains they're considering trivial which, in fact, aren't. This is really good discussion on the topic and why this change just simply ignores so many technical issues, best practices and simply realities: https://bugs.chromium.org/p/chromium/issues/detail?id=881410
Here's a problem: people often share screenshots with the address bar in the screenshot.
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:
This behavior will train users to believe that the www in domains isn't important, when it actually serves a very important purpose.
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.
If the url isn't important enough to display, then they shouldn't display it. They can display just the domain. They shouldn't display almost the url, but they removed an important thing.
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 would have no trouble with hiding "https://" in the address bar, as long they show it for other protocols (including http). It might help move us to a world with https everywhere even faster.
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 have the opposite complaint: when I highlight a portion of the url in chrome, it prepends the http:// anyway. If I have the whole thing selected it would make sense to prepend the http://
Yes, on Windows. You do have to select the first part of the url, but I often just want the host and port, ie localhost:8080 instead of http://localhost:8080
This is so minor but it slows me down working every day. If I didn't select it, don't copy it. If I clicked in the center on a specific spot, drop the cursor right there instead of selecting a section.
Interesting. What OS and Firefox build are you on? Firefox always copies the full URI for me. (Windows, Firefox 69 - and I'm pretty sure I get the same behavior on my Linux machine at home, but I'm at work right now so can't confirm.)
This is so pointless. Why? To make the URLs prettier for the average user who they assume is too stupid to function or something?
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.
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 work for well-known tech company [redacted] and visiting our website with the www omitted does not work from within our network. But if you've just updated Chrome, it would now be unclear whether you typed the site name right.
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.
They're not good practice on the part of the website operators, for sure, but they are real examples of the root and www domains being different. In my experience there are also lots of old or government sites that just plain don't work without the www.
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://!
193 comments
[ 2.6 ms ] story [ 224 ms ] threadchrome://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 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).
Now do it like Firefox:
Warning: Check the black portion of the URL and make sure it's the right one!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?
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.
In the past, I guess the second URL would have included www at the beginning.The dangerous one didn't change... the not dangerous one did change but doesn't matter really. They are just as similar.
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.
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.
https://news.ycombinator.com/item?id=20631676
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.
Heck, if you use `fr.example.com` and `en.example.com`, those would also work.
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.
"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."
[0] https://developers.google.com/amp/
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.
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.
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.
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 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.
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.
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.
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://!