Hacker News Reader

Comment by willvarfar | Hacker News Reader

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/

View on HN

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

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.

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?

Reply on news.ycombinator.com