HTML5 Flash Player (Shumway) lands in Mozilla | Hacker News Reader

HTML5 Flash Player (Shumway) lands in Mozilla

gemal.dk

373 pointsrobin_reala176 comments

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

http://andreasgal.com/2011/06/15/pdf-js/

Ignoring flash does an even better job.

Sure, and not browsing the Web at all is even safer. But it's nice to see developments that make insecure technologies more secure.

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.

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.

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.

s/Windows/Linux/g

thanks :) I, Gabe Newell and many others would like to see this happen.

Closing your browser trumps it though...

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

If it were widely adopted, people would target it. If it's not widely adopted, who cares?

It's adopted by having a HTML 5 compliant browser, at which point you would just use HTML 5 tools.

Unless you really loved the flash IDE which I guess some people do...

There's also a lot of flash out there generated through things like libming that people either can't or won't rewrite to use html5.

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.

What features are they using that html5 doesn't cover?

I'm genuinely curious, as I do a bit of html5/webgl and formerly did a lot of flash/haxe, so I'm wondering what I missed...

Lets say DRM video for arguments sake.

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?

If it appeases the rights holders into allowing their video on the web I'm happy.

Users want to watch videos, they don't care about the technology under the hood.

Do you ever try and watch youtube videos that say, "this video isn't available on your device"...

Just saw this answer to another question about the technology:

https://news.ycombinator.com/item?id=6558539

I guess you could ask him for more details.

According to this Shumway was based on Gordon. http://www.geek.com/news/mozillas-shumway-project-replaces-f...

And you remember who Gordon Shumway is right? ( https://en.wikipedia.org/wiki/ALF_(TV_series) )

So the best way to change things is to leave no choice? Dictator-style?

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.

Just disable JavaScript.

Anything that this can do, JavaScript can do. If you're worried about losing control with JavaScript, then you should already have that disabled.

It's this sort of person who will be calling to bring back flash, so all the annoying banners and CPU intensive code can be easily blocked.

In fact IE used to lose control, so it is disabled now.

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.

> 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 repeatedly: http://www.securelist.com/en/advisories/52983

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

Safari has how much of the browser market share?

Nobody gives two glances about Safari, mate.

Pretty large if you count mobile devices.

There was a well publicized audio problem with Pepper. It broke nearly all audio playback for weeks. Happened on every platform.

Okay, but playback problems don't negate the ability to record or stream input devices.

Apart from the fact that until February this year it was impossible to keep PepperFlash disabled [1], we've so far had:

- Frequent crashes when acquiring video camera [2]

- Recorded sound being choppy and broken (still not fixed for Red5) [3]

- Audio delays and broken echo cancellation in Speex [4]

- Microphone sound levels not reported, breaking apps like ours which check if a microphone worked properly. (resolved together with [3])

- Sound stopping to record after a few minutes [5]

- Inability to give camera access on retina displays [6]

- Rushed fix for a click-jacking attack introduces horrible UX that gets into an unrecoverable state by default [7]

All in all I can personally confirm that Chrome has not been good for people doing video recording on the web.

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.

Great effort but I really don't want this.

I've lived without Flash for a year now and all is good. We just need to break the crack addiction!

It's not because you pretend Flash doesn't exist that it disappears from the Internet.

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?

I can tell you what my problem is with flash: the reference implementation by Adobe stinks.

Yes there is.

You misunderstand.

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.

Canvas, video, webgl fine.

From the fine article:

  "Shumway is an HTML5 technology experiment that explores
   building a faithful and efficient renderer for the SWF file
   format without native code assistance."

By your criteria, you should be fine with this.

Well if it wasn't for the numer of turtles in the pile on the way down it'd be fine. This is a whole other layer on top...

You end up seeing a canvas, does it matter what application was used to draw it? (by the way I don't like Flash either for different reasons)

What's so great about the "security model" of the browser? It's a patch work of horrible decisions.

Nothing at all. It's shit.

But one security model is better than having two security models.

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.

Draining excessively my CPU and Memory for no good reason, being insecure, etc.

I suspect this will not use less memory and CPU than a native plugin.

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

http://loewald.com/blog/?p=3362

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:

https://docs.google.com/spreadsheet/ccc?key=0Av4YDog3VfA-dHI...

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

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.

Flash, when used badly, becomes a self-contained sandbox for the entire experience of a website.

But if it's rendered as part of the page instead of in a black-box plugin, doesn't that whole problem go away?

No, It's about what is inside the Flash that defines your experience with it.

For me the best trade-off is still to use a flash-block and grant the flash running time when I choose to do so.

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

And you think asm.js/WebGL will be any different? The more powerful the browser gets the more open to this kind of abuse it will be. Live with it.

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.

This will actually make Flash go away faster, since now more devices and browsers can start ignoring supporting Flash.

This isn't ignoring flash, it's supporting some random subset of it with different bugs.

The main problem for me was that it was a proprietary, terribly buggy and insecure piece of code. In principle, Shumway should fix that.

The other problem is autoplaying audio and video, which is annoying in the extreme. So I hope there will remain a click-to-activate option for this.

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.

Another nay vote from me as well. I do not use Flash at all. Do not need it, nor want it.

Does this mean the FSF can cross off 'free flash player' from their high priority list? What will happen to Gnash?

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.

YouTube (which now has HTML5)

Sadly, YouTube videos that have embedded ads seem to be Flash-only.

You can still watch them with HTML5 using this addon for Firefox: https://addons.mozilla.org/en-us/firefox/addon/youtube-all-h...

I'm assuming there's a Chrome equivalent. I've completely disabled Flash in my browser now. Feels good.

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.

(I am also a Shumway contributor)

This isn't GPL, so I'm assuming work will go on.

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.

Which is great for the companies that take open source into their products and never return anything back.

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.

GPL isn't about (nor does it require) licensees to contribute anything back.

Hence the need of AGPL.

I do a lot of development with closed source software as well, but when I do open source, I take the point of only using copyleft licenses.

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.

AGPL is questionably enforceable and still only requires contributions back in a very specific case.

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

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.

Correct. I recommend https://en.wikipedia.org/wiki/Iceweasel#History_and_origin_o... for more information. Please note this:

  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.

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?):

[1] http://slashdot.org/comments.pl?sid=225606&cid=18272276

>>> NOTE: This was true as of 2007

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.

You can make "GPL version" with 1 fork though.

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.

IANAL

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.

You can make a derivative that also includes GPL parts, and the entire package will be GPL for practical purposes.

Yeah, but you can do a simple change and suddenly it's derivative and you can licence it as GPL.

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/

Thanks I didn't know about www-plugins/lightspark =) Gonna compile/install it, because adobe-flash is crashing for me all the time.

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.

Too bad. The browser is becoming general purpose with asm.js, WebGL etc. You can't hold back progress.

I think you might have misunderstood my point.

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.

animation tools. Edit: Users Wintamute and biot have solid replies as well.

Completely agree. This will just bloat more whatever browser is implemented.

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

Well, we keep dragging HTML and JS for compatibility. Will one extra legacy approach do too much harm?

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.

And other platforms like Android and Firefox OS. The areweflashyet.com demos apparently also work on iOS!

wow, just installed this on Linux, disabled the flash plugin and flash doesn't crash anymore yipiii :)

It appears that the flash testing site doesn't work with it though: http://www.adobe.com/software/flash/about/

Now I have 0 Plugins Enabled in Firefox. It's perceived about 40% slower though. :/

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.

Go to Tools->Addons.

Select the "Plugins" tab.

Select "Never Activate" for the ones you don't want to activate.

My OCD wouldn't allow a plugin that is "just there" in the browser even if it's not activated ;)

