Live data from Hacker News

HTML5 Flash Player (Shumway) lands in Mozilla

gemal.dk

121–130 of 181 posts

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#121

Earlier quoted context omitted.

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

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.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#122
post #85

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/

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?

Just disable JavaScript.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#123

Earlier quoted context omitted.

Ignoring flash does an even better job.

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.

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

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#124

Earlier quoted context omitted.

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

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.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#125
post #75

Earlier quoted context omitted.

There's no real conceptual difference between a element, a element, a WebGL experience, a NaCl app or a Flash 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 KoolAi…

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…

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

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#126

Earlier quoted context omitted.

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.

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?

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#127
post #85

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/

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?

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

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#128
post #63

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.

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

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#129
post #10

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

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?

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#130
post #107

Earlier quoted context omitted.

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 th…

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

Post reply on HN