>Many didn't know that Chrome engineers could run experiments on their tightly-controlled Chrome installations, let alone that Google engineers could just ship changes to everyone's browsers without any prior approval.
Uhm, isn't that the entire auto-update feature, that google ships changes without you even being aware?
We were affected and our version hadn't changed (in fact we weren't quite on the latest version - we were still testing it). We have updates disabled and are very much aware of how to manage this.
Google changed a feature flag that was automatically picked up by existing copies of Chrome and changed their behaviour.
If Chrome is critical to your company, shouldn't you be testing on Beta before it goes stable? In this case, the feature was enabled on Beta for 5 months, yet not a single impacted company caught it. Even with 1% enabled, no one caught and reported it.
This is explicit. Binary changes and flag flips are very strongly split. This is almost always a good thing, as it means you don't need to roll back binaries to revert problems.
I can see the benefits when thinking about consumers.
I think the difference here is to do with who's responsible for keeping things "working".
In a business environment there is a whole IT department who go to a lot of trouble to guarantee that their colleagues can continue working. But when Google take that control there's a clash, and it hinders the IT team's capabilities.
In the bug thread, multiple orgs stated they tried to downgrade to the last version and encountered the exact same problem. This alone is going to leave orgs circumspect about their security and Chrome’s reliability, at the very least.
My interpretation of the below quote from the article is that Google enabled the feature through pushing a configuration change to active clients. So if I'm a sysadmin and have done my due diligence and successfully tested the new build (with my configuration) before deploying it, I would be very unhappy if/when Google decides to turn this on without my consent or knowledge.
Ref. quote from article:
"Chrome engineers operate a system called Finch that lets them push updated Chrome settings to active installs, such as enabling or disabling experimental flags."
I always recommend Firefox ESR to corporate clients that use our web-based product. Long-term stability, automatic security updates, and a yearly, well-documented release cycle that allows their IT department to test the upcoming ESR release and upgrade with confidence, while we get the benefit of a modern web browser to target.
ESR user for many years, plus useragent-switcher for sites that pretend to care about my "security" (but mostly care about CSS eye candy and the latest whizzbang). Free beta tester for other people isn't in my job description ;-)
Specifically this example I don't know, but there are pretty big differences between look and feel on websites when sending a Chrome UA vs a Firefox UA. The most obvious example is Google.
Article said they already ran it in beta and even experimented in stable!
>"The experiment/flag has been on in beta for ~5 months," said David Bienvenu, a Google Chrome engineer. "It was turned on for stable (e.g., M77, M78) via an experiment that was pushed to released Chrome Tuesday morning."
>"Prior to that, it had been on for about 1% of M77 and M78 users for a month with no reports of issues, unfortunately," he added.
The bug affected Citrix-style environments, where perhaps 10-20 users are running Chrome on the same machine.
If 1% of users are running the experiment the chance of two of those 10 users running the experiment is tiny, and when they experience the bug it's unlikely to get reported back to Google.
Uhm, isn't that the entire auto-update feature, that google ships changes without you even being aware?