ADDED: Mozilla blogging about security benefits of PDF.js, which apply here too to
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.
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."
- Frequent crashes when acquiring video camera 
- Recorded sound being choppy and broken (still not fixed for Red5) 
- Audio delays and broken echo cancellation in Speex 
- Microphone sound levels not reported, breaking apps like ours which check if a microphone worked properly. (resolved together with )
- Sound stopping to record after a few minutes 
- Inability to give camera access on retina displays 
- Rushed fix for a click-jacking attack introduces horrible UX that gets into an unrecoverable state by default 
All in all I can personally confirm that Chrome has not been good for people doing video recording on the web.
Nobody gives two glances about Safari, mate.
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.
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.
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.
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.
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.
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.
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.
thanks :) I, Gabe Newell and many others would like to see this happen.
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 ;)
And you remember who Gordon Shumway is right? ( https://en.wikipedia.org/wiki/ALF_(TV_series) )
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...
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).
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"...
I guess you could ask him for more details.
Unless you really loved the flash IDE which I guess some people do...
I've lived without Flash for a year now and all is good. We just need to break the crack addiction!
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 same argument is true for Canvas, SVG, WebGL etc.
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).
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.
But if it's rendered as part of the page instead of in a black-box plugin, doesn't that whole problem go away?
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.
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.
"Shumway is an HTML5 technology experiment that explores
building a faithful and efficient renderer for the SWF file
format without native code assistance."
But one security model is better than having two security models.
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..
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.
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.
So yes, other things are impenetrable, but Flash is impenetrable and lacks the virtues of those other things.
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.
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.
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:
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.
(I am also a Shumway contributor)
Sadly, YouTube videos that have embedded ads seem to be Flash-only.
I'm assuming there's a Chrome equivalent. I've completely disabled Flash in my browser now. Feels good.
>>> 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)
The artwork in Firefox had a proprietary copyright 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.
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.
You should really read up on the licenses and the intent behind them; contributing back was never the point.
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 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.
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)
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().
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. :/
 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.
Select the "Plugins" tab.
Select "Never Activate" for the ones you don't want to activate.
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).
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.
It's still ahead even now, just not so decisively.
Then again, a the factor in Flash's favour isn't the run-time, its' the development workflow.
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.).
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)
Not sure if it's me or if it's the code. Can anyone else confirm?
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.
So, in practice, the only way to handle the issue is to do stuff at runtime.
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.
I've been hoping this was going to get pulled into Firefox soon. Honestly the sooner the better.
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.
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).
If proprietary was such a big disadvantage why would it exist at all?