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