5 ms·

Yeah, NPAPI was too open for them to keep permitting the use of. Better to move everything to in-browser DRM (they almost gleefully recommend EME for video) and

by gergles 12y ago

Yeah, NPAPI was too open for them to keep permitting the use of. Better to move everything to in-browser DRM (they almost gleefully recommend EME for video) and everything else to NaCl which only works in Chrome. sigh

captainmuon 12y ago
Too open in every sense. One, it was fairly simple. NaCl is a complete operating system API in the browser, and basically impossible for anyone but Google to implement (because it is proprietary, but also because of its sheer complexity). Then, native browser plugins were "omnipotent" and could do anything the user could do. Of course, this has security implications, which was why people wanted to get rid of them. But these are not unsolvable. Remember how insecure browsers were a few years ago, and look at how much work has went into securing them. Chrome uses sophisticated sandboxing of its individual parts. One could use this, or other modern techniques to contain plugins (containers, virtualization. Hell, you could just run plugins under a different user with restricted rights and it would help a lot). Security worries are not the reason. The real "problem" is that native code allows to much. - You can access the hardware and play back (potentially pirated) videos in any format at high speed. - You can access sockets and do any kind of communication (AFAIK this is not possible in pepper plugins, and in NaCl only with restrictions, and you are registered with your name with Google). You could write a file sharing client, a darknet, etc.. You could have a plugin that scrapes information from other sites. And you could do it all without having a domain, and without being legally accountable. - You can access the hardware, and peripherals - I guess there is a business opportunity for Google if manufacturers have to pay so their devices (printers, 3D headsets, ...) work with Chrome. If it is not for money, then for patents, or they use it for leverage against the other companies.
- pekk 12y ago
  NaCl is not "proprietary," it's BSD-licensed
- skybrian 12y ago
  "basically impossible for anyone but Google to implement". Sheer nonsense. I don't doubt it was hard to build, but with an open source reference implementation it shouldn't be hard to clone. I mean, we're not talking about WINE here. You could start with a fork.
  - pcwalton 12y ago
    > You could start with a fork. Of what? The entire Chromium browser?
    - teacup50 12y ago
      No, and if you think that's what getting NaCL running will take, it explains a lot about the quality of Mozilla's technical output. First, the NaCL runtime and tools are NOT tied to Pepper. You could take those as-is and have the hardest part of the stack done. Second, Pepper is NOT a complex API, and anyone arguing that it is completely nuts. It provides basic abstractions around sound, 2d/3d rendering, etc. If anything, it's a relative simplified SDL equivalent. If that's hard to implement/integrate into your environment (including thread safety issues inherent in its support for threads), that says more about your browser's architectural issues than it says about Pepper. This small API surface area should be implementable as a thin shim on almost any sane browser stack: https://developer.chrome.com/native-client/pepper_stable/c https://developer.chrome.com/native-client/pepper_stable/c There's just not much there!
      - pcwalton 12y ago
        65 header files is not small.
        teacup50 12y ago
        Are you serious? You're measuring complexity by header file count? I'm sorry, but that's small. By that ridiculous metric, I have numerous projects that have involved a few man months of effort that far exceed '66 headers' worth of complexity. What a joke.
tomphoolery 12y ago
If you can run the Unreal Engine in Firefox, surely you can do the same in Chrome? I thought that was where everything was going, transpiling C/C++ code into asm.js for browser execution. NaCl and NPAPI just seem like shitty/overly-complex proprietary systems that are means to the same end. That said, it's not like Google is dropping support for NaCl anytime soon, so that might be a point made against this argument. Still, I don't feel like removing NPAPI support actually matters all that much, not nearly as much as people are making it out to be in this thread.
justinschuh 12y ago
I'm sorry, but I just don't understand where this argument is coming from. There's no mention of EME, DRM, or anything along those lines in that post, because those are the furthest possible things from a motivation to deprecate NPAPI. The reasons for deprecation are clearly stated and indisputable: NPAPI has a huge negative impact on security, stability, and performance; maintaining support places a very large burden on Chrome's development team; and NPAPI doesn't work on mobile, which is a giant and rapidly growing platform.

