Implementing Pepper since Google is dropping NPAPI for good

[Hubert Figuière]

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.

[Jet Villegas]

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

_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Benjamin Smedberg]

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

[Andreas Gal]

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.
>
>

[Brian Smith]

On Mon, Sep 23, 2013 at 1:46 PM, Benjamin Smedberg <benj...@smedbergs.us>wrote:

> 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.

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."

> 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. 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.

> 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.
>

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.

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Brian Smith]

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:
>
>> 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.

http://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.

[Benjamin Smedberg]

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.
* 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.

>> 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.
>>
> 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.

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.

--BDS

[Chris Peterson]

On 9/23/13 2:41 PM, Benjamin Smedberg wrote:
> * 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.
> * That we could have a pepper Flash for Firefox in a reasonable
> timeframe (highly unlikely given the engineering costs of Pepper).

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.


cp

[Brian Smith]

On Mon, Sep 23, 2013 at 2:41 PM, Benjamin Smedberg <benj...@smedbergs.us>wrote:

> 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.

[Brian Smith]

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-pl...@lists.mozilla.org

> https://lists.mozilla.org/**listinfo/dev-platform<https://lists.mozilla.org/listinfo/dev-platform>
>



--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[Henri Sivonen]

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
hsiv...@hsivonen.fi
http://hsivonen.iki.fi/

[Yuhong Bao]

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

[Zack Weinberg]

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

[Till Schneidereit]

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.

[therealbr...@gmail.com]

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

[Robert O'Callahan]

That is a gross misrepresentation of our plan to make plugins click-to-play.

Rob
--
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 *
*

[Johnathan Nightingale]

On Sep 24, 2013, at 2:04 PM, Robert O'Callahan wrote:

> On Tue, Sep 24, 2013 at 11:55 AM, Yuhong Bao <yuhong...@hotmail.com>wrote:
>
>> 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
>>
>
> That is a gross misrepresentation of our plan to make plugins click-to-play.

Benjamin blogged with what's actually happening: https://blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in-firefox/


---
Johnathan Nightingale
VP Firefox
@johnath

[Robert Kaiser]

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