[mr_puzzled]

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).

[EpicEng]

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.

[RobertRoberts]

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)

[EpicEng]

Like I said, I'm against it for several reasons, but I replied to this:

>there seems to be a disconnect between the chrome devs and users

[dwild]

> 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.

[EpicEng]

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.

[dwild]

> 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.

[EpicEng]

>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".

[dwild]

> 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.

[tedivm]

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.

[xemdetia]

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.

[magicalist]

> ruin chrome as an intranet browser in the last few years with TLS handling, self signed cert handling, and general settings window changing malarkey

Just put it in the OS certificate store? It's worked like that since Chrome was released.

[xemdetia]

I'm talking about things like HSTS where the interface to purge HSTS entries that have become invalid has changed constantly.

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.

[hannob]

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.)

[xemdetia]

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.

[tedivm]

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.

[huntermeyer]

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).

[ljoshua]

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.

[danShumway]

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.

[magicalist]

> This is why forking Chromium is not a solution

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.

[benbristow]

Had issues using Brave.

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!).

[OrgNet]

I still prefer Firefox but they removed many features that I liked... maybe because I dont share analytics but that doesnt matter to me