Hacker News Reader

Comment by mankyd | Hacker News Reader

Going to give a guess as to more pragmatic reason this came about: they don't have a requirement or test for it.

Some engineer was asked to make a feature. That feature happened to break 3rd party seeking. It probably wasn't intentional, just incidental.

Because they have no internal requirement to support this, nor anyone/anything testing for it, it silently broke.

It was probably not malicious, even if it feels like a step backwards to this extension developer.

Whether it _should_ be fixed of course, is a different matter, but when I see statements like "DRM vendors REALLY want you to buy a smart TV"[1] I frown, as it is contains an assumption of intent that I suspect isn't there.

[1] https://news.ycombinator.com/item?id=28896614

Edit: The title of the article (and original title here) is "Netflix's new player is an open web nightmare". My response is written in response to this sort of inflammatory language.

View on HN

I agree. We ran into this issue all of the time at a past employer with a lot of tech enthusiasts in the customer base: We’d make harmless changes to our own code that broke someone’s community software that relied on undocumented APIs from time to time. Without fail, someone from the community would jump to conclusions and start stirring up controversy with claims that we were deliberately breaking 3rd-party applications.

The strange thing was that people from all over the internet wanted to get in on the controversy and anger, even when they didn’t use the software that broke. This created a weird incentive for software authors to complain loud and wide about any breaking changes because it became free advertising for their software. We tried quietly helping some of them fix their software with hints, but that quickly became an avenue for “<company> caves to pressure from angry customers” stories that only made our problem worse.

https://xkcd.com/1172/

We could save everyone a lot of time commenting on HN just by auto categorizing by XKCD.

Fascinating. I’m curious what were the landscape of MOs you/company evaluated. Eg: would it have been possible to encourage a slightly more organized relationship with the enthusiasts by communicating the challenges to them?

It’s tough. I engaged with the community a lot at first and we made efforts to give them what they wanted.

Over time this created a weird, unhealthy dynamic where parts of the community felt entitled to special treatment from the company. Some of them felt like they were stakeholders in the company and that we were obligated to incorporate them into the development process.

At worst, it reminded me of some of the “parasocial” relationships described in social media situations, where the followers start to feel like they were owed much more than regular customers due to their dedication as super customers. Even worse, some of them had their own YouTube channels, newsletters, or Discord communities for our products and would often threaten to turn them against us if we didn’t do what they wanted. That part was especially saddening.

Hmmm, that’s interesting in an unfortunate way that can only be learned from experience. I have wondered about why companies don’t better engage with enthusiasts / power users, and now I have a better appreciation for the challenges. Thanks for sharing.

That's the problem, the company didn't publicly engage with their users that needed it. A simple intent to ship with a list of changes related to API's is a great start. The employees should be using the most popular of the user made software. That's how organic communities function. The problems occur when company thinks theyre God and their software is controllable - it's not. People are going to use it as they see fit, and if you don't Shepard it that community will find their owns reasons for why the company ignores it.

>A simple intent to ship with a list of changes related to API's is a great start.

So the controversy can start sooner?

>The problems occur when company thinks theyre God and their software is controllable - it's not.

This isn't some github project. This is proprietary software owned by Netflix. This isn't "the community" getting upset, this is a small group of people using closed source software in a way that wasn't intended. Most people using Netflix just use it the way Netflix wants them to.

You would be apart of the problem, not the solution. Attitudes like that are exactly how that happens.

I am for open standards and accessible apis and support companies that provide those things. Netflix neither promised or delivered those things and it's extra work to maintain them. They don't owe anyone to maintain backwards compatibility on the undocumented public facing apis.

It's unreasonable to expect Netflix to deliver a feature that they have no interest in providing and never promised to.

I use a lot of software that relies on apis like that and it breaks constantly, that's just the way it goes.

There is typically a reason when APIs are not documented. There are no guarantees given it will keep working etc

Many times undocumented API's become a lot more permanent and 3rd party documented. If you don't do it, other people will, it's better to handle that problem from the company itself and put bit fat "can break any time" stickers on it.

> that only made our problem worse.

This is the part of PR that I fail to grasp. At a certain point, couldn't you just post "fuck you" on twitter and disregard the noisy mess? Would 100% of everyones' customer base actually walk away from them if they don't play "the game" on social media just right?

What I'd be afraid of is fake review brigading causing lasting damage to brand.

Been there. Basically, ignoring twitter and press pretty much works. If you have a working customer service mechanism, you need to be ready to respond there with a brief note of something like 'this use is not supported by us, bye', and once you have that note, you might consider responding to press with that.

