IMHO, this kind of things are not done by engineers.
* Marketing/Sales asks engineers to add a feature flag to sleep N milliseconds for their research: "how slowing down impacts your revenue"
* engineer adds a flag, with different control parameters
* Some genius in Product figures this out and updates the experiment to slow down for competitors
When company gets a backlash from public: "oops, we forgot to clean up all parameters of feature flag and it accidentally impacted Firefox"
Google stopped testing stuff in Firefox, that is all they did afaik. We all should know how many bugs and "oppsies" you get when you don't test before releasing new features. Test code snippets being pushed to prod etc.
Engineers tend to create paper trails on what they work on, code reviews and bug logs etc are everywhere, so I doubt there is any of those where they say "Make things shit for Firefox to hurt our competitors", that would net them an easy loss in court. But not testing in browsers with small userbases will hold in court.
Firefox has a small userbase partly because of the early "oopses" described in the article I linked. Those happened a while ago, when Firefox had more users than Chrome.
But they referred to behaviour that was present pretty much from the start. It's just that Mozilla folks were extremely tolerant and assumed good faith for a very long time.
Google have been disgustingly anticompetitive for a very, very long time at this point.
Yeah, one of the biggest examples being the HTML 5 video push and Chrome’s claims around H.264: Google promised they were going all in on WebM and would remove support soon, but never did. That meant that Firefox users got more errors outright but also that for years even sites like YouTube would leave Firefox using 100% CPU with your laptop fans on high doing software WebM while Chrome users got hardware accelerated H.264. That became moot after Mozilla and Cisco struck that deal and video hardware acceleration for other formats shipped but there was a multi-year period where Firefox suffered badly in comparison to other browsers.
Another person is claiming that Google writes custom code for Firefox (or other browsers) to enable tracking, because of the feature difference between Firefox and Chrome [1]. Only one of you can be correct.
The company is big enough for both of them to be correct.
I have firsthand knowledge that Cloud, for instance, did not test regularly directly on Firefox. Team couldn't justify the cost of setting up and maintaining a FF test suite to satisfy 1 in 50 users, so they didn't (and nobody up-chain pushed back on that). Testing was done regularly on Chrome, Safari, and Edge, as per the usercounts and "top three browser" guidance (at the time, we didn't even test regularly on mobile, since there was a separate mobile client).
But the analytics team? I'm sure they test directly on Firefox. They're just testing an entirely different piece of the elephant and their end-to-ends won't include how, for example, changes they make interoperate with Firefox in the context of Cloud. Or YouTube. Or etc. Not unless they have a specific reason to be concerned enough to.
Google's like any other megacorp in the sense that costs of cross-team coordination are combinatoric.
Very good point. It's important to recognise that developers in many companies are often not fully aware of the intended use of features they're asked to create.
My initial reaction was astonishment that the engineers would happily implement this. And maybe that is what happened. But the alternative possibility is that product and senior management assigned different parts of the feature to different teams e.g. one team develops a pattern recognition system to detect users' professions, another team develops a spoofing system for use in demos, etc...
They have done such research before, Google published this at a time when developers were all "100 ms more or less web load time doesn't matter". Since then webpages has gotten much more focused on performance.
The prevailing developer discussions going from "Load speed doesn't matter, stop complaining about useless stuff" to "load times matters, but here we choose to make it slow for other reasons" is a massive improvement though. Today speed is valued, it wasn't back then.
There are many such tests being written about in blogs today. So now a developer can get time to optimize load times based on those blog posts while before managers would say it was worthless.
Of course it always mattered. But at the time lots of people argued it didn't matter, which is why the headline is "Speed matters". You thinking it did matter at the time doesn't mean the general community thought so.
But the general community did care about speed. Everyone worked towards small load times, optimized (for example) image size for optimal load time, everyone cared.
Not so hard to believe tho. I work on a product that has parametrized feature flags. This means that, from a web interface, someone can say things like "activate feature X, on machines running operating system Y, at version Z, and are running product version W with license type Q". This is not a hard thing to build, and once you have it you can mix and match filters without being a software engineer or knowing how it works behind the scenes.
