7 ms·

From the comments on the debian bug, this appears to have been fixed in Chromium. https://code.google.com/p/chromium/issues/detail?id=491435 https://code.google

From the comments on the debian bug, this appears to have been fixed in Chromium. https://code.google.com/p/chromium/issues/detail?id=491435 https://code.google.com/p/chromium/issues/detail?id=491435

jug 11y ago
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.
- rockdoe 11y ago
  That's the point. It's strong vendor lock in because NaCl is unadoptable by their competition.
  - mseebach 11y ago
    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.
    - espadrine 11y ago
      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.
      - mseebach 11y ago
        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.
        rockdoe 11y ago
        Firefox doesn't support NacCl, Mozilla has show no intention of integrating it and they even criticized the technology.
        IshKebab 11y ago
        Yeah but that's because Mozilla loves javascript and NaCl provides a working alternative.
        stevehawk 11y ago
        How is NaCl not just "Google's version of ActiveX"
        spot 11y ago
        it's secure and open source.
        stevehawk 11y ago
        Nothing is "secure".
        strcat 11y ago
        It's more secure than JavaScript, which is a start. Dropping the need for just-in-time compilation while gaining performance is nice.
        icebraining 11y ago
        When 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/
        11y ago
      - simoncion 11y ago
        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.
        rockdoe 11y ago
        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.
        simoncion 11y ago
        According 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 ago
        the 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
- mortehu 11y ago
  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.
  - jug 11y ago
    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.
    - strcat 11y ago
      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.
      - vezzy-fnord 11y ago
        As it's not the "preferred form of the work", I think it is proprietary - same way any object/intermediate or obfuscated code would be.
      - rockdoe 11y ago
        >NaCl doesn't imply proprietary any more than a JavaScript engine does http://www.gnu.org/philosophy/javascript-trap.html http://www.gnu.org/philosophy/javascript-trap.html
      - diamondlovesyou 11y ago
        > The downloaded code is bytecode at an abstraction level a bit below C but quite a bit above assembly. You just described PNaCl, not NaCl. NaCl is architecture specific and already sandboxed (ie the SFI part of NaCl), whereas PNaCl is not.
dtech 11y ago
Note that it wasn't an upstream bug per se, they added a build flag to disable it.
JoshTriplett 11y ago
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.

From the comments on the debian bug, this appears to have been fixed in Chromium. https://code.google.com/p/chromium/issues/detail?id=491435 https://code.google.com/p/chromium/issues/detail?id=491435

jug 11y ago

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.

rockdoe 11y ago
That's the point. It's strong vendor lock in because NaCl is unadoptable by their competition.
- mseebach 11y ago
  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.
  - espadrine 11y ago
    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.
    - mseebach 11y ago
      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.
      - rockdoe 11y ago
        Firefox doesn't support NacCl, Mozilla has show no intention of integrating it and they even criticized the technology.
        IshKebab 11y ago
        Yeah but that's because Mozilla loves javascript and NaCl provides a working alternative.
        stevehawk 11y ago
        How is NaCl not just "Google's version of ActiveX"
        spot 11y ago
        it's secure and open source.
        stevehawk 11y ago
        Nothing is "secure".
        strcat 11y ago
        It's more secure than JavaScript, which is a start. Dropping the need for just-in-time compilation while gaining performance is nice.
        icebraining 11y ago
        When 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/
        11y ago
    - simoncion 11y ago
      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.
      - rockdoe 11y ago
        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.
        simoncion 11y ago
        According 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 ago
        the 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
mortehu 11y ago
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.
- jug 11y ago
  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.
  - strcat 11y ago
    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.
    - vezzy-fnord 11y ago
      As it's not the "preferred form of the work", I think it is proprietary - same way any object/intermediate or obfuscated code would be.
    - rockdoe 11y ago
      >NaCl doesn't imply proprietary any more than a JavaScript engine does http://www.gnu.org/philosophy/javascript-trap.html http://www.gnu.org/philosophy/javascript-trap.html
    - diamondlovesyou 11y ago
      > The downloaded code is bytecode at an abstraction level a bit below C but quite a bit above assembly. You just described PNaCl, not NaCl. NaCl is architecture specific and already sandboxed (ie the SFI part of NaCl), whereas PNaCl is not.

dtech 11y ago

Note that it wasn't an upstream bug per se, they added a build flag to disable it.

JoshTriplett 11y ago

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.