Announcement

Collapse
No announcement yet.

Google Puts Chrome NPAPI Support On Final Countdown

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Naib View Post
    I wonder if Java will convert over and whether there is any drive...
    This is the response I got from IcedTea team (a few months ago):
    We haven't yet determined if it is even possible to create a port of IcedTea-Web to PPAPI, due to the sandboxing and other restrictions Google places on extensions built with Pepper/Native Client.
    http://icedtea.classpath.org/bugzill...cgi?id=1791#c2

    Comment


    • #12
      Originally posted by GreatEmerald View Post
      That sounds just like Office Open XML.
      Not quite.

      PPAPI is under-documented because the implementation is the spec.
      OOXML is over-documented. The specification is over 6000 pages making a full implementation by a 3'rd party difficult.

      Comment


      • #13
        what's the real difference between PPAPI and NPAPI?

        Comment


        • #14
          Originally posted by Azrael5 View Post
          what's the real difference between PPAPI and NPAPI?
          NPAPI defines an interface for libraries to hook into the browser. The plugins are not contained in any way so they greatly increase the attack surface of the browser, as a vulnerability in the plugin is a full compromise of the browser / user. PPAPI was designed to support a model where plugins run inside of the same sandbox Chromium uses for the renderer processes spawned for each site. Unlike the old Flash plugin, Pepper Flash is contained in an empty chroot + process namespace + network namespace along with the seccomp-bpf whitelist to protect against kernel exploits. PPAPI is essentially just the IPC API exposed to it.

          Comment


          • #15
            Pepper is also the API exposed to NaCl / PNaCl applications, which is another layer of sandboxing within the OS sandbox similar to the JavaScript virtual machine but without the need for dynamic JIT compilation. PNaCl is similar to asm.js but has features like threads and significantly better single-threaded performance. It has a lot of potential *outside* of the web browser for sandboxed code execution where it wouldn't be used with Chromium's Pepper API.

            Comment


            • #16
              Originally posted by Daktyl198 View Post
              1. you realize the only reason Chrome is disabling it is because they want to push their proprietary PPAPI architecture, right? Browser plugins aren't going to die, they're going to become even worse.
              2. Mozilla currently has no plans of killing off NPAPI, since PPAPI really isn't a viable option for any non-chromium-based browser (for various reasons).
              has nothing to do with Google, its the fact Adobe Flash for Linux will completely Die in 2017, no more flash updates. so Mozilla have to look at doing something else like using PPAPI so linux users can use Pepper Flash in Firefox

              Mozilla wanna start doing something now about it rather than wait till its to late. , they hope by 2016 they can eradicate NPAPI from Mozilla all together an use PPAPI or something else, shumway i dont think is going anywhere
              Last edited by Anvil; 25 November 2014, 11:40 PM.

              Comment


              • #17
                Originally posted by Anvil View Post
                has nothing to do with Google, its the fact Adobe Flash for Linux will completely Die in 2017, no more flash updates. so Mozilla have to look at doing something else like using PPAPI so linux users can use Pepper Flash in Firefox

                Mozilla wanna start doing something now about it rather than wait till its to late. , they hope by 2016 they can eradicate NPAPI from Mozilla all together an use PPAPI or something else, shumway i dont think is going anywhere
                And that's only if Google is willing to allow Mozilla to incorporate it into Firefox with no major strings attached

                Comment


                • #18
                  Originally posted by DeepDayze View Post
                  And that's only if Google is willing to allow Mozilla to incorporate it into Firefox with no major strings attached
                  i cant see why Google would force Mozilla into a corner by allowing Mozilla to use Google PPAPI.

                  Comment


                  • #19
                    Originally posted by mark45 View Post
                    because PPAPI has too many poorly documented or undocumented features or which are tailored to Chrome's needs which is a no-go for non-blink, non-webkit browsers.
                    About year or two ago someone said that PPAPI is poorly documented, that PepperFlash uses internals of Chromium, that part of PPAPI is hidden. And since then, I see others repeating the same matra. Have anybody of you blaming PPAPI (or NPAPI) tried to use it?

                    I tried. With no prior knowledge of any of them. Just read available documentation, then started to code. And I must say, PPAPI is no harder than NPAPI, it's just larger. But it should have anything plugin can ask an operating system, so no doubt it would be huge. I do stumbled upon some corner cases, but from reading PPAPI docs I figured out they were already mentioned. So PPAPI is OK.

                    Originally posted by mark45 View Post
                    no-go for non-blink, non-webkit browsers.
                    I have flash version of Youtube playing music in another tab in Firefox at the moment, and it uses PepperFlash. So, as you can see, issues are solvable.

                    Comment

                    Working...
                    X