Flash EOL date announced
 

Adobe just announced the EOL date for Flash: end of 2020.

Here is their announcement:

Flash & The Future of Interactive Content

Google responds:

So long, and thanks for all the Flash

CNET comments:

Flash loses final appeal: Adobe sentences its web tech to death

Finally! :)
But let us hope that the people using HTML5 spend more time thinking about cross-platform and sensible code that the useless morons who coded all that Flash.

Are you kidding? My first thought is that it was the widespread adoption of EME DRM in HTML that made this possible.

The DRM seems to be vital -- I think you guys need to get voting or something because the US laws regarding DRM are now worldwide and there's not much to stop them.
As to the moronic code in Flash -- it was largely written by cheap, free (as in money) "compilers" at the behest of people who were "creative" but, apparently, too important to learn anything at all about computers.

I politely but firmly disagree.

I think that "HTML5 + JavaScript" is a vastly less-secure alternative to Flash, which was, after all, a compiled (into p-code) language. Although it was sometimes possible to largely reverse-engineer the logic because of the simple-minded techniques used by Adobe's own Flash compiler, you still couldn't do anything to alter the behavior of the source code. Which you can do, if you have the source-code (albeit in a very mangled form). The nature of JavaScript allows you to dramatically alter code simply by playing games with prototypes.

Google and Company waged a very successful battle to discredit Flash, and plug-ins in general, but I don't think the game is over yet. Haxe and Apple's Swift are clearly pointing the way to a future in which "JavaScript plus HTML5" in my view are quite likely to play no part at all.

I don't understand how being able to modify the source-code affects security at all? What kind of "security" do you have in mind? Copy protection?

Also, I think you'll find that modifying minified/obfuscated JavaScript is just as difficult as modifying p-code.

FutureSplash/Flash is really a product of a bygone age, conceived for a different purpose, which morphed into what most people regard as only a "video player". I doubt security ever really came into it and retroactively adding "security" is as stupid as that sounds.

Considering that the Flash player is actually infamous for its security vulnerabilities, I find the "it's more secure" defense to be rather amusing.

Can you point me to a case where this has actually caused issues with "security"? Whose security?

Where will that leave people who've paid for ebooks that are accessed on-line? Some of the readers won't work without a flash plug-in in the browser.

The problem to me is the presence of source code, which, because it is source, can be modified. And, as I referred to earlier, JavaScript's "prototype" mechanism means that the behavior of objects can be surreptitiously changed. It's easiest when you tamper with the "Object" object, from which every other object inherits. And, it's quite astonishing to me that you can do so – but you can.

I submit that JS+HTML5 was given no more thought for "security" than Flash ever was. The Flash plugin, just like the Java plugin and the Silverlight plugin (Microsoft dot-NET), executes compiled p-code which is or can be digitally signed. The behavior of an existing, apparently "faultless," JS program can be altered without altering the code.

However, I also think that the JS+HTML5 paradigm is fading away in the face of the mobile device. Kludge methods of building "mobile apps" that are really web-pages are no match for native code, and both Haxe and Swift are proof-positive that cross-platform apps can be built from a single code base without relying on kludges. In time, I think you will see a browser plug-in ... or, more likely, a built-in standard browser feature ... that will execute truly compiled, truly un-tamperable code in a web-browser context. It is sorely needed.

Is this a security problem or a copy protection problem?

Minified/obfuscated "source" code is not really the source. The byte code of Flash (and Java) can be easily disassembled and (unlike the output from a C compiler) even decompiled successfully because the instruction set is fairly high level and compilers are not very aggressive (they assume the presence of JIT compilation for most optimization). So in practice you can recover pretty much everything but variable names and comments from byte code (i.e., exactly the same as minified JavaScript).

To an extent, the type of injection he's talking about is how web extensions (such as Adblock and Greasemonkey) work.

Do you know where you are? ;)

Doesn't HTTPS do the equivalent of code signing for anything that comes out of a server? To intercept one would need to decrypt then recrypt the HTML(XML, whatever)?

The root-cause vulnerability is that the client's computer is effectively "the compiler."

By definition, "the client is Untrustworthy." And yet, we send the client source(!) code, and expect the client to translate this source-code into "client-computer behavior" exactly as our test-machines did in our sanitized, safe, test-labs.

However, not only is this translation process "un-trust-worthy," but the JavaScript language, itself, is amazingly "trusting!" :eek: Every statement that is executed, is executed in a context that (thanks to "prototypes" and so-forth) is determined dynamically, such that it cannot(!!), in fact, be determined statically.

Compare this to "the much-maligned Flash compiler." :eek:

With Flash, or any other true compiler, "the eventual client-computer behavior" is determined solely by the compiler, and the execution-time behavior of that compiled code is not subject to influence by purely-dynamic notions such as "prototypes."

The JavaScript language, by its very design(!), cannot be analyzed, nor verified, nor certified, "statically," because there is absolutely nothing(!) "static" about it. Everything that happens, happens on the (un-trust-worthy ...) client machine, subject to an unknowable number of dynamic influences which can neither be anticipated nor prevented.

Quite honestly, I am amazed that JavaScript has survived for such a long time.