Live data from Hacker News

HTML5 Flash Player (Shumway) lands in Mozilla

gemal.dk

171–180 of 181 posts

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#171
post #161

Earlier quoted context omitted.

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

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#172
post #132

Earlier quoted context omitted.

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.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#173

Earlier quoted context omitted.

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

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.

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.

[1] https://code.google.com/p/chromium/issues/detail?id=150596 [2] https://code.google.com/p/chromium/issues/detail?id=140831 [3] https://code.google.com/p/chromium/issues/detail?id=136624 [4] https://code.google.com/p/chromium/issues/detail?id=144554 [4] https://code.google.com/p/chromium/issues/detail?id=152314 [4] https://code.google.com/p/chromium/issues/detail?id=140724 [5] https://code.google.com/p/chromium/issues/detail?id=168859 [6] https://code.google.com/p/chromium/issues/detail?id=177621 [7] https://code.google.com/p/chromium/issues/detail?id=155437

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#174
post #134

Earlier quoted context omitted.

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.

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

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#175

Earlier quoted context omitted.

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

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#176

Earlier quoted context omitted.

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

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.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#177

Earlier quoted context omitted.

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

Let's suppose you have no idea what you're talking about.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#178

Earlier quoted context omitted.

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.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#179

Earlier quoted context omitted.

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.

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

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.

Re: HTML5 Flash Player (Shumway) lands in Mozilla

#180
post #143

Earlier quoted context omitted.

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

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

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.
Post reply on HN