by gergles 12y ago

captainmuon 12y ago

Too open in every sense. One, it was fairly simple. NaCl is a complete operating system API in the browser, and basically impossible for anyone but Google to implement (because it is proprietary, but also because of its sheer complexity). Then, native browser plugins were "omnipotent" and could do anything the user could do. Of course, this has security implications, which was why people wanted to get rid of them. But these are not unsolvable. Remember how insecure browsers were a few years ago, and look at how much work has went into securing them. Chrome uses sophisticated sandboxing of its individual parts. One could use this, or other modern techniques to contain plugins (containers, virtualization. Hell, you could just run plugins under a different user with restricted rights and it would help a lot). Security worries are not the reason. The real "problem" is that native code allows to much. - You can access the hardware and play back (potentially pirated) videos in any format at high speed. - You can access sockets and do any kind of communication (AFAIK this is not possible in pepper plugins, and in NaCl only with restrictions, and you are registered with your name with Google). You could write a file sharing client, a darknet, etc.. You could have a plugin that scrapes information from other sites. And you could do it all without having a domain, and without being legally accountable. - You can access the hardware, and peripherals - I guess there is a business opportunity for Google if manufacturers have to pay so their devices (printers, 3D headsets, ...) work with Chrome. If it is not for money, then for patents, or they use it for leverage against the other companies.

pekk 12y ago
NaCl is not "proprietary," it's BSD-licensed
skybrian 12y ago
"basically impossible for anyone but Google to implement". Sheer nonsense. I don't doubt it was hard to build, but with an open source reference implementation it shouldn't be hard to clone. I mean, we're not talking about WINE here. You could start with a fork.
- pcwalton 12y ago
  > You could start with a fork. Of what? The entire Chromium browser?
  - teacup50 12y ago
    No, and if you think that's what getting NaCL running will take, it explains a lot about the quality of Mozilla's technical output. First, the NaCL runtime and tools are NOT tied to Pepper. You could take those as-is and have the hardest part of the stack done. Second, Pepper is NOT a complex API, and anyone arguing that it is completely nuts. It provides basic abstractions around sound, 2d/3d rendering, etc. If anything, it's a relative simplified SDL equivalent. If that's hard to implement/integrate into your environment (including thread safety issues inherent in its support for threads), that says more about your browser's architectural issues than it says about Pepper. This small API surface area should be implementable as a thin shim on almost any sane browser stack: https://developer.chrome.com/native-client/pepper_stable/c https://developer.chrome.com/native-client/pepper_stable/c There's just not much there!
    - pcwalton 12y ago
      65 header files is not small.
      - teacup50 12y ago
        Are you serious? You're measuring complexity by header file count? I'm sorry, but that's small. By that ridiculous metric, I have numerous projects that have involved a few man months of effort that far exceed '66 headers' worth of complexity. What a joke.

tomphoolery 12y ago

If you can run the Unreal Engine in Firefox, surely you can do the same in Chrome? I thought that was where everything was going, transpiling C/C++ code into asm.js for browser execution. NaCl and NPAPI just seem like shitty/overly-complex proprietary systems that are means to the same end. That said, it's not like Google is dropping support for NaCl anytime soon, so that might be a point made against this argument. Still, I don't feel like removing NPAPI support actually matters all that much, not nearly as much as people are making it out to be in this thread.

justinschuh 12y ago

I'm sorry, but I just don't understand where this argument is coming from. There's no mention of EME, DRM, or anything along those lines in that post, because those are the furthest possible things from a motivation to deprecate NPAPI. The reasons for deprecation are clearly stated and indisputable: NPAPI has a huge negative impact on security, stability, and performance; maintaining support places a very large burden on Chrome's development team; and NPAPI doesn't work on mobile, which is a giant and rapidly growing platform.