plugin.expose_full_path does nothing and about:plugins always shows the full url nowadays.

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.

A lot changes in a month in terms of software development. Try it again and let us know if it still sucks by your standards.

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.

Same thing here. I can't run silly stick man games from ~2004 on my laptop I bought 3 years ago with this.

Just like PDF.js, it's brilliant on my desktop, but unusable on my trusty old netbook (that could do this things prefectly well with native code).

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

Why is this called a HTML5 Flash player? What is HTML5 about it?

<canvas> is an HTML5 element? :)

The browser only needs to support HTML5 in order to run SWF.

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.

They dropped that a long time ago with the OpenScreenProject licensing.

Is there a reason this has to be an extension?

What is stopping it from being hosted on a webpage, which then loads flash files from URLs?

(Background: I need a way to let thousands of flash-based educational resources be usable on an iPad)

It doesn’t have to be an extension, their demo page just loads the player as a JS file:

http://mozilla.github.io/shumway/iframe/viewer.html?swf=../m...

It also works in Chrome!

This demo (nor none of the others linked to on the main Shumway page) appear to be working on my iPad, mobile Safari running iOS7.

Not sure if it's me or if it's the code. Can anyone else confirm?

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.

I wonder if this project will suffer from same things that haunt Mono and Moonlight - chasing a moving target that does not want to be reached.

Flash is far from moving fast these days.

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.

Why not to convert flash stuff to html5 directly? Using runtime is just extra overhead.

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.

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.

Various people are working on this: Jangaroo and Flex-ASJS/FalconJX (part of Apache Flex) are the two most active projects.

What black magic is this? I wonder what the performance hits will be like though.

Why would you think this is black magic? The SWF format has been open for years and there are many other flash players out there.

I removed Acrobat Reader from my computer after PDF.js.

This has the same potential. Although it's vm is implemented in pure js, not even asm.js. It may never hit the 'good enough' performance levels.

This is beautiful! There will be less need to move small casual games to HTML5, so hopefully Flash developers will be a bit happier.

Flash is dead! Long live Flash!

I've been hoping this was going to get pulled into Firefox soon. Honestly the sooner the better.

When will all that hate for Flash finally come to an end? It's growing old and boring.

So if I install the extension, do I need to disable Flash plugin on Firefox?

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.

How about video decoding? Can it rely on gstreamer for codecs support?

Why didn't this come out of Adobe a year ago?

Why would Adobe do something like this? It costs them money and it doesn't improve their position (and IMO, their goals) at all.

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?

Because is smarter to invest in developing a new tool to create HTML5 content than to invest in a tool that converts the deprecated flash to HTML5.

Smarter for whom? Adobe? It's in their interest to keep the 'depreciated' Flash going as long as possible, whilst it still makes them money.

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.

"It actually still makes them money." That was what I was saying.

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)

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.

http://en.wikipedia.org/wiki/Adobe_Flash#SwfDec

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

It suffers from the biggest disadvantage of all: being proprietary. Flash is a massive wart on the free web.

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?

It's a disadvantage for the user, and an advantage for the business. The user is the one that matters here.

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?

Thank god for noscript.

Reply on news.ycombinator.com