You might want to engage with 3rd party developers, but it's clear that it would quickly become much more work than supporting in-house clients. When the server team unintentionally breaks an in-house client, they don't start a big distracting PR war about it; and when an in-house client unintentionally breaks the server, there's leverage to fix the client (or the server) and insight into how the fixed client deployment is going.

It can also be difficult to fix sensitive or just complex issues in a coordinated way when there's unequal access as happens with in-house and 3rd party development. Being non-transparent is easier; although certainly less desirable to many.

If you have a compelling product, people often don't follow through on their plans to drop it.

At a previous company we had someone angrily call in with a bug. We had moved a button several pixels and this broke some automation they had built which relied on the pixel coordinates of the button. It was exactly as dumb as it sounded.

So I don't see much reason for Netflix have a deprecation cycle for undocumented functionality that a third party extension relies on. If you want to rely on internals, don't be surprised when they change.

I'm specifically trying to avoid a bad integration though, the API for <video> is quite clear for how to interact with a <video> element hosted on a page, as defined by the HTML5 spec.

This is the issue I have with this change, I'm following all the rules here and those rules apply to every video provider on the web for rendering video.

While I don't think it was purposeful, it certainly needs to be called out that crashing the entire page is certainly nonstandard behavior for a <video> element.

Fwiw, you can’t even trust the browsers to handle HTML5 media spec behavior the same way.

I just dealt with cross-browser issues in how setting currentTime on <audio> is handled because I needed a player to resume from a preset time.

On WebKit browsers, including desktop safari and all iOS browsers, you must wait for the ‘dataloadded’ or ‘canplay’ events to fire before trying to set currentTime.

On desktop Firefox / Chrome, you must set currentTime immediately prior to .play() or it won’t pick it up.

At my company humans will complain if you move a button because most people operate on their own muscle memory, any time Microsoft, or some other software vendors moves a button, no matter how small, we get ends less complains, automation is not needed.

For automation, this is likely because you company did not provide proper official API do to proper automation. Many companies do not, nexflix does not. So people have to hack around internals to make the things do what they want.

I am still at a loose why companies, and devs are such control freaks they only want people to use their software / hardware in the exact way they want them do, offering no other control options, automation API;s or any other "power" features". It is their way or the highway... and screw you if you do not like it

To give you some perspective from a user:

The GSuite (or whatever they call it these days) google groups UI is hot garbage. However, I finally figured out how to open a group -- effectively a mailing list -- to the public internet. This was carefully documented in our internal wiki because, again, UI is hot garbage.

Google has too many PMs, so someone decided to go screw with the UI. It is now not much easier, but it is different, so I had to spend another hour figuring out how to do the same thing. For your "convenience" as a customer, the change has invalidated the vast majority of help text on the internet helping users work around the deficiencies in Google's UI.

And that is why users hate change: the previous UI might not have been good, but we'd already figured out how to use it. So a change creates work with zero benefit to us.

Yea, I love Microsoft Documentation [/s]. There has been more than a few times I have been trying to do something in azure, following the official Microsoft documentation which says something like "Click this button, then in the submenu choose X" except the button is not there, and the submenu has been moved....

> At a previous company we had someone angrily call in with a bug. We had moved a button several pixels and this broke some automation they had built which relied on the pixel coordinates of the button.

This is part of why Windows doesn't update the old Control Panel screens - the UI is the API for automation like this, and backwards compatibility matters more than consistency.

I don't find that particularly hard to believe, but do you have a reference for this?

A slight tangent: I know I'm not the only one who considers the old control panels to be far superior to the new ones, even if Microsoft disagrees.

The new UIs won't allow you to keep open the Bluetooth config panel at the same time as the Windows Update config panel, for instance, as they share the One True Config Window. You can only view one at a time. A little ironic for an operating system named for its ability to run multiple UIs at once.

Fortunately many of the old config UIs are still there on Windows 10, especially for more advanced points of configuration.

I imagine the old UIs are also more resource-efficient, for what that's worth, following the usual trend with UI toolkits.

And the fact that the old control panels can display so much information and controls in such a compact form. While all the new UI stuff needs full screen and scroll bars on my 4k screen to display 5 toggle and few sentences.

True.. Though sadly the Windows settings screen is far from the only application doing this :'(

It's like everything has to be touch friendly. Understood that this is great in some cases. But on my desktop PC it's not. I didn't buy a big screen to have half of it filled with empty space.

The curse of every damn website in the mobile first and responsive some badly world. As a long time Pc user it drives me batty.

KDE now won't let you open multiple settings pages at once either, unless you run kcmshell5 from a terminal.

