Re: Implementing Pepper since Google is dropping NPAPI for good
Johnathan Nightingale schrieb: Benjamin blogged with what's actually happening: https://blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in-firefox/ Hmm, I would have expected that to appear on Planet Mozilla Projects, but I don't see it there... Robert Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
On Tue, Sep 24, 2013 at 1:54 AM, Brian Smith br...@briansmith.org wrote: I am making the assumption for now that Flash is the main thing we don't have a solution for. In the present tense, we have neither Pepper nor Shumway shipping. Considering what we'll have in the future, do you have a reason to believe Shumway wouldn't qualify as a solution, particularly with some current uses of Flash migrating to browser-native APIs? On the topic of getting current uses of Flash to migrate to browser-native APIs, perhaps contributing to one of the Flex to JavaScript compilers would be more cost-effective than implementing Pepper and arranging the availability of the Pepper version of Flash to Firefox users. I am not making this assumption. I am not saying we should/must do Pepper. I am saying that it isn't right to say there is little benefit to Pepper. Even with Flash being the only Pepper plugin, the (potential) security advantages of Pepper make it very valuable. That's assuming that there would be a way to get a Pepper version of Flash to Firefox users under reasonable terms/price and that Shumway wouldn't satisfy users' swf rendering needs. Also, several internal systems within Mozilla Corporation are Flash-based, including our company-wide videoconferencing system and parts of our payroll system (IIUC). I think it would be great if we developed a plan for Mozilla Corporation to be able to dogfood a Flash-player-free Firefox internally by the end of 2014, at least. That would be a great goal. I'm really looking forward to a WebRTC-based replacement for Vidyo. (Fun security speculation experiment: How much less secure are Mozilla's LDAP passwords because Vidyo forces people to have passwords that they are able to type into a Flash applet repeatedly instead to letting Firefox manage a long randomly generated unrememberable password?) -- Henri Sivonen hsivo...@hsivonen.fi http://hsivonen.iki.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
Brian Smith brian@... writes: Note in particular, this quote from that article: Furthermore, Mozilla plans to block NPAPI plug-ins in December 2013. People are asking me about that on Twitter now. Looks like it came from the original source: http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
On 2013-09-23 4:29 PM, Hubert Figuière wrote: PS: I truly believe that we should drop plugin support all together, but that's not what I'm discussing here. I think if we think our options going forward are implement PPAPI and dump plugins altogether, we should seriously consider both. Having said that, I think keep NPAPI around for compatibility's sake, but promulgate our own pure-JS object API is probably the most Mozillaish position. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
On Tue, Sep 24, 2013 at 5:19 PM, Zack Weinberg za...@panix.com wrote: On 2013-09-23 4:29 PM, Hubert Figuière wrote: PS: I truly believe that we should drop plugin support all together, but that's not what I'm discussing here. I think if we think our options going forward are implement PPAPI and dump plugins altogether, we should seriously consider both. The first of these simply isn't an option at all. We can not re-implement or import all of Chromium. Even if we could, though, it wouldn't gain us anything. For one, PPAPI Flash uses internals of Chromium (and maybe Chrome?) that aren't part of PPAPI. More importantly though, we don't have PPAPI Flash, and probably won't get it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
On Monday, September 23, 2013 3:56:52 PM UTC-7, Brian Smith wrote: Just to re-iterate: I am not saying we should/must do a Pepper Flash Player in Firefox. I am not particularly for or against it. Get back off the fence :-P. We are not going to do Active G now, any more than we were going to do Active X 10-12 years ago. However, I will say that the people at Google that worked on Chromium's sandboxing and Pepper have already reached out to us to help us with sandboxing. Of course they have. I talk to Googlers at higher and lower levels all the time. They can't make a straight-up standards-track case for Pepper, NaCl, or even PNaCl, so they are trying market power. Since they don't have Microsoft-in-2001-level market share they are also nudging us now and then to jump on board. We shouldn't assume that they wouldn't help us with the Pepper Flash player without asking them. It might actually be easier to secure help from Google than from Adobe. Both are deeply problematic, on purely technical, standards-based, and business grounds. Shumway all the way. /be ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
The only Pepper plug-in worth talking about is the Flash Player. The Flash Player that ships in Chrome is developed by Google and distributed with the Chrome browser. That is, Adobe doesn't make this Pepper plug-in and has no installers for Firefox users to use. In other words, Pepper support doesn't get you a Pepper Flash Player in Firefox. We're going in a rather different direction: https://blog.mozilla.org/research/2012/11/12/introducing-the-shumway-open-swf-runtime-project/ --Jet - Original Message - From: Hubert Figuière h...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Monday, September 23, 2013 1:29:14 PM Subject: Implementing Pepper since Google is dropping NPAPI for good Hi all, Today Google said they'd drop NPAPI for good. http://news.cnet.com/8301-1023_3-57604242-93/google-begins-barring-browser-plug-ins-from-chrome/ Bug 729481 was WONTFIXED a while ago. tl;dr : implement Pepper plugin API I think it might be worth the revisit that decision before it is too late. Hub PS: I truly believe that we should drop plugin support all together, but that's not what I'm discussing here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
On 9/23/2013 4:29 PM, Hubert Figuière wrote: Hi all, Today Google said they'd drop NPAPI for good. We also intend to someday drop NPAPI for good. I don't think that by the end of 2014 is a realistic timeline for either Chrome or us, given the number of users who still rely on Java and other plugins. But we're certainly looking into the places where people currently need plugins and are trying to create or implement web APIs to address those needs. http://news.cnet.com/8301-1023_3-57604242-93/google-begins-barring-browser-plug-ins-from-chrome/ Bug 729481 was WONTFIXED a while ago. tl;dr : implement Pepper plugin API I think it might be worth the revisit that decision before it is too late. Too late for what? What are you concerned about? We are not constrained by Chrome's decision to drop NPAPI. Right now Flash is the only significant plugin that is using pepper, and it also has a supported NPAPI version. We're also working on a pure-JS replacement (Shumway) which is going quite well. The costs of Pepper are huge: it is not a well-specified API; we'd be reverse-engineering large bits of chromium code in order to support it, and it's clear that we want to focus effort on the web not Pepper. Given that Pepper presents little benefit to users, I don't think it makes any sense to focus on it relative to other things such as graphics performance, web API improvements, and asm.js which can serve the sam general niche as plugins, but will improve the open web at the same time. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
Pepper is not an API, its basically a huge set of Chromium guts exposed you can link against. The only documentation is the source, and that source keeps constantly changing. I don't think its viable for anyone to implement Pepper without also pulling in most or all of Chromium. Pepper is Chrome, and Chrome is Pepper. This is the reason that we won't-fixed bug 729481, and nothing has changed since then. I don't think we should spend energy on getting onto Google's Pepper treadmill. We should instead continue to accelerate the decline of plugins by offering powerful new HTML5 capabilities that obsolete plugins. Andreas On Sep 23, 2013, at 1:29 PM, Hubert Figuière h...@mozilla.com wrote: Hi all, Today Google said they'd drop NPAPI for good. http://news.cnet.com/8301-1023_3-57604242-93/google-begins-barring-browser-plug-ins-from-chrome/ Bug 729481 was WONTFIXED a while ago. tl;dr : implement Pepper plugin API I think it might be worth the revisit that decision before it is too late. Hub PS: I truly believe that we should drop plugin support all together, but that's not what I'm discussing here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
On Mon, Sep 23, 2013 at 2:41 PM, Benjamin Smedberg benja...@smedbergs.uswrote: On 9/23/2013 4:59 PM, Brian Smith wrote: Given that Pepper presents little benefit to users, Pepper presents a huge benefit to users because it allows the browser to sandbox the plugin. Once we have a sandbox in Firefox, NPAPI plugins will be the security weak spot in Firefox. You're making some assumptions here: * That the plugin is only Flash. No other plugin has Pepper or is likely to use pepper. And a significant number of users are still using non-Flash plugins. I am making the assumption for now that Flash is the main thing we don't have a solution for. * That we could have a pepper Flash for Firefox in a reasonable timeframe (highly unlikely given the engineering costs of Pepper). I am not making this assumption. I am not saying we should/must do Pepper. I am saying that it isn't right to say there is little benefit to Pepper. Even with Flash being the only Pepper plugin, the (potential) security advantages of Pepper make it very valuable. * That Flash is the primary plugin attack vector we should protect against. We know *out of date* Flash is an attack vector, but our security blocking already aims to protect that segment of the population. Up-to-date Flash does not appear to be highly dangerous. Vulnerabilities are dangerous even when we don't know about them. And, even when we do know about them, they are dangerous until the user can update to a version without the vulnerability. My understanding is that if there were a zero-day exploit in the Flash plugin, and Adobe took a week to ship a fix, then all of our users would be vulnerable to that zero-day vulnerability for a week or more. We need a story and a timeline for securing plugins. Click-to-play was a great start, but it is not enough. If our story for securing plugins is to drop support for them then we should develop the plan with a timeline for that. What is your definition of enough? With the change to mark plugins as click-to-play by default, they will be at least as secure as Firefox extensions, and less attack surface. Like I said, the click-to-play change is a huge improvement. I can't emphasize that enough. We don't have a sandbox for Firefox itself yet, so now is not the time to be super critical of potential weaknesses in Adobe's sandbox for Flash to argue that the exception for Flash is unreasonable. I think everybody should feel good with the progress here. These are all longer-term items, some of which are still research-y. I don't think it's either possible or necessary to develop a plan with a timeline in our current situation. I don't think we necessarily need a detailed timeline for killing plugins completely. I agree it would likely be impractical to create one even if we tried. But, we should be able to create and share plans for what we can accomplish regarding improving things with respect to plugins in the next year, at least. For example, in your earlier comments, you said that it didn't seem realistic to kill NPAPI plugins by the end of 2014. I suppose that includes, in particular, Flash. I agree with you, though I think there are some people at Mozilla that disagree. Either way, it seems like we should develop a more concrete plan for dealing with Flash security issues, at least, for 2014--e.g. creating a plan to make click-to-play for Flash in the event of a zero-day in the Flash player a viable alternative. I would be happy to help create such a plan. Also, several internal systems within Mozilla Corporation are Flash-based, including our company-wide videoconferencing system and parts of our payroll system (IIUC). I think it would be great if we developed a plan for Mozilla Corporation to be able to dogfood a Flash-player-free Firefox internally by the end of 2014, at least. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
On Mon, Sep 23, 2013 at 3:40 PM, Chris Peterson cpeter...@mozilla.comwrote: On 9/23/13 2:41 PM, Benjamin Smedberg wrote: Even if Firefox supported the Pepper API, we would still need a Pepper version of Flash. And Adobe doesn't have one; Google does. When I was an engineer on Adobe's Flash Player team, Google did all development and builds of Flash for Pepper. Adobe just verified that Google's builds pass a certification test suite. Just to re-iterate: I am not saying we should/must do a Pepper Flash Player in Firefox. I am not particularly for or against it. However, I will say that the people at Google that worked on Chromium's sandboxing and Pepper have already reached out to us to help us with sandboxing. We shouldn't assume that they wouldn't help us with the Pepper Flash player without asking them. It might actually be easier to secure help from Google than from Adobe. Cheers, Brian __ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/**listinfo/dev-platformhttps://lists.mozilla.org/listinfo/dev-platform -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
