This is excellent for security. In the same way that Mozilla's PDF.js does PDF rendering in-browser and in-sandbox, doing SWF rendering in-browser and in-sandbox makes the security nightmare that is Flash go away.
ADDED: Mozilla blogging about security benefits of PDF.js, which apply here too to
> 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.
> Multiple vulnerabilities have been reported in Google Chrome, which can be exploited by malicious people to compromise a user's system. The vulnerabilities are caused due to a bundled vulnerable version of Adobe Flash Player.
That's not what Firefox is doing, and I hope the tech community helps regular users understand the difference.
> 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 webcam based services across the web.
Ironically enough these issues are extra hard to address, because when you tell Chrome users to 'try another browser' they all go "Nahh. I'm already on the best one."
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.
Boy, am I glad these bugs were fixed around the time I wrote my publishers. Remind me to check all the relevant bug trackers before going full steam ahead with a rewrite, ha ha.
I'd be afraid that I lose control of the flash with this. As things are now, I can safely disable the flash plugin and everything is fine. If someone is able to render flash within HTML5, how can I prevent it from doing so?
Well you can chose to disable pdf.js already; don't see why Mozilla wouldn't make swf.js configurable too. I'd expect flashblock plugins etc to continue to work also.
Flash is awful, but Firefox and the other browsers don't exactly have a great track record on security either. The less code and business built-in to the browser, the better its security.
Flash's security track record is still far, far behind Mozilla's. There aren't that many runtimes in the world that find themselves in a position to be constantly scrambling to patch egregious 0-day exploits, but somehow Flash managers.
Firefox is to Flash like a solid wooden door is to a screen door.
Even if it isn't bulletproof, it's still a huge improvement over the status quo.
And keep in mind this solution precisely fits your desires: "less code and business built-in to the browser". This Flash player runs directly on top of the existing sandbox and does not create yet-another-special-case-for-native-code. It introduces little to no additional attack surface area.
Well, we assume it's more secure than simply running Flash, but we don't know. In fact it increases the overall attack surface since now there's bugs in Adobe's implementation and bugs in this implementation to exploit.
Let's suppose we believe our site to be secure because we've tested it on Windows and Mac and checked the flash doesn't cause issues, and we've tested it on mobile and the flash simply doesn't work. Now we need to test all over again.
Consider, for example, JPEG injection bugs. There are JPEGs embedded inside Flash content that are now being parsed by different code.
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 carefully sanitized all the JPEGs on your site, but not the ones embedded in SWFs. This is merely an example.
Would it be a Good Thing if every copy of the Flash runtime magically disappeared and got replaced with this thing? Maybe. But as it is, life just got more, not less, complicated.
It might be true that as an ad network if you allow Flash files, but don't allow JS files, your life might become harder. (If you do allow JS files, your life is no different — you were already exposed to JS vulnerabilities).
As a user, though, your browser is significantly more secure running Shumway than running Flash. It literally removes an entire attack vector without adding a new one. If there's an exploitable vulnerability in Firefox's JS engine, you're vulnerable to it regardless of whether you run Shumway or not — but if there's an exploitable vulnerability in Flash, you aren't vulnerable if you're running Shumway instead.
The attack surface isn't increased. If you can exploit the vulnerability using Shumway, you could also exploit the vulnerability using vanilla JS — because Shumway is just Javascript. Shumway doesn't allow new exploits that are impossible without Shumway.
Shumway decreases the attack surface of Firefox for general-purpose browsing: most people would install Flash otherwise, and this way that (infamously broad) attack vector is removed.
Fair enough. You have to be careful taking this argument too far, though, or you end up saying something like no other browser besides IE should be developed, because it increases the attack surface.
Ultimately, individual users have to take charge of their own individual attack surface. If switching from one Flash player to another increases their personal security, it's a good thing.
Fair point. Any argument taken to extremes is probably a bad thing.
In general, I'd say replacing things with emulations of things is not a good way to get better reliability, performance, or security -- now you have bugs in the original thing and the emulation of the thing to consider.
In this case, the emulation lives within a restricted runtime environment and the real thing doesn't. But that's a performance / resource consumption / convenience / compatibility hit in exchange for "security", and those tend to fail simply because most people like their performance / resource consumption / convenience / compatibility.
Agreed, I feel like by building things like this it just hampers all the work that is being built to replace flash. The best way to change things is to make it so that learning HTML5 and JavaScript becomes worth it, and that is easily done by just not supporting flash.
I think this is aimed at legacy support, I don't think anyone would target this as a supported runtime.
Ironically most of the useful flash applications/games etc wouldn't run on these runtimes as they are using features not supported in HTML5. This sort of thing works best for crappy adverts and banners, which no one really wants anyway. This is highlighted by the fact the big competitor (Gordon?) is developed by the Google ad sense team ;)
However there are other things, like webcam/device support, some audio stuff, filters that may be very slow on a canvas and hard to run in WebGL inside other panes (overlays etc).
I'm glad DRM isn't globally accepted by the W3C Consortium, but I'm sure beneficiaries like Google, Adobe and Microsoft heavily try to subvert that state.
But Flash DRM is, like all DRM in the face of a hostile end-user, ineffective. Nobody has any problems using the plethora of tools that strip DRM from Flash video, right?
I expect there will be a new lib to replace that, I guess this would bridge the gap for those who don't update. I doubt ming would target this runtime though, would be very inefficient.
There's no real conceptual difference between a <canvas> element, a <video> element, a WebGL experience, a NaCl app or a Flash <object> on your webpage. They're all somewhat non-semantic, hard to search, rich media black boxes. So what's your particular beef with Flash, especially when rendered via HTML5? Or do you just hate all tools that enable creativity beyond a plain text website equally? Or did you just drink the Flash-should-die KoolAid without really thinking about it?
There may not be any conceptual difference, but there is a very significant difference in how these things you describe are used. Flash, when used badly, becomes a self-contained sandbox for the entire experience of a website. Besides security concerns, this approach is damaging to the overall experience of that site, since developers end up needing to re-implement native controls and functionality (scrollbars, form elements and keyboard navigation to name a few) in order to provide users with affordances they would otherwise take for granted. More often than not, the developer doesn't re-implement these features and so users are left with a sub-optimal experience (even if it is more ‘on brand’, or replete with gratuitous effects and animations). This is to say nothing for the accessibility implications.
Since the advent of smartphones and tablets that can't display Flash content, sites that do this have started to die out in favour of a combination of native applications and true HTML implementations. If the experience they're going for calls for a video or canvas element (3D or otherwise) then great, go for it. But the scope of that part of the experience is implicitly reduced, and so it doesn't result in a sub-par experience across the board (I might not be able to see your fancy WebGL 3D canvas effects, but the links to your ‘contact us’ page still work).
What I'm worried about is that by providing a compatibility path, Flash's imminent demise will be put on hold, and the sub-optimal experiences I described above see a resurgence. And that's not a good thing.
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..
Being open to abuse and being something that is commercially viable and desirable are totally different things. Yes, you can do all manner of nefarious things with native web technologies — as I understand it, this was one of the reasons it took so long for a native JS fullscreen API to be implemented, as it would open the door to spoofing the operating system's interface chrome.
But where these technologies differ is that Flash was marketed as a one-size-fits-all solution, that allowed designers and developers to work inside of a single framework. The barrier to entry is also very low: you can achieve a lot (relatively speaking) without much technical expertise — certainly when compared to how much effort it might be to do things the right way with native tech.
I don't ever see this happening with the likes of asm.js or WebGL because they're much more narrow in focus, plus they require very different (and non-trivial) skillsets to those of designers. As soon as an endeavour like this requires multiple developers and designers, it no longer appeals to your common or garden ‘chuck it over the wall’ marketing agency; the only ones that can afford to invest in this are the ones using the tools appropriately (or at least, most of them will be).
To say that asm.js and WebGL are "narrow in focus" is like saying x86 is "narrow in focus". They're general-purpose primitives that can be used for a wide variety of purposes. UDK, Unity, Gamemaker, Construct all export to HTML5. Flash has achieved a huge degree of success, so if it goes away maybe the next contender will be less damaging, but the mistake can be remade at any point, and with the power of asm.js/WebGL almost any framework can be ported.
People have always abandoned the pure, semantic HTML way as soon as the power has been there to do so. Sometimes this has been for good, sometimes for evil. You need to either turn it into a general purpose computing platform (Mozilla have been fighting this for a long time and finally lost) or leave it as a pure document browser (in other words, an application rather than a platform). But since people always want cooler, shinier things delivered faster, and the web provides fast, sort-of-safe delivery, there will be pressure from many places to start trying to eat up some of the native pie, which is how we got here in the first place.
The web people got everything wrong. They pushed a ton of waffly high-level rubbish trying to hang onto a restricted, comprehensible model, but in the end they had to cave and stick all the powerful stuff in anyway, and on a C-machine that means something like C (hence asm.js, which is a C compile target). And what we've ended up with is, frankly, pretty shit. The whole idea of nice, semantic HTML only works as a restricted application with no client-side programming facilities. Maybe in 30 years someone will have the sense to lift it out into the "user land" of the browser where it belongs.
My beef is with NaCl, objects, Applets and ActiveX etc as well, mainly because they run outside of the browser's engine, sandbox, security model and conceptual model. you also have to ship them externally to the browser.
"Shumway is an HTML5 technology experiment that explores
building a faithful and efficient renderer for the SWF file
format without native code assistance."
If the components are sufficiently isolated, I'd much rather have many smaller components (with individual security models) than one monolithic system.
That's why e.g. the Unity3d plugin is so great. A complete 3D engine (with state of the art graphics, the ability to load almost any 3d format on earth, ...) does not belong into the browser. I don't want that code on my work PC.
OTOH, its great to have the ability to run games in the browser. The performance is much better than WebGL (because it contains compiled code, and because it is a complete, tuned, engine and not just an opengl implementation). And it's fairly safe, since it's built with Mono/.NET, you don't have problems with shellcode injection etc..
So.. stay with the shit model forever? Good idea! NaCl is part of an effort to fix all this bullshit, and it's at least sort of going in the right direction.
> Or do you just hate all tools that enable creativity beyond a plain text website equally?
That would be my stance. "Creativity" mostly translates to flashy adds, and while there are numerous examples of fun, engaging and useful Flash animations, they are vastly outnumbered by Flash banners, and the math is really simple: Blocking Flash is a huge net positive.
A video element is a video. It's as well or poorly handled as, say, an image. (The QuickTime / MP4 container actually allows standardized text tracks etc. so it's capable of being more semantically tractable than most other media formats in the long run.)
The other options are all, as you say, semantically impenetrable, but that's not all there is to it.
WebGL has the advantage of delivering very lightweight and efficient graphic effects, whereas even native Flash was horribly inefficient at doing what it did. NaCl likewise is intended to deliver near native performance to embedded functionality and isn't designed for a proprietary production front-end, better than Flash on both counts.
Canvas affords JavaScript the ability to natively generate graphics that would otherwise be impossible or very difficult. Flash is pretty horrible to talk to with Javascript.
So yes, other things are impenetrable, but Flash is impenetrable and lacks the virtues of those other things.
> WebGL has the advantage of delivering very lightweight and efficient graphic effects, whereas even native Flash was horribly inefficient at doing what it did.
Fundamentally incorrect. Flash is actually an incredibly efficient file format for rich media, especially at vector animation. Look it up, you can fit amazing animations into just a few kb. Nothing can beat it on the web today for that purpose, and the Flash IDE environment is unsurpassed as a toolchain for the creation of that sort of content. Of course you can abuse it, like any other tech, and pump too many large images, videos, sounds or whatever into a SWF.
Flash's file format is fine w.r.t. compression. (It's beastly to parse, but that's a consequence of history.)
It does a terrible job of rendering graphics though (probably because the guys who wrote the lowest level parts of the engine did so a long time ago and have moved on). When Steve Jobs wrote his letter about Flash a big part of the deal was Flash's impact on battery life because it was so inefficient -- and Adobe struggled to fix this for years and then gave up.
I remember back when some Adobe blogger published a comparison of Flash to canvas animations showing Flash to be significantly faster. I, and several others, posted trivially optimized versions of the canvas code that crushed Flash like a bug, and this was Flash at the end of a long period of optimization where it carefully draws only the regions of the screen that changed, versus a pretty naive canvas implementation pretty much double-buffering its animation.
A single bouncing circle on a rectangle doesn't count as a benchmark in my opinion. Flash can be written in a performant manner, it used to be faster than HTML for almost everything, but that gap has narrowed for some specific things.
Most of all though, in my experience, Flash is usually more consistent across browsers and operating systems. Even if it's slower than the fastest browser, it's at least consistently slower.
When dealing with the desktop and/or applications on mobile devices that support AIR (i.e. supported runtimes), graphics rendering isn't an issue anymore. If you are really stuck with poor graphics performance using the traditional methods, you can just leverage Stage3D, which is just like WebGL, except it has a compatibility layer and is constrained in some ways, which can potentially make it more compatible with different underlying architectures and across more GPUs.
Going back to benchmarks though, I believe that 95% (pulled out of my behindus) of benchmarks have poorly written code / code that could be optimized to run an order of magnitude faster, so I won't engage in a benchmark fling-fest. I can at least link a few minor tests I made a while ago where I encountered the above mentioned inconsistency issues:
My favorite example of a Flash website was Adobe's store, which was 100% Flash for quite some time and virtually unusable (in different ways!) on every platform.
Fun unsubstantiated anecdote; when working for Symbian we unofficially optimised their then-new renderer for generic 2x speedups. But this was just weeks before the death of UIQ and that went nowhere...
Isn't autoplaying now pretty much impossible to stop, short of disabling JavaScript (where that's even an option)? Web pages have become an alternative, yet equivalent mechanism to flash.
Rob Sayove, the Gnash lead, was at the GNU 30th, and he's said he's basically done with Gnash. There's going to be an upcoming release, and then it's done. He was a bit concerned about the state of Flash, but Shumway gave him some hopes for the future.
The Gnash guys have done a lot of good work, but for a native open-source Flash player, Lightspark became the project to watch some time ago: http://lightspark.github.io/
I'm guessing something like HURD, some people will still work on it but it won't be the focus of anything. I haven't had any success with Gnash, it can (choppily) play YouTube (which now has HTML5) and nothing else worked.
It is Apache v2 licensed, which means that Shumway is free software. So, if Shumway functions adequately then I imagine that the FSF will consider the task complete. Believe it or not, the FSF and the GNU project don't demand that everything be GPL licensed.
Some years ago I wrote a comment on Slashdot[1] where I researched what GNU software isn't copyleft. Copying it here because it took me almost 20 minutes to find it again, and I want the info to gain some Google juice so I can find it next time I need it (maybe in 6 years?):
These are all the GNU packages not under a copyleft license I have been able to verify. I have tried to err on the side of caution, which means all the packages listed here are GNU and not copyleft, but there might be some non-copyleft GNU packages that I have failed to list:
Kawa [fsf.org]: licensed under the Kawa License [gnu.org], which is an X-11/MIT style license. Kawa is a Scheme/Emacs Lisp environment that runs on Java, in case you were wondering.
GNU less [fsf.org]: the page says it is licensed under a SimplePermissiveNowarranty, but if you download the latest less tarball from ftp.gnu.org [gnu.org], you will find it is GPLd. However, older versions of less were non-copyleft [gnu.org], and they still are, as you can still download them.
Ncurses [gnu.org], which is distributed under an X11-style license.
Proto [fsf.org], which is is a tool for finding C and C++ function prototypes (someone please explain to me what that means), in the Public Domain. This one is not downloadable from the GNU ftp, but I guess that, if they list it as a GNU project, it must be.
Quexo [fsf.org], xquery implementation using Kawa to compile to java bytecode. Under the Kawa license, which means an X11-style license.
Speex [fsf.org], an audio compression codec for voice, under the Xiph.org license (a modified BSD)
At least one other non-GNU programs is listed as being GNU on the directory, like Slib [fsf.org], a portable scheme library, which under a simple permissive non-warranty license.
Since Apache can be relicensed as I understand, doesn't that mean GNU people could just slap GPL on there if that's what stops them using it? Isn't this how they usually integrate FF anyways, by renaming it something to something like Icyfox and changing its license?
'Iceweasel' is the branding Debian applies to Firefox (and 'Icedove' for Thunderbird). That's nothing to do with the code license, it's specifically about trademark and copyright on the names and logos.
The artwork in Firefox had a proprietary copyright license.
As for the license:
The rebranded programs are available under Mozilla's
standard MPL/GPL/LGPL tri-license. Like Mozilla, the
default icons are under the same tri-license, but unlike
Mozilla, there are no trademark restrictions.
The AGPL doesn't either. We have a product based on a third-party AGPL licensed codebase and we're fully compliant even if we don't contribute everything back.
You should really read up on the licenses and the intent behind them; contributing back was never the point.
I understand, which is why I personally prefer to use copyleft licenses. However, non-copyleft licenses like Apache v2 are still compatible with free software.
On the positive side, apache has a strong patent clause. It was so much admired, that FSF used it for GPLv3 (with the single adjustment regarding patent agreements).
That is not true. The people who contributed the original Shunway code own the copyright to it. They are choosing to license it under Apache. You cannot change that since you do not own the copyright.
They may choose to "relicense" it under GPL if all the contributed agree.
What you suggest cannot legally be done. However, Apache is GPL compatible, so it can still be used in a GPL project, though its license will not change.
It's shorthand for an end result that is in practice similar. If I fork the project, add new features, and license my new code under the GPL, a user of the forked version needs to abide by the copyleft provisions. They could, of course, continue to use the original Apache v2 code without my GPL'd additions, on a non-copyleft basis, since I cannot relicense the existing code.
Nothing beats the ease with which the regular flash player can be blocked, and then occasionally loaded by mouse click as it works with flash block and the like. The danger of it becoming an extension is that it's now more difficult to have that block/override workflow. And there's always the dreadful prospect of people embedding it directly into their site, potentially leading to a new wave of blanket JavaScript blocking as a response.
The current reliance of sites on Javascript is worse than Flash ever was. Flash elements can be blocked, but if you block javascript, this disables the entire site, so you have to live with CPU chugging mess of a website.
That is sort of my point though. On the other hand, I can see myself just stopping to use sites that abuse JavaScript, keeping the "good" ones. Maybe that kind of feedback just have happened on the web a long time ago.
Why do we need this? The way that Flash has diminished in significance since high-quality browsers on smartphones and tablets emerged is a good thing. The web is better with Flash gone completely, not dragged along through compatibility layers.
First of all, good old backwards compatibility. There's large codebases still written in Flash, or perhaps things that are in Flash that will never get updated ever again (browser games being a big one), and people would like them to work even after Adobe's dropped out.
It also turns out that reimplementing Flash in HTML5 gives you a great idea of what's missing if you want to tell developers to just use HTML5. There has been quite a lot missing from the web standards that Shumway helped pushed through.
> First of all, good old backwards compatibility. There's large codebases still written in Flash, or perhaps things that are in Flash that will never get updated ever again (browser games being a big one), and people would like them to work even after Adobe's dropped out.
It's a fair point that wanting to retain the ability to run this content after there is no (working) Adobe plugin is desirable, but is the browser the best place for this? We don't demand that each version of an operating system is able to run all old application software for that OS; the preferred way of being able to do this is through virtualisation, and I'd argue that's probably a better way to do this, too.
> There has been quite a lot missing from the web standards that Shumway helped pushed through.
…such as? (I'm genuinely interested; I wasn't aware of this)
A big one that's being discussed right now is blend modes and filter effects on canvas, as we can't do a GPU blur or convolution filter on canvas contents right now. We're looking to see if it's possible to reuse some of the stuff like CSS filter effects on canvas 2D contents.
We've also helped with a lot of the baggage around audio decoding and synchronization, since Flash files can have MP3 files that require close sync to the timeline, so we need to use <audio> together with WebAudio, which is a giant bag of worms. We're still working through that on the web audio mailing list.
And we've also helped with some minor additions to the spec that aren't really too hard to implement, like canvas's isPointInStroke().
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.
This is great news. Now if only Mozilla made it easy to remove plugins just as other addons[1], we'll be all set.
[1] At present, you'll need to go to [your install folder]\extensions or check their path.
To do this, go to about:config and set 'plugin.expose_full_path' to 'true'. Now go to about:plugins where you'll see the full install path. Go to these and delete the .dll
Edit: Globally installed plugins, may affect other browsers installed on your machine. Renaming is probably safer in case you need to roll back.
In something I'm building, we have to play all kinds of clips. Some of the more "legacy" ones are unfortunately in flash. We can't get rid of them for the next few years and nobody is going to redo them in something else. So this might a really good thing to be able to get rid of the flash plugin but keep supporting those files. Thanks mozilla!
I tried to use it ~1 month ago, it wasn't a great experience. I tried playing video and several games on Kongregate, and almost nothing worked, except Flash ads (only few games showed anything similar to loading screen -- most of them just didn't start at all). But the most problematic thing was its slowness. Even small almost static ads brought entire Firefox to its knees. I am looking forward for this project, but I really hope the developers will solve the performance problems before shipping it in stable Firefox.
I've compiled new version from git, but still literally nothing except ads work. I've tried various games from Kongregate, Armor Games and Newgrounds, including very old ones, various sites with Flash video, various sites with Flash charts -- nothing. And there are still very serious slowdowns even if Shumway is not on screen.
This is great. It effectively makes ActionScript 3 into YALTCTJS; Yet Another Language That Compiles To JavaScript, just like CoffeeScript and TypeScript.
In particular, AS3 is strongly typed; you could say it puts the Java into JavaScript. It has (had?) a large developer community, and there's a lot of good code for it out there already. I quite enjoy programming it, though the endless reliance on EventListeners is a PITA.
Mind you, Flex (the UI framework) genuinely does deserve to eat flaming death. I'm convinced Adobe were trolling Apache by donating it to them.
While it has a number of poor implementation choices under the hood Flex was simply miles ahead of any competing tech for doing Rich Internet Applications 5 years ago.
It's still ahead even now, just not so decisively.
have you used haxe? it was positioning itself as a viable actionscript replacement back when actionscript was relevant, and it already compiles to javascript (and a bunch of other useful platforms).
So when ActionScript is compiled to JS, do they mean it's actually pure JS, or is this getting converted into ASM.JS? Historically, a big appeal of Flash vs. JS has been performance - ActionScript is an ugly language, but it's statically typed. And JS/canvas/whatever historically haven't been too efficient at moving vectored objects around the screen.
Then again, a the factor in Flash's favour isn't the run-time, its' the development workflow.
Shumway compiles ActionScript bytecode to JavaScript source. It cannot target ASM.JS because not all ActionScript code is typed. The goal of Shumway is to identify what is missing from the web platform and fix it, so we're working on improving graphics performance.
I wonder whether this supports all the simple animation features that made flash big back in the day (like vector animation, tweening, etc.). When people say HTML5+js is the replacement for Flash, they usually think about video players and ActionScript apps.
I also wonder, if you go through all the trouble of creating a new flash implementation, why do it in HTML+js? Why not in native code on top of a cross-platform library, such as Skia or Qt? Security is one issue, but if you start a new project you can plan for security from the start and effectively rule out buffer overflows etc. with the right programming practices. Also all modern OSes have ways to sandbox applications.
I'd very much rather have my code in small, auditable, removable plugins than put everything and the kitchen sink in the browser. Sure, you prevent buffer overflow exploits by using a well tested JS engine, but you get a load of other possible bugs that you wouldn't have if the plugin were in a separate process (DoS/hanging the browser, information leakage, cross origin scripting, etc.).
How did Mozilla get around Adobe's oppressive EULA that forbids reverse engineering? This is a major obstacle of the Gnash project. They developers cannot install Flash, because to do so would make their work illegal.
It's literally the same situation as with PDF.js. You can use it as a library for viewing pdf/swf; you can embed it into your browser. Hell, you can probably put it on your Node server.
This is great step for allowing more user control / detection over sound within Firefox.
I recently open sourced MuteTab (http://www.github.com/jaredsohn/mutetab). If MuteTab were to also work on Firefox (it builds with OpenForge right now), it should be possible to get audio indicators working within Firefox, at least for HTML5 audio/video and for Flash that is supported by Shumway.
Although perhaps a native implementation of what I just described is in the works.
While I love the concept, I don't think Shumway is ready for prime time. It doesn't work on Kongregate, last time I tried, which is the largest flash based game site there is. Youtube works nicely, but overall, unless both Flash games and videos are supported, I doubt it should be shipped.
That would be the ideal case. However, that would require the cooperation of the owners of all this Flash stuff, and there is simply no way to get them all to agree to get rid of Flash just because the reference implementation happens to be annoying, crash-prone, unsafe, etc.
So, in practice, the only way to handle the issue is to do stuff at runtime.
Similar issue to there being a colossal amount of invalid HTML out there that's never going to be made valid, so the browsers just have to do the best they can. It's the way of the web.
I think there might be a lot of complex Flash games out there that are written in AS* that would not be too easy to port to HTML5. Or at least it would be time consuming.
You don't need to install the Shumway extension if you are running Firefox Nightly builds and flip the "shumway.disabled" pref in about:config. Shumway will try to load embedded Flash content and show a little "Shumway X" button that you use to fall back to Adobe's Flash Player instead.
Adobe Edge Animate is their answer to animation in HTML 5 (not the same thing as an non-native SWF player like Shumway, but a direction they're obviously headed). Did some hands on with the early betas back at Adobe MAX 2011 - kinda felt like Flash 4 or 5 (admittedly I'm not a Flash guy, but have only played with it in the past)
From where does Adobe get money from Flash? It isn't through the Flash Player plugins (which are already free), but it does get money from tools that create Flash content. So why wouldn't it make sense for Adobe to have made a move like this?
It actually still makes them money. The Flash authoring environment is still one of the more popular methods of doing production-quality animation. See http://coldhardflash.com for lots of examples.
The Flash authoring environment is the best vector graphics editor I've used, even without the animation and scripting on top. They're still going to continue that, even if the Flash Player plugin is a bit behind.
Because Adobe has long been profiting greatly from their proprietary Flash player and other related software. Had the Flash format been a free standard and Flash player had no restriction on reverse engineering we would have had free Flash players for a long time.
Adobe actually made their Flash money from tooling and supporting services.
If they open sourced the spec and turned it into a commitie it would be in the same mess as HTML 5 and lose it's advantages (fast development, adoption for example).
That's a double edged sword, proprietary software moves much much faster which is why plugins like flash came about. They plugged the gaps required that the web working groups couldn't agree on.
If proprietary was such a big disadvantage why would it exist at all?
Was it a disadvantage for all those people who got to play great games or watch video on the web for years before HTML 5 added the canvas or video tag? Would we have half the features in HTML 5 if they hadn't been proved by plugins or implemented as experimental by proprietary browsers?
ADDED: Mozilla blogging about security benefits of PDF.js, which apply here too to
http://andreasgal.com/2011/06/15/pdf-js/