You’re touching on a wider huge problem for society now: people make assumptions that ascribe malice when there is none (and/or vastly misunderstand something), and the internet lets this amplify and morph into bigger issues than should exist.

When social networking was nascent, there was this assumption that decentralized voices would help get truth out faster than could ever happen, and the principals of democracy would flourish. While that sometimes happens, it seems more often than not public opinion falls victim to conspiracy theories aided by cognitive biases (especially confirmation bias) and those who purposefully wish to distort.

What’s saddest to me is that I’ve come to the conclusion that the genie cannot be put back in the bottle. We cannot expect that technology will go backwards, and the only viable option is the China one of absolute information control, which itself is scary. Those who do not adopt this will be vulnerable to outside control and inside dark forces, and those who do will create a censorship authoritarian state.

> We cannot expect that technology will go backwards, and the only viable option is the China one of absolute information control, which itself is scary.

There is an obviously better alternative, which is non-centralized moderation.

This is HN. It's moderated. It's not moderated by a government or Mark Zuckerberg and it has no monopoly on the dissemination of information, so if you don't like the moderation here you can go somewhere else and there are in actual fact other places to go.

That works.

The real problem right now is that the biggest platforms are too big/centralized, which means you get chokepoints that attract hamfisted bureaucratic censorship instead of vigorous competition for high quality moderation.

Except it doesn’t. It falls victim to all the same things. I’ve seen things posted with all kinds of conspiracy theories that I happen to have intimate knowledge of from where I’ve worked, and those theories are dead wrong. They’re a combination of not knowing about public information, not being able to understand it (outside of skill set), not bothering to do research before stating opinions and amplifying (upvoting) things that sound right but are in fact not, incorrectly connecting dots that are unrelated, bringing in false “facts”, stating opinions as facts that others assume are then facts, and a host of other issues.

If all you’re depending on is others to upvote and downvote, then you information bubbles are easy to form. Facebook is notoriously bad for exactly this reason, as are forums that attract certain demographics / ideologies.

> They’re a combination of not knowing about public information, not being able to understand it (outside of skill set), not bothering to do research before stating opinions and amplifying (upvoting) things that sound right but are in fact not, incorrectly connecting dots that are unrelated, bringing in false “facts”, stating opinions as facts that others assume are then facts, and a host of other issues.

"The China one of absolute information control" doesn't fix any of that, because the censors have no better information than anyone else about what is actually true. And bad incentives to suppress things they know are true but don't want to get out.

The answer is, again, decentralized moderation. Subject matter specific discussion forums where the moderators are steeped in the subject matter and know better than the average man in the street or government bureaucrat what is and isn't malarkey.

This is emphatically not what Facebook does which is why Facebook is a dung fire.

Why do you suppose people will select sites with good moderation? Is there any more reason to expect this, than that they would join a non-conspiracy Facebook group today?

People do join non-conspiracy Facebook groups today. Most Facebook groups are actually non-conspiracy Facebook groups. People don't want to be spammed with balderdash all the time.

The problem with Facebook is that they do what amounts to inverse moderation, site-wide. They promote inflammatory nonsense because it builds engagement. Ordinarily this would cause people to leave, but the site is so large that the network effect locks people in and enables the company to survive abusing its users like that.

If there was a larger number of smaller sites, or a federated network in which individual subgroups handled their own moderation, people would abandon the ones that operated like Facebook because they're severely unpleasant and the network effect wouldn't be strong enough to lock them in.

I tag those commits with "spacebar heating": https://xkcd.com/1172/

The cause of the problem here is generally that you didn't provide (or adequately document) a reasonable API to do that thing.

If you did, and the third party was fishing through your internals to do it instead, they're the assholes. That's generally more work than reading API documentation so if the API exists people are likely to use it, which should make this rare.

But if fishing through your internals was the only way to do it, maybe change that if your goal is to not hear from so many angry people after you move things around.

Expect people to use the undocumented unstable interface if the documented stable interface doesn't exist or doesn't work.

But how do you do that with the web? If someone is digging into the actual source of the site, that's on them. But that doesn't mean our team has time to provide and support an API for 3rd parties.

There is nothing actually preventing a web page from having a documented API. Many of them do.

Especially if the service is free, it's not reasonable for companies to bend over backwards to build, support, and maintain an API. One can expect users to build on undocumented and unstable interfaces, but they shouldn't expect the care one might receive if they had a contract to support that functionality.

It's not about that.

If you make a service with popular third party extensions and then you make a change that breaks those popular third party extensions, the users are gonna be mad. At you.

