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