Re: Implementing Pepper since Google is dropping NPAPI for good

[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
___
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

[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 wrote:
> 
>> Brian Smith  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

___
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

[Robert O'Callahan]

On Tue, Sep 24, 2013 at 11:55 AM, Yuhong Bao wrote:

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

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

[therealbrendaneich]

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

[Till Schneidereit]

On Tue, Sep 24, 2013 at 5:19 PM, Zack Weinberg  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

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

[Yuhong Bao]

Brian Smith  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

[Henri Sivonen]

On Tue, Sep 24, 2013 at 1:54 AM, Brian Smith  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]

On Mon, Sep 23, 2013 at 3:40 PM, Chris Peterson wrote:

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



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

[Brian Smith]

On Mon, Sep 23, 2013 at 2:41 PM, Benjamin Smedberg 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.

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

[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
___
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

[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

___
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]

On Mon, Sep 23, 2013 at 1:46 PM, Benjamin Smedberg 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.

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

[Brian Smith]

On Mon, Sep 23, 2013 at 1:46 PM, Benjamin Smedberg 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)
___
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

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

[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

___
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

[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

- Original Message -
From: "Hubert Figuière" 
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