Strange how they "fixed" it by making it opt-out rather than opt-in, given the culture collision here. Google really likes NaCl a lot for being a feature with almost no third party adoption.
While there's "almost no third party adoption", there are two pretty significant uses: The Flash player and the PDF viewer. Browsers that rely on NPAPI for these get all of Adobe's security bugs on top of their own. You may say that Flash and PDF doesn't exist in your view of the web, but it definitely does for many people.
It does, and I enjoy mp4 videos and I'm not bothered much by DRM on Netflix either, but should a component like NaCl implying a binary blob be part of an open source software.. by default? Feels weird to have it included with Chromium by default. Weren't Chrome and Chromium originally separated in order to make one compatible with open source distributions, so that this sort of thing would be avoided? A conflict with Debian sounds like a pretty big one.
NaCl doesn't imply proprietary any more than a JavaScript engine does. The downloaded code is bytecode at an abstraction level a bit below C but quite a bit above assembly. It's not substantially different from a freedom perspective than code compiled to asm.js or just minified JavaScript. Both are usually proprietary and require reverse engineering work to decipher.
It's really hard to create vendor lock in on a feature nobody uses.
But even if they did go down that route, NaCl is licensed under BSD, so even Microsoft could add NaCL to IE if they wanted to. That's some pretty weak vendor lock-in.
Licensing is not the issue. Microsoft could not add NaCL to IE in the same sense that it could not add Firefox' DevTools to IE. It would require a major rewrite and cost tremendous heaps of money.
Even if that's true (and I share the sibling's skepticism), vendor A's incompetence and poor product quality is not meaningfully described as "lock-in" to vendor B - especially so when there's a readily available vendor C (Firefox) that doesn't share these ills.
I've gotta raise an eyebrow on that one. If it's a major rewrite to support a new plugin authoring language, your plugin architecture was a terrible mess to begin with.
Given that we're supposed to believe that New Internet Explorer was pretty much a from-the-ground-up rewrite, I can't imagine that their plugin architecture is a terrible mess.
NaCl isn't simply a plugin architecture. It is effectively the entire Chrome sandbox and large parts of Chrome architecture made available to binary plugins.
You aren't pulling it into your project without also pulling in half of Chrome.
Unfortunately, that fix disables the functionality completely, rather than making it so that the sandboxed hotwording module can be used if enabled by the user.