The obvious way to reduce the likelihood of that is to publish an API for the third parties to use that won't break. You can say you have no obligation to provide that, and that's fine, but then it's going to break and the users are gonna be mad. At you.

> It probably wasn't intentional, just incidental.

The reason people assume intent is because such things often enough are intentional. Making your product harder to interoperate with outside of your control is a well-established practice for SaaS companies, particularly the big ones[0].

The reason this blog post has a story is not because this behavior is surprising, but because it's annoying, and because it can be construed as an accessibility issue - accessibility being the only excuse for having sane computing experience that won't be dismissed as "silly power users with their silly wishes".

[0] - See e.g. the lengths to which Facebook goes to make it hard to work with its DOM.

To be fair, Facebook has very deep incentives to do this (ie. to prevent adblocking)

I'm not sure what such incentive is here for Netflix

Facebook has no problem lying to advertisers about how much their money buys, I'd say it's much more likely that Facebook is concerned with preventing scraping.

I actually tend to agree with this take honestly. If I was an Architect over at netflix implementing QoE, and all my minions were making calls directly to the html element for seeking instead of using the API I created, I'd want to catch that regression quickly too.

That said, there is no public API for that functionality beyond the DOM element for anyone else, so I'm not sure what was expected for any sort of integration.

> they don't have a requirement or test for it.

Automated and thorough testing of client-side JavaScript is a huge, huge burden because you cannot simply run a script in isolation in a headless V8 instance or something: you need the entire browser and clone environment running.

Secondarily: the major tools for performing automated testing of web-applications within modern browsers are all lacking in some critical way, for example while Cypress automates Chrome fine, for some reason it loads the entire SUT into an <iframe>!!!! That alone will introduce massive differences from production, top-level browsing (the project is full of hacks that do things like re-write `window.top` so that the SUT can almost believe it's not running in an iframe, but enough differences leak through).

For all the effort Google put into Angular's Protractor, Chrome does not make this easy.

I've been pretty happy with the WebDriver protocol: https://developer.mozilla.org/en-US/docs/Web/WebDriver

Works across browsers and lets you simulate the user and check anything you want.

Sure, it's technically possible, just very unstable.

The issue isn't that the testing is challenging. The ask here is Netflix covers all third-party Chrome plugins that manipulate the playback experience. Is it really Netflix's job to ensure all changes are compatible with third party tools like the one linked here, or others like Language Reactor?

If they wanted to, it wouldn't be much work for them to provide a stable API for such tools. Mostly it would involve making certain functions/properties that are internal to their modules/closures available on a global object. For Language Reactor, it would be helpful to have a handful of stable classes or ids on different HTML elements, and an email when major changes are incoming. Even just to have access to the new code early on in the rollout would be nice. There is a frantic two weeks every year where LR is breaking for users and we can't debug, because we don't have the new code yet.

We're jaded enough to assume the reverse of Hanlon's razor (for me it was when google dropped their "don't be evil", hard).

At a certain point (size of org, number of incidents) you decide that mere stupidity is not an adequate explanation. It doesn't have to rise to the level of actual malice, but willful negligence is on the table.

Comment sections are no fun if we’re going to assume good intent of people we don’t know. I suggest we ignore this reasonable explanation and start a frenzied campaign against this obviously malicious change.

I feel like I'd find this comment more humorous if it wasn't a parody of what is actually happening.

I think that's true for many things Netflix does, but wrapping the seeking event handler for HTMLMediaElement with private state specifically to catch unexpected seek events seems like it would be known to break 3rd parties. That's fine, of course, they aren't claiming to support a public api. But it doesn't seem accidental or some oversight.

Any change to frontend behavior will likely break someone at Netflix's scale. They are likely desensitized to breaking these things, otherwise they would never make any changes.

That's roughly what I was saying. It wasn't an oversight or accident.

The thing is, organizations have their own sort of "intent" apart from the people involved in them, and the process you describe is exactly how that intent is expressed. Who decides what should be tested and how? Who can be affected without anyone noticing or fixing the problem? Which problems are deemed important to fix and which are more of a "nice to have"?

It's possible for most people in an organization to care about something -- in the sense that they'll tell you they care if you ask them, and if you point out a problem they'll spend some time trying to fix it -- while the organization itself doesn't actually care in the slightest. The people who care can't fix the problems if they don't see them in the first place or if other problems have already been prioritized above them.

It's honestly better in some cases just to lock these types of folks out - you can save yourself a ton of a headaches later.

Look for words like offended, nightmare, deeply upset, outraged - if you see a lot of that - disengage!

Reply on news.ycombinator.com