Weekly Edition
Return to the Front page
| |||||||||||||
Gnash, Lightspark, and ShumwayAdobe's proprietary and often annoying Flash format is dying, to be replaced by a bagful of open technologies like HTML5, CSS3, SVG, JavaScript, and royalty-free media codecs. Or so we are told. Of course, we have been told this story often enough over the years that it is difficult to muster genuine excitement at the news. Nevertheless, the most recent combatant to enter the ring is Mozilla's Shumway, which constitutes a distinctly different life form than existing free software projects like Lightspark and Gnash. Rather than implement Flash support in a browser plugin, Shumway translates .swf content into standard HTML and JavaScript, to be handled by the browser's main rendering engine. The sparking and gnashing of teethGnash and Lightspark are both reverse-engineered implementations of a Flash runtime (and, naturally, come with an accompanying Netscape Plugin API (NP-API) browser plugin), but they cover different parts of the specification. Gnash, the older of the two projects, implements versions 1 and 2 of Flash's ActionScript language, and the corresponding first generation of the ActionScript Virtual Machine (AVM1). This provides solid coverage for .swf files up through Flash 7, and partial support of Flash 8 and Flash 9 (including a significant chunk of .flv video found in the wild). Lightspark implements ActionScript 3 and the AVM2 virtual machine, which equates to support for Flash 9 and newer. Lightspark does have the ability to fall back on Gnash for AVM1 content, though, which enables users to install both and enjoy reasonably broad coverage without having to know the version information of Flash content in advance. As is typical of reverse engineering efforts, however, neither project can claim full compatibility with the proprietary product. In practice, development tends to focus on specific use-cases and popular sites. Gnash, for example, was founded with the goal of supporting Flash-based educational games, and previous releases have been pinned to fixing support for popular video sites like YouTube. Lightspark maintains a wiki page detailing the status of support for common Flash-driven web sites. But the sheer variety of Flash content makes it virtually impossible to implement the full specification and offer any meaningful guarantee that the plugins will render the content without significant errors. But an even bigger problem remains one of time and funding. Gnash in particular has struggled to raise the funds necessary for lead developer Rob Savoye to devote significant time to the code. Gnash has been a Free Software Foundation (FSF) high-priority project for years, and Savoye was the 2010 recipient of the FSF's Award for the Advancement of Free Software, but fundraising drives have nevertheless garnered low returns — low enough that as recently as March 2012, Savoye reported that the hosting bills for the site were barely covered. The last major release was version 0.8.10 in February 2012, which included OpenVG-based vector rendering along with touchscreen support. A student named Joshua Beck proposed a 2012 Google Summer of Code (GSoC) project to add OpenGL ES 2.0 support under Savoye's mentorship, but it was not accepted. Traffic on the mailing lists has slowed to a trickle, though there are still commits from Savoye and a devoted cadre of others. Lightspark has made more frequent releases in recent years, including two milestone releases in 2012. In June, Version 0.6.0.1 introduced support for Adobe AIR applications and the BBC web site's video player. Version 0.7.0 in October added support for LZMA-compressed Flash content and experimental support for runtime bytecode optimization. Both projects regularly make incremental additions to their suites of supported Flash opcodes and ActionScript functions, but neither has much in the way of headline-grabbing features in new releases. This is a bigger problem for Gnash, which does not have Adobe's newer enhancements to Flash to worry about (and is probably a key reason Gnash has had a hard time attracting donations). Lightspark can still tackle a host of new features with each update of Adobe Flash. Of course, both projects' real competition has come from the easy availability of a freely-downloadable official browser plugin for Linux, but Adobe announced in February 2012 that Flash 11.2 would be the last release available as an NP-API plugin for Linux. Subsequent Linux releases would only be made as the built-in Flash plugin in Google's Chrome. The move has seemingly not motivated Flash-using Linux fans to cough up support for Gnash and Lightspark — but perhaps the next major update to Flash will. I did it ShumwayMozilla developer Jet Villegas wrote a blog post introducing Shumway on November 12, but the code has been available for several months. Shumway is described as an "experimental web-native runtime implementation" of the .swf format. Shumway essentially pushes handling of the formerly-Flash content to the browser's rendering engine and JavaScript interpreter. This protects against misbehaving plugins that eat up too many resources or simply crash. Shumway is available as a Firefox extension [XPI], though it is only expected to work on the most recent Firefox beta builds. The recent Firefox build is required because Shumway parses Flash content and translates it into HTML5 elements, such as <canvas> and <video> elements, WebGL contexts, and good-old-fashioned embedded images. Shumway translates ActionScript into JavaScript to handle interactivity. Both AVM1 and AVM2 are supported, as are ActionScript versions 1, 2, and 3. The extension supports the use of <object> and <embed> tags to incorporate Flash into the page. As for multimedia codecs, Shumway can automatically take advantage of whatever codecs are available on the system. At the moment there is not a definitive compatibility list, so Shumway's support for any particular Flash file is a gamble. Villegas did say in a comment that the project is targeting Flash 10 and below, which he said accounts for "the vast majority of existing content." The idea of translating Flash content into HTML5 is not original to Shumway, but its predecessors have been focused on Flash-based advertising. Google offers a web service called Swiffy that translates uploaded Flash files into JSON objects, targeted at advertisers wanting to deploy animated ads. Smokescreen was a JavaScript player designed to render Flash ads on iOS devices. Slaying the Flash gorgonMozilla's goal with Shumway is to remove Flash from the equation altogether, replacing it with "open web" technologies. By demonstrating that HTML5 content is capable of reproducing anything that can be done in Flash, the thinking goes, the browser-maker can encourage more content creators to drop Flash from their workflows. One might think it fair to ask whether supporting Flash in any sense genuinely "promotes" the use of Flash alternatives. After all, in December 2010, Mozilla's Chris Blizzard told Joe Brockmeier that the organization was not interested in funding Flash support, open source or otherwise:
Our strategy is to invest in the web. While Flash is used on the web,
it lacks an open process for development with open specifications and
multiple competing implementations. Creating an open source version of
Flash wouldn't change the fact that Flash's fate is determined by a
single entity.
Blizzard's comment was in response to a question about supporting Gnash and Lightspark development. Sobhan Mohammadpour asked the same thing on the Shumway blog post, to which Villegas replied:
Processing SWF content in C/C++ exposes the same security & device
compatibility problems as the Adobe Flash Player. It also doesn’t help
advance the Open Web stack (eg. faster javascript and canvas
rendering) with the research work.
Such a distinction might seem like splitting hairs to some. In particular, Villegas suggests that Gnash and Lightspark are a greater security risk than an .xpi browser extension. The Gnash team might take offense at that, especially considering the work the project has done to enforce a solid testing policy. But it is certainly true that massaging Flash content into generic web content has the potential to bring .swf and .flv support to a broader range of platforms. Both Gnash and Lightspark are developed primarily for Linux, with only intermittent working builds for Windows. On the other hand, Gnash and Lightspark also offer stand-alone, offline Flash players, which can be a resource-friendly way to work with Flash games and applications. History also teaches us that it would be unwise to embrace Shumway too tightly, writing off Gnash and Lightspark as also-rans, for the simple reason that Shumway is still an experimental Mozilla project. Sure, some Mozilla experiments (such as Firefox Sync) move on to be fully integrated features in future browsers — but far more are put out to pasture and forgotten, with nary an explanation. Firefox Home, Chromatabs, Mozilla Raindrop — the list goes on and on. It is also not clear exactly what to make of Villegas's statement about Flash 10 being the newest supported version. If that is long-term limitation, then Shumway may be of finite usefulness. True, Flash may die out completely before there is ever a Flash 12, and Flash 11 may never account for a significant percentage of the web's .swf files. In that case, users everywhere will enjoy a blissful HTML5-driven future with plugin-crashes a forgotten woe, and free unicorns as far as the eye can see. But where have we heard that one before? (Log in to post comments)
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 0:02 UTC (Thu) by dtalen (subscriber, #86448) [Link]
Shumway, although it suffers from a terrible name, has the benefit of Mozilla's funding. Gnash and Lightspark don't have have that luxury, but they do have the benefit of years of development. I think that, like Nathan, that Mozilla's project will probably not see the same level of adoption.
Mozilla has the option of promoting Shumway by bundling it with Firefox, but it would be unwise to turn it on by default since it's unlikely to work perfectly. In order to prevent a backlash, they would have to have it be opt-in - and even then vast majority of users are going to prefer Adobe's implementation because it will work, and Shumway may not.
Really, the people that Shumway may serve are Linux Firefox users that don't want to run proprietary software. The problem for Shumway is that Gnash and Lightspark already serve them pretty well. Also, a small market like that is unlikely to keep Mozilla putting money into Shumway if it won't get widespread adoption.
Shumway sounds interesting, but it's likely to not garner much of a following. Mac and Windows users will continue to use the proprietary plugin, and Linux users already have "good enough" existing support.
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 0:12 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> vast majority of users are going to prefer Adobe's implementation because it will work, and Shumway may not.
That assumes that the users are going to be able to GET Adobe's implementation.
Remember that Adobe has stopped development on Flash for Linux. So new versions are going to have features that you just can't get on Linux.
so users may end up being forced to choose between the Adobe version that will work for some things, and another version that works on other things.
This completely ignores the problem of vulnerabilities in the released version and what that will eventually do to the 'everyone should just run the Adobe version' mindset.
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 1:16 UTC (Thu) by roc (subscriber, #30627) [Link]
The big issue is mobile. Adobe doesn't offer an implementation for any mobile platform anymore. On mobile it's basically Shumway or nothing, and it's not hard to beat nothing.
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 23:41 UTC (Thu) by douglasbagnall (subscriber, #62736) [Link]
> On mobile it's basically Shumway or nothing, and it's not hard to beat nothing.
Actually I have been trialling nothing for about a year now, and on balance find it to be my preferred swf player. The only feature I really miss is an h264 decoder, which sometimes tempts me to use other browsers. So while I thoroughly approve of Shumway, I can't bring myself to install it and thereby lose my nothing.
Gnash, Lightspark, and Shumway Posted Nov 23, 2012 22:10 UTC (Fri) by KaiRo (subscriber, #1987) [Link]
Mozilla is working on getting h264 decoding to work by using the hardware or software decoders already present on systems. AFAIK, that's even implemented in some of the latest Firefox for Android versions.
Using that together with Shumway will hopefully enable even a number of video sites to work that do not (yet) serve HTML5 video.
Gnash, Lightspark, and Shumway Posted Nov 27, 2012 15:58 UTC (Tue) by lambda (subscriber, #40735) [Link] Hmm. I use Flash on Android with "tap to enable". I find that gives all the benefits of "nothing", while still allowing you to access the occasional piece of content you still can't access any other way.
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 13:34 UTC (Thu) by dtalen (subscriber, #86448) [Link]
> That assumes that the users are going to be able to GET Adobe's implementation.
> > Remember that Adobe has stopped development on Flash for Linux. So new versions are going to have features that you just can't get on Linux.
That's true. I should have clarified that this point was about Windows and Mac users, and not about Linux. Given that Gnash and Lightspark don't have much of an audience there, I don't think it's a stretch to assume that Adobe's implementation will continue to be their choice.
Gnash, Lightspark, and Shumway Posted Nov 23, 2012 15:30 UTC (Fri) by drag (subscriber, #31333) [Link]
> Remember that Adobe has stopped development on Flash for Linux. So new versions are going to have features that you just can't get on Linux.
No they didn't. They just stopped development of flash netscape plugin.
The 'Pepper' version of Flash is vastly superior and is up-to-date.
It would be nice if Adobe Flash would die, but whatever happens on the Linux desktop has no bearing on it's fate.
Gnash, Lightspark, and Shumway Posted Nov 23, 2012 20:12 UTC (Fri) by nix (subscriber, #2304) [Link]
s/vastly superior/almost indistinguishable, but somewhat sandboxed and not maintenance-dead/g
(Note: Pepper Flash works perfectly well with Chromium, too, so you can have your free cake with your non-free PPAPI plugin if you want it.)
Gnash, Lightspark, and Shumway Posted Nov 23, 2012 20:58 UTC (Fri) by Jonno (subscriber, #49613) [Link]
> (Note: Pepper Flash works perfectly well with Chromium, too, so you can have your free cake with your non-free PPAPI plugin if you want it.)
Except there is no *legal* way to get the pepper Flash plugin without installing Chrome, which makes it sort of irrelevant that you don't need Chrome to run it...
Gnash, Lightspark, and Shumway Posted Dec 4, 2012 15:49 UTC (Tue) by nix (subscriber, #2304) [Link]
You can install Chrome, build Chromium, then use the latter with the former's plugin. Works fine and lets you hack all of it except the non-free plugin (though obviously there are changes you cannot make to PPAPI without breaking the plugin).
Gnash, Lightspark, and Shumway Posted Nov 29, 2012 18:18 UTC (Thu) by JanC_ (guest, #34940) [Link]
The NSAPI Flash plugin doesn't work well with (recent versions of?) Chrome/Chromium, so I suppose Google wanted the PPAPI for that reason.
(The NSAPI Flash plugin still works fine with Firefox & Opera & other browsers though...)
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 0:43 UTC (Thu) by n8willis (editor, #43041) [Link] Mac and Windows users will continue to use the proprietary plugin,They might ... unless Shumway makes headway and gets rolled into Firefox. I have no idea if that's the plan, obviously, but I suspect that no-plugin-required-built-in-Flash-decoding would sound like a plausible bullet point to Mozilla High Command. As did built-in-PDF-decoding, for instance. Nate
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 22:25 UTC (Thu) by speedster1 (subscriber, #8143) [Link]
It seems like firefox needs to come up with a decent flash interpreter of some sort in the near future, and shumway does sound simpler to work with than a solution that requires cooperation between 2 separate plugins. Unless of course, they really don't care about losing a lot more Linux users to chrome...
As a current gnash user, I would be happy to see fellow linux firefox users help fund gnash rather than jumping ship to chrome, but it just doesn't seem to be happening yet.
Gnash, Lightspark, and Shumway Posted Nov 23, 2012 15:17 UTC (Fri) by wookey (subscriber, #5501) [Link]
I've always been disappointed by the number of free software users that just installed the proprietary plugin and declared the problem solved. The small userbase of gnash and then lightspark has greatly limited the developer base and thus speed of progress.
I know it's always been easier, but the free software ecosystem isn't always about doing what's easiest. Dogfooding matters.
Yes it's true that I've never sent any patches either (I have no clue how any of this stuff works), but I have at least reported some bugs, and donated to gnash. A few thousand more people doing that for that last 4 years or so would (probably) have helped a great deal. I can't help but feel that we have collectively failed to deal well with this issue.
What about Swfdec? Posted Nov 22, 2012 8:49 UTC (Thu) by mgedmin (subscriber, #34497) [Link]
I remember there once were two promising alternatives to proprietary Flash: Gnash and Swfdec (this was long before Lightspark appeared). What happened to Swfdec, so it doesn't even get a mention on LWN today? Is it totally dead?
Latest news on its website seem to be from 2008, which probably means exactly that.
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 12:27 UTC (Thu) by elvis_ (subscriber, #63935) [Link]
I have a book here called "Miss Shumway Waves a Wand". Happiness is a warm gun, and so is a title. It fits from this perspective.
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 2:44 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Well, another Mozilla project to port to uzbl. Oh how I wish JS came as libraries so it'd be easier to manage this. Maybe an XPI translation layer could be made for uzbl to load these things easier.
is uzbl still alive? Posted Nov 22, 2012 4:24 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the latest news is from may, and prior to that from November, hardly the quarterly release cycle that they were on for a while
is uzbl still alive? Posted Nov 22, 2012 4:28 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
I pushed some new feature branches up recently and bct merged a few today and yesterday. I have a pile of branches in various states of disarray (WebKit2 support, collusion, mitmproxy in the event-manager for adblock, header manip, etc., and others). I don't know what future plans are for releases. There is a uzbl group on github now, but migration hasn't happened yet. I should prod again.
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 7:30 UTC (Thu) by Seegras (subscriber, #20463) [Link]
It's quite clear where this Shumway has to go: Onto the (proxy- ?)server, and into a standalone converter. So everyone can fix their websites (read: convert their horrible flasgh to html). And if they can't do it, the ISP can fix it in the webserver. And if the ISP can't do it, the other end can fix it in a proxy..
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 10:55 UTC (Thu) by gidoca (subscriber, #62438) [Link]
I'd rather my ISP did not try to "fix" the websites I visit. :)
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 11:33 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> I'd rather my ISP did not try to "fix" the websites I visit. :)
What about a layer even further up then? Straight in the website serving the Flash content, so that they can serve HTML5 directly?
Gnash, Lightspark, and Shumway Posted Nov 24, 2012 15:18 UTC (Sat) by tkreagan (subscriber, #4548) [Link]
Actually, that is kind of brilliant. Wouldn't it be easier as a one-time compile though? And doesn't Adobe make a tool for that?
It seems like this solves a problem for orphaned sites more than for sites which are being actively maintained.
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 17:31 UTC (Thu) by kripkenstein (subscriber, #43281) [Link]
>> Processing SWF content in C/C++ exposes the same security & device compatibility problems as the Adobe Flash Player. It also doesn’t help advance the Open Web stack (eg. faster javascript and canvas rendering) with the research work.
> Such a distinction might seem like splitting hairs to some. In particular, Villegas suggests that Gnash and Lightspark are a greater security risk than an .xpi browser extension. The Gnash team might take offense at that
I don't see why they or anyone else should take offense. C/C++ code is inherently less secure than a language like JavaScript that is sandboxed by design (and huge efforts are put into testing that sandboxing). It's just a fact that C/C++ code, by itself, is a bigger security risk.
Not that C/C++ can't be secure - browsers are written in it, for example. But it takes tons of work: stringent security reviews, huge amounts of fuzzing, security bug bounties, etc. You don't need that level of effort with JS.
Gnash, Lightspark, and Shumway Posted Nov 23, 2012 11:47 UTC (Fri) by dgm (subscriber, #49227) [Link]
Bullshit. JavaScript is only more secure if you limit your analysis to memory management, and only to certain aspects of it (DOS by memory exhaustion is perfectly possible in JS, for example). There are tons of other security threats that sandboxed languages are vulnerable to, The canonical example being SQL injection. The existence of eval() in JavaScript makes it similarly vulnerable.
Gnash, Lightspark, and Shumway Posted Nov 23, 2012 13:03 UTC (Fri) by kripkenstein (subscriber, #43281) [Link]
Yes, JS has security vulnerabilities. But it has no additional ones over C++, and has fewer (it is memory-safe, has an API designed for sandboxing, etc.).
Gnash, Lightspark, and Shumway Posted Nov 23, 2012 22:56 UTC (Fri) by khim (subscriber, #9252) [Link] The only thing which makes JS "safe" is browser's sandbox. It's perfectly compatible with C++, so I don't see what are you talking about. What awful additional "security hazards" exist in C++?
Gnash, Lightspark, and Shumway Posted Nov 24, 2012 23:45 UTC (Sat) by intgr (subscriber, #39733) [Link] > What awful additional "security hazards" exist in C++?Undefined behavior. It's the number 1 reason why computers are so insecure today.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 10:01 UTC (Sun) by khim (subscriber, #9252) [Link] Undefined behavior is a problem, yes, but JS and PHP have it's own answer to his problem: non-transitive comparisons. Practically speaking these produce similar number of vulnerabilities (well, PHP has SQL-injections which, of course dwarf both C and JS problems, but we are not comparing PHP and C, but JS and C).
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 14:02 UTC (Sun) by intgr (subscriber, #39733) [Link]
I agree that it's ugly, but... WTF, a similar number of vulnerabilities? I can see how PHP's comparison rules can cause vulnerabilities, but JavaScript is a great deal better.
On the other hand, NEARLY ALL security announcements these days are a result of undefined behavior in C code. In many cases, C undefined behavior leads to code execution, whereas that just cannot happen in JavaScript unless the coder explicitly calls eval() -- which is used almost never in real code.
Undefined behavior and intransitive comparisons aren't even in the same league.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:38 UTC (Sun) by khim (subscriber, #9252) [Link] I agree that it's ugly, but... WTF, a similar number of vulnerabilities? I can see how PHP's comparison rules can cause vulnerabilities, but JavaScript is a great deal better. No, it's not. There are about bazillion vulnerabilities found on web sites every day. I mean, XSS, data leaks, etc. Vulnerabilities which affect the web application itself, not the rest of the system. Rest of the system is not affected by JS vulnerabilities because web apps are sandboxed. Well, you can sandbox C++ application, too, so what's the big deal? On the other hand, NEARLY ALL security announcements these days are a result of undefined behavior in C code. Well, sure. That's because security-sensitive unsandboxed applications are written in C++. How many of them are written in JavaScript? In many cases, C undefined behavior leads to code execution, whereas that just cannot happen in JavaScript unless the coder explicitly calls eval() -- which is used almost never in real code. Is this a joke or are you really that dumb? Javascript programs have bazillion places where eval() can be injected. Do you add some data from user to the page? Thank you, thank you - that's eval right there, just add <script></script>. Do you change innerHTML? Thank you, thank you - that's another place for eval, just add "<script></script>". And so on. Javascript programs are actually more vulnerable then their C++ counterparts, but most problems are contained because of browser's sandbox. Well, you can add sandbox to C++, so what's the big deal?
Gnash, Lightspark, and Shumway Posted Nov 26, 2012 9:21 UTC (Mon) by intgr (subscriber, #39733) [Link]
Dafuq? In the last post you were trying to convince me how non-transitive comparisons in JavaScript *the language* is the worst security flaw ever.
Now you suddenly changed topic to HTML and web technologies and claim I'm "dumb" for not reading your mind? Remember, you were comparing C++ with JavaScript, not C++ with HTML or "the web" (does that even make sense?).
JavaScript is also used in Node.JS, Mozilla's XUL GUI, Gnome 3, PostgreSQL stored procedures, etc etc. None of these are vulnerable to the HTML vulnerabilities you describe.
And don't get me wrong -- I certainly agree that the way how web applications and JavaScript interact with HTML is a very generous place for security problems. But these aren't a problem of JavaScript *the language*.
> Do you change innerHTML?
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 20:26 UTC (Sun) by kripkenstein (subscriber, #43281) [Link]
It is possible to sandbox C++ to some extent, yes. However,
1. It was not designed for that from the beginning, so the result has some tradeoffs (not all C++ code can run in a sandbox, performance is not quite the same, etc.).
2. Practically speaking, if you have a web browser with one sandbox that you spent huge efforts on (and all do), adding another sandbox means a lot of additional effort and risk. The risk comes from the fact that each sandbox will have vulnerabilities, so having more sandboxes means more of them.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:22 UTC (Sun) by khim (subscriber, #9252) [Link] It was not designed for that from the beginning, so the result has some tradeoffs Well, of course. not all C++ code can run in a sandbox That's kinda definition of sandbox, you know. If all code (including malicious code) can run in sandbox then why will you need any sandbox at all? All correct ANSI C/C++ code should work in sandbox (as long as it does not try to do anything forbidden, that is). performance is not quite the same, etc. Without sandbox it's 100 times faster, with sandbox it's only 50 times faster. Not a big deal, really. Practically speaking, if you have a web browser with one sandbox that you spent huge efforts on (and all do), adding another sandbox means a lot of additional effort and risk. The risk comes from the fact that each sandbox will have vulnerabilities, so having more sandboxes means more of them. Not all sandboxes are created equal. If you compare 100'000 LOC of JS sandbox (with some handwaving which should explain that it works... if you are lucky) and formally proven C++ sandbox... I'm not sure amount of effort is relevant, really. Chrome example is pretty convincing: JS sandbox had more known vulnerabilities then C++ one, but, more importantly, most vulnerabilities are not in JS-specific parts or C++-specific parts but in common parts which work with WebKit.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:35 UTC (Sun) by kripkenstein (subscriber, #43281) [Link]
You are right that a small sandbox for C++ can be safer than a big one for JS. It's a fact that sandboxing a JS engine is a hard problem, it requires PICs and so forth to be fast.
But the web platform *forces* everyone to have a JS engine. So that work is already done (and the sandboxing is quite good these days). Adding another sandbox is a net increase in vulnerabilities. You can't not have the JS sandbox, but you can not have the C++ one.
Regarding 100x vs 50x - try 6x vs. 3x in modern JS engines on modern codebases.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:08 UTC (Sun) by cmccabe (guest, #60281) [Link]
Javascript has eval(), which C++ does not. This can be a security vulnerability in some cases. Not to mention the cross-site scripting attacks which can often be pulled off against JS code in the wild.
Safer than C++? Sure. "No additional vulnerabilities"? No.
Please don't turn this into yet another "my programming language is better than yours" thread.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:11 UTC (Sun) by kripkenstein (subscriber, #43281) [Link]
We are talking about different kinds of vulnerabilities. eval() can cause problems, sure, but eval in a sandbox still can't escape the sandbox. C++ code, on the other hand, can in general affect the outside system.
For a browser itself running Flash (not a website), one type of vulnerability is much more important.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:25 UTC (Sun) by khim (subscriber, #9252) [Link] We are talking about different kinds of vulnerabilities. eval() can cause problems, sure, but eval in a sandbox still can't escape the sandbox. C++ code, on the other hand, can in general affect the outside system. No, it can not do that. The most you can do is create some kind of logic fault in the program itself - exactly what eval() tends to do. Effects buffer overflows in C++ program and misquoting in eval() in JS tend to be surprisingly similar.
Gnash, Lightspark, and Shumway Posted Dec 1, 2012 11:50 UTC (Sat) by HelloWorld (guest, #56129) [Link]
> Javascript has eval(), which C++ does not.
What eval essentially does is to launch a compiler and run the resulting code in the context of the currently running program. This is perfectly possible in C++: invoke a compiler, compile to a shared object and dlopen it. There is no fundamental difference between the two in that regard.
Also, eval is much less of a problem than memory-safety, as you can simply avoid using it. You can't avoid using memory.
Gnash, Lightspark, and Shumway Posted Dec 2, 2012 23:51 UTC (Sun) by cmccabe (guest, #60281) [Link]
Do you have g++ installed on your production servers? I sure don't.
> Also, eval is much less of a problem than memory-safety,
I'm not trying to argue which is the bigger problem. I'm just responding to the bogus "no additional vulnerabilities" claim.
Incidentally, have fun searching every Javascript library that you use to make sure none of them happen to use eval(). What's that? You don't do that? Sounds like you can't "simply avoid using it" then.
Here's another piece of advice: "simply avoid writing buffer overflow exploits." Hmm. Perhaps you can't "simply avoid" a fundamental feature of the language just by pretending it doesn't exist.
Gnash, Lightspark, and Shumway Posted Dec 3, 2012 0:33 UTC (Mon) by HelloWorld (guest, #56129) [Link]
> Do you have g++ installed on your production servers? I sure don't.
That doesn't alter the fact that it's just as possible to generate code at run-time in C as it is in JavaScript. And besides, there are libraries to facilitate just that, such as libjit, Lightning or Orc.
> Incidentally, have fun searching every Javascript library that you use to make sure none of them happen to use eval().
> Here's another piece of advice: "simply avoid writing buffer overflow exploits."
> Hmm. Perhaps you can't "simply avoid" a fundamental feature of the language just by pretending it doesn't exist.
Gnash, Lightspark, and Shumway Posted Dec 9, 2012 16:24 UTC (Sun) by oak (subscriber, #2786) [Link]
>> Hmm. Perhaps you can't "simply avoid" a fundamental feature of the language just by pretending it doesn't exist.
> > eval isn't a fundamental language feature any more than libjit/Lightning/Orc are.
Do Gnash or Lightspark use libjit/Lightning/Orc?
Nowadays browsers run the Flash plugins in separate processes. Is Shumway stuff run in a separate process or within the same browser process?
If latter, HTML interaction with JS may also needs to be considered for security, not just JS in isolation.
PS. One difference between compiled C/C++ code and JS is that latter is JITted for performance reasons, and also for performance reasons, the JITted code is typically memory mapped both as executable and writable. Whereas the compiled C/C++ code isn't mapped as writable in to memory.
While the JIT compiler probably is safe, I would expect the huge amounts of extra write/execute mapped memory to make injected code execution attacks elsewhere in Browser easier...?
Gnash, Lightspark, and Shumway Posted Dec 9, 2012 18:03 UTC (Sun) by cortana (subscriber, #24596) [Link]
The pages that store the result of the JIT compilation can have their mode changed once the compilation is complete, no?
Gnash, Lightspark, and Shumway Posted Nov 22, 2012 23:27 UTC (Thu) by marcH (subscriber, #57642) [Link]
> Adobe's proprietary and often annoying Flash format is dying,...
Thank you Steve.
Gnash, Lightspark, and Shumway Posted Nov 23, 2012 10:48 UTC (Fri) by ikm (subscriber, #493) [Link]
Has anyone actually tried the thing? What was your experience like?
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 4:34 UTC (Sun) by Trelane (subscriber, #56877) [Link]
Interestingly, when the Blockbuster DVD failed to play this evening and I rented _Wall-E_ from Amazon, the main problem I encountered was DRM.
First, apparently Adobe has removed DRM from 11.3 and later: http://www.amazon.com/gp/help/customer/display.html/ref=h...
Second, even using the latest for Firefox (11.2) the movie failed to play due to DRM, specifically for needing HAL. Fortunately, the Internet saved me there.
So the key question for the future is how we can either make DRM die a flaming death or else keep Linux a viable platform for streaming.
|
|||||||||||||