6 ms·
That's the point. It's strong vendor lock in because NaCl is unadoptable by their competition.
by rockdoe 11y ago
That's the point. It's strong vendor lock in because NaCl is unadoptable by their competition.
- mseebach 11y agoIt'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.
- espadrine 11y agoLicensing 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.
- mseebach 11y agoEven 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.
- rockdoe 11y agoFirefox doesn't support NacCl, Mozilla has show no intention of integrating it and they even criticized the technology.
- IshKebab 11y agoYeah but that's because Mozilla loves javascript and NaCl provides a working alternative.
- stevehawk 11y agoHow is NaCl not just "Google's version of ActiveX"
- spot 11y agoit's secure and open source.
- stevehawk 11y agoNothing is "secure".
- strcat 11y agoIt's more secure than JavaScript, which is a start. Dropping the need for just-in-time compilation while gaining performance is nice.
- icebraining 11y agoWhen has JavaScript itself (and not the APIs, unless it's a JS-specific problem) last enabled an exploit in a major browser? I can't remember it. Meanwhile, here's a NaCl sandbox escape exploit from March: https://www.exploit-db.com/exploits/36311/ https://www.exploit-db.com/exploits/36311/
- lallysingh 11y agoNaCl runs in a sandbox
- Niten 11y agoHere's an overview: http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/34913.pdf http://static.googleusercontent.com/media/research.google.co...
- simoncion 11y agoI'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.
- rockdoe 11y agoNaCl 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.
- simoncion 11y agoAccording to this [0], NaCl is a Pepper plugin. [1] This would strongly imply that all you'd need to do to use NaCl is to implement PPAPI. Care to point out how I'm wrong about that? [0] https://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics#TOC-Native-Client-NaCl- https://www.chromium.org/nativeclient/getting-started/gettin... [1] Indeed, in a vaguely-recent Chrome, about:plugins has this to say about NaCl: Native Client Name: Native Client Version: Location: /opt/google/chrome/internal-nacl-plugin Type: PPAPI (in-process)
- pilif 11y agothe PPAPI is very closely tied to chrome's inner workings and is extremely complicated to implement as, compared to the old plugin api's, it doesn't allow native code any access to the local system. So it needs to provide plugins with all the possible hooks they will ever need. Check https://developer.chrome.com/native-client/c-api https://developer.chrome.com/native-client/c-api for a list of currently supported features. For other browsers to support PPAPI, they'd have to implement all of this, which, btw, also is a moving target that moves forward in lockstep with chrome releases.
- 11y ago