HTML5 Flash Player (Shumway) lands in Mozilla

Post by brokenparser » Thu, Oct 03, 2013, 12:19 AM UTC

mtrimpe wrote: post #147

Terretta wrote: post #104

Earlier quoted context omitted.

> doing SWF rendering in-browser and in-sandbox makes the security nightmare that is Flash go away I think it's crucial to make sure end users concerned with security understand the difference between built-in or bundled Adobe Flash Player (Google Chrome style), and what Firefox is offering. As soon as Chrome added a built-in Flash Player, it became the preferred target for hack contests, and still falls over repeate…

> I think it's crucial to make sure end users understand the difference between built-in or bundled Adobe Flash Player And please, for the love of all that is holy, also make sure they understand what it might mean for the stability of features such as video recording. Over the past few years Chrome has repeatedly shipped PepperFlash versions with various degrees of brokenness for video recording; wreaking havoc for…

Post by roarroar » Thu, Oct 03, 2013, 1:12 AM UTC

kapowaz wrote: post #137

Recoil42 wrote: post #125

Earlier quoted context omitted.

>Flash, when used badly, becomes a self-contained sandbox for the entire experience of a website. This same argument is true for Canvas, SVG, WebGL etc.

This is true, but because of completely different toolchains it's very rarely the case that this happens. Flash, at its height, was being used with tools like Flex to build full applications. Adobe provided interface libraries for you to substitute native controls for its own (inferior) versions. Nothing like this exists yet for the tools you mention, and hopefully never will..

Post by reissbaker » Thu, Oct 03, 2013, 1:52 AM UTC

Tloewald wrote: post #121

willvarfar wrote: post #116

Earlier quoted context omitted.

Well this is counter to my understanding. As shumway - like PDF.js - is ultimately using the exact same rendering engine and scripting engine via the same interface and in the exact same way as the HTML pages are already exposing, the attack surface just got massively smaller. If there is a jpeg injection bug, its a bug in the browser proper.

It's smaller on browsers running this implementation of Flash but you're dealing with browsers running the real Flash runtime AND this new implementation, which may expose bugs you are not otherwise exposed to. Let's suppose you're an ad network and you don't want to mistakenly inject malware into other websites because that would be bad. Now you need to think of a whole bunch of new cases. E.g. you might have carefu…

Post by cpeterso » Thu, Oct 03, 2013, 2:02 AM UTC

ekianjo wrote: post #18

gkoberger wrote: post #2

Very cool. Here's some more demos: http://mozilla.github.io/shumway/

The other cool thing about this is that it could potentially bring back Flash compatibility on Linux machines since the official Flash support/updates was dropped in 2011.

Post by base698 » Thu, Oct 03, 2013, 4:02 AM UTC

brokenparser wrote: post #151

mtrimpe wrote: post #147

Earlier quoted context omitted.

> I think it's crucial to make sure end users understand the difference between built-in or bundled Adobe Flash Player And please, for the love of all that is holy, also make sure they understand what it might mean for the stability of features such as video recording. Over the past few years Chrome has repeatedly shipped PepperFlash versions with various degrees of brokenness for video recording; wreaking havoc for…

Calling shenanigans. I wrote a couple of fairly complex publishers and Chrome isn't the problematic browser (if you use ExtermalInterface correctly). It's Safari which doesn't handle plugins well, but Camera and Microphone devices should still work as Flash handles those by itself.