Hacker News new | ask | show | jobs
by bsimpson 945 days ago
As a Googler, I find this hard to believe.

A more plausible explanation is that there's a very strong culture of using Chrome for work stuff at Google, and a general belief that automated tests can replace manual tests. These "oops"es are more likely the result of engineers doing most of their work in Chrome, and not noticing subtle changes in browsers they don't often use.

3 comments

I think the very defense you're using is the problem though. It's fine if nobody uses the competing browser for work at Google. It is, however, pretty standard to have automatic tests for performance and functionality, and these need to be cross-platform. Having insufficient automated testing for Firefox to catch these sorts of issues is a structural, anti-competitive bias. Especially when these things clearly don't happen with Chrome.

Couple that with the article's documented case of using a deprecated API from Chrome that's unsupported in FF. That's bias in the design, and that's something that leadership is either not catching, or making a conscious decision on. I'm sure it's couched in some statstic about which monetizable users are impacted or something. But at the end of the day it's an organizational, structural bias.

And that's not to say this is necessarily illegal. I honestly wouldn't know. But I think you made a straw man to attack. The allegation isn't necessarily that there's an organization wide conspiracy of evil Googlers. Just that the organization and culture is designed to benefit Chrome and disadvantage Firefox, and that's happening regularly with user-harming effects.

I think this is correct and would add that the YouTube example highlights that it’s a management decision, not just an inexcusable lack of testing. I’d definitely believe that developers tune what they use first, but once a known problem is identified someone had to decide how to prioritize it.

In many ways, I’d treat this like mandatory banking & investment separations where a cost of being a browser developer should be that you can’t ignore things other shops can. Vimeo could decide not to fix a performance regression affecting Firefox but YouTube should be required to fix it within 60 days, and if they don’t like that they can split it into an independent company which wouldn’t have that constant conflict of interest concern.

I'm not defending anything - I definitely have my own thoughts on the matter, I'm just trying to be conscientious about what I publicly say about my employer.

However, I don't believe that engineers are intentionally disfavoring Firefox, trying to drive market share down to "run out the clock" or "sabotage" competitors.

For all its dysfunction, Google does tend to hire well-intentioned people - the person being quoted even said as much. There's also a long list of annual trainings that coach people to tread lightly regarding anything that might be perceived as anticompetitive.

It's fair to talk about the craft of engineering and how different processes have different effects. Like I said, I have to be conscientious about what I say, so I'm not going to engage that point. But loaded language like "sabotage" and "run out the clock" suggests a malicious intent that I don't believe exists.

A sweeping majority of web-native teams I've met do cross-browser cross-device testing and intentionally make sure their team has multiple browsers/devices represented by engineers during development.

Serious shops have literal walls of devices for automated testing across different browsers and OS stacks, with real-time Quality of Experience metrics streaming back from customer devices - tagged with environment metadata - to detect regressions to the experience on every release.

I find it hard to believe that one of the largest web-native giants in our industry didn't follow those practices as an oversight. I hold engineers at Google in higher regard than that.

Rubbish. Back when user agents were used you could change the agent and get access to Google things that were faster in Firefox.

It’s silly to assume they didn’t do it on purpose.

User agent strings are still used for this stuff. Today's Youtube delay is an example which I've verified myself.
I've added several of those checks to Google products; it's certainly never been for the reason you're suggesting.

You get a bug that a certain feature is crashing Firefox, or slowing it to a crawl. You can't do feature detection, because Firefox reports the relevant features are supported. So you code up a less-efficient behavior that avoids the crash, and only use it for the Firefox user agent.

Months or years later, Firefox improves the problematic behavior, and now performs much better when you switch the User Agent to Chrome and get the efficient path. Nobody at Google is paying active attention to that code anymore, so it remains in that state until someone notices.

The idea of slowing down Firefox based on a User Agent check would be totally crazy to anyone I worked with at Google, and you'd be immediately reported to legal and HR if you tried to get such a thing through code review...