5 ms·
Trying to be charitable here: could this be a debug/test artefact that inadvertantly got into production?
by andyjohnson0 3y ago
Trying to be charitable here: could this be a debug/test artefact that inadvertantly got into production?
- enlyth 3y agoWithout studying the minified code I wouldn't assume malice just yet, this could be just an inexperienced developer trying to lazily fix some browser-specific bug, or something that accidentally made it to production like you say
- vanderZwan 3y agoYou think they let inexperienced developers touch the YT code base without proper code review? Even if that were the case, which is an extremely charitable assumption, that itself would be malice in my opinion.
- londons_explore 3y agolol This reply is for everyone who has ever worked on the codebase...
- ozim 3y agoShould be: LOL LGTM
- sapiogram 3y ago> You think they let inexperienced developers touch the YT code base without proper code review? Yes
- ric2b 3y agoYouTube is way too stable for that to be the case.
- enlyth 3y ago> You think they let inexperienced developers touch the YT code base Uh, yes? We were all inexperienced at some point. Just the linked file is like 300k lines of unminified code, I doubt it's all written by PHDs with 20 years of experience
- xxs 3y agoSome would argue that owning a PhD degree does not necessarily guarantee half decent engineering skills.
- vanderZwan 3y agoIt's the "without proper code review" part that I consider malice, not being inexperienced.
- xxs 3y agoAs the saying goes: "we like naked girls, not naked sleep". Even the interns should know that, naked sleep is just bad - not fixing anything.
- asddubs 3y agothere is such a thing as overextending the benefit of the doubt, to the point that malicious actors will abuse it.
- kevincox 3y agoIt could even just be a timeout as part of retry logic or similar. A lot of people seem to be saying that there is no reasonable reason to have a `sleep` in a production application. But there are many legitimate reasons to need to delay execution of some code for a while.
- fwn 3y ago> Trying to be charitable here [...] There is no reason for charity with such a large power difference. For Firefox, "bugs" like this can really end up being a lost one-shot game. It's like people walking by and casually reaching for your phone. It's always meant as a joke, unless you don't pull it away fast enough. Then suddenly it wasn't a joke - and your phone is gone. This is not rooted in any reservation against Google in particular. If you are a mega-corporation with the power to casually crush competitors, you should really want to be held to a high standard. You do not want to be seen as the accidentally-fucking-others-up-occasionally kind of company.
- neonsunset 3y agoUnlikely. Google has been breaking non-Chromium (or sometimes even just non-Google Chrome) browsers for years on YouTube and their other websites. It was especially egregious when MSFT was trying their own EdgeHTML/Trident-based Edge. Issues would go away by faking user-agent.
- thaumasiotes 3y ago> It was especially egregious when MSFT was trying their own EdgeHTML/Trident-based Edge. Issues would go away by faking user-agent. Why is there more than one user-agent? Does somebody still expect to receive different content based on the user-agent, and furthermore expect that the difference will be beneficial to them? What was Microsoft trying to achieve by sending a non-Chrome user-agent?
- kevincox 3y agoUser agents are useful. However they tend to be abused much more often than effectively used 1. They are useful for working around bugs. You can match the user agent to work around the bugs on known-buggy browser versions. Ideally this would be a handful of specific matches (like Firefox versions 12-14). You can't do feature detection for many bugs because they may only trigger in very specific situations. Ideally this blacklist would only be confirmed entries and manually tested if the new versions have the same problem. (Unfortunately these often end up open-ended because testing each new release for a bug that isn't on the priority list is tedious.) 2. Diagnosing problems. Often times you see that some specific group of user-agents is hammering some API or fails to load a page. It is much easier to track down if this user agent is a precise identifier of the client for which your site doesn't work correctly. 3. Understanding users. For example if you see that a browser you have never heard of is a significant amount of traffic you may want to add it to your testing routine. But yes, the abuse of if (/Chrome/.test(navigator.userAgent)) { mainCode() } else { untestedFallback() } is a major issue.
- thaumasiotes 3y agoOnly option 1 is something that users, who are the people who decide what user-agent to send, might care about. And as you yourself point out, it doesn't happen.
- KptMarchewa 3y agoIf, with Youtube size, they do not test on Firefox, this is as much malice as doing this deliberately.