|Implementing Pepper since Google is dropping NPAPI for good||Hubert Figuière||9/23/13 1:29 PM|
Today Google said they'd drop NPAPI for good.
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.
PS: I truly believe that we should drop plugin support all together, but
that's not what I'm discussing here.
|Re: Implementing Pepper since Google is dropping NPAPI for good||Jet Villegas||9/23/13 1:35 PM|
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:
dev-platform mailing list
|Re: Implementing Pepper since Google is dropping NPAPI for good||Benjamin Smedberg||9/23/13 1:46 PM|
On 9/23/2013 4:29 PM, Hubert Figuière wrote: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.
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.
|Re: Implementing Pepper since Google is dropping NPAPI for good||Andreas Gal||9/23/13 1:53 PM|
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.
|Re: Implementing Pepper since Google is dropping NPAPI for good||Brian Smith||9/23/13 1:59 PM|
On Mon, Sep 23, 2013 at 1:46 PM, Benjamin Smedberg <benj...@smedbergs.us>wrote:I asked some Chromium guys how much of the Pepper API the Flash Pepper
plugin used. Their answer was literally "150%." They explained that Flash
player users APIs that are not even in the Pepper "spec."
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. Granted, Flash has its own sandbox.
However, I have very little confidence in Flash's sandbox given my
understanding of how Adobe is (barely) maintaining Flash and given that we
are the only major user of that version of Flash.
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
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
|Re: Implementing Pepper since Google is dropping NPAPI for good||Brian Smith||9/23/13 2:09 PM|
On Mon, Sep 23, 2013 at 1:46 PM, Benjamin Smedberg <benj...@smedbergs.us>wrote:
> On 9/23/2013 4:29 PM, Hubert Figuière wrote:
> We also intend to someday drop NPAPI for good. I don't think that "by thehttp://thenextweb.com/google/2013/09/23/google-chrome-drops-netscape-plugin-api-support-to-improve-stability-will-block-most-plugins-in-january-2014/
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.
|Re: Implementing Pepper since Google is dropping NPAPI for good||Benjamin Smedberg||9/23/13 2:41 PM|
On 9/23/2013 4:59 PM, Brian Smith wrote: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
* That we could have a pepper Flash for Firefox in a reasonable
timeframe (highly unlikely given the engineering costs of Pepper).
* 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.
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.
We all agree that users would be more secure without plugins. But we
can't make security decisions in a vacuum: some users *use* Java and
other minority plugins. Turning that off just means that those users are
stuck with IE or downrev Firefox. What we *can* do is use a combination
of carrots and sticks to decrease plugin usage to the point where
removing it won't affect our viability as a product:
* Use the leverage of growing mobile device populations that don't have
any plugins to incent websites authors to stop using plugins.
* Add the most common features to the web platform which currently
require plugins. This is well underway with websockets, graphics/gaming
improvements, and webrtc; I am already working with Andrew Overholt on
some other web APIs which we've identified as important.
* Replace the Adobe Flash runtime either partly or entirely with shumway.
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.
|Re: Implementing Pepper since Google is dropping NPAPI for good||Chris Peterson||9/23/13 3:40 PM|
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.
|Re: Implementing Pepper since Google is dropping NPAPI for good||Brian Smith||9/23/13 3:54 PM|
On Mon, Sep 23, 2013 at 2:41 PM, Benjamin Smedberg <benj...@smedbergs.us>wrote:
> * That "the plugin" is only Flash. No other plugin has Pepper or is likelyI am making the assumption for now that Flash is the main thing we don't
have a solution for.
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.
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.
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.
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
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.
|Re: Implementing Pepper since Google is dropping NPAPI for good||Brian Smith||9/23/13 3:56 PM|
On Mon, Sep 23, 2013 at 3:40 PM, Chris Peterson <cpet...@mozilla.com>wrote:
> Even if Firefox supported the Pepper API, we would still need a PepperJust 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.
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
|Re: Implementing Pepper since Google is dropping NPAPI for good||Henri Sivonen||9/24/13 12:40 AM|
On Tue, Sep 24, 2013 at 1:54 AM, Brian Smith <br...@briansmith.org> wrote: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
Pepper and arranging the availability of the Pepper version of Flash
to Firefox users.
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.
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?)
|Re: Implementing Pepper since Google is dropping NPAPI for good||Yuhong Bao||9/23/13 4:55 PM|
Brian Smith <brian@...> writes:Looks like it came from the original source:
|Re: Implementing Pepper since Google is dropping NPAPI for good||Zack Weinberg||9/24/13 8:19 AM|
On 2013-09-23 4:29 PM, Hubert Figuière wrote: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
|Re: Implementing Pepper since Google is dropping NPAPI for good||Till Schneidereit||9/24/13 8:32 AM|
On Tue, Sep 24, 2013 at 5:19 PM, Zack Weinberg <za...@panix.com> wrote: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.
|Re: Implementing Pepper since Google is dropping NPAPI for good||therealbr...@gmail.com||9/24/13 8:58 AM|
On Monday, September 23, 2013 3:56:52 PM UTC-7, Brian Smith wrote: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.
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.
Both are deeply problematic, on purely technical, standards-based, and business grounds.
Shumway all the way.
|Re: Implementing Pepper since Google is dropping NPAPI for good||Robert O'Callahan||9/24/13 2:04 PM|
That is a gross misrepresentation of our plan to make plugins click-to-play.
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
waanndt wyeonut thoo mken.o w *
|Re: Implementing Pepper since Google is dropping NPAPI for good||Johnathan Nightingale||9/25/13 9:17 AM|
On Sep 24, 2013, at 2:04 PM, Robert O'Callahan wrote:Benjamin blogged with what's actually happening: https://blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in-firefox/
|Re: Implementing Pepper since Google is dropping NPAPI for good||Robert Kaiser||9/26/13 1:32 PM|
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...