News for hackers. Stuff that matters.
Re:The Call to Kill Adobe’s Flash in Favor of HTML5 Is Rising by Silhouette on Tuesday July 14, 2015 @10:51AM (#9885298)
As an aside, we shouldn't even accept your first assumption there, because it's demonstrably not true. There are all kinds of thing that tools like Flash (and Java, and Silverlight, and even ActiveX controls) have previously been useful for that HTML5 and JS can't yet replace.

But your main point is a very good one. There are way too many people in the industry right now complaining about those older technologies who think that the world somehow magically owes them updates to 10-20 years of past work, just because their bleeding edge browser-native tools have finally reached the point in the very recent past when they can do some of the same work to a useful degree.

There are also way too many people moaning about how these plug-ins are such horrendous security problems while ignoring the facts that (a) every major browser also has a less than stellar track record on security issues, with Firefox and Chrome patching numerous vulnerabilities in updates every few weeks, and (b) moving the more advanced, and often hardware-accelerated, functionality from plug-ins to native browser capabilities isn't really reducing the area of the attack surface, it's just reshaping it. Given these facts, there is little reason to assume that browsers will inherently be more secure just because plug-ins were forced out in favour of native technologies. As others have been pointing out today, the reverse might actually be true, because at least the plug-ins have a degree of isolation and click-to-play safeguards are now widespread, while the trend with browsers (again, particularly Firefox and Chrome) is to remove obvious settings that would allow users to turn off certain functions.

Re:The Call to Kill Adobe’s Flash in Favor of HTML5 Is Rising by pyre on Tuesday July 14, 2015 @11:16AM (#9885541)
Don't most of the Chrome vulnerabilities used in pwn2own end up being Java or Flash vulnerabilities?
Re:The Call to Kill Adobe’s Flash in Favor of HTML5 Is Rising by dangerlibrary on Tuesday July 14, 2015 @11:36AM (#9885713)
Things that do more have a larger attack surface.
Re:The Call to Kill Adobe’s Flash in Favor of HTML5 Is Rising by pyre on Tuesday July 14, 2015 @02:19PM (#9886962)
Exactly. This is why the argument of "well, you can't complain about Flash/Java exploits because the browser itself also has exploits too" is not valid. By adding Flash/Java to the browser you are increasing the attack surface of the browser "package" as a whole.
Re:The Call to Kill Adobe’s Flash in Favor of HTML5 Is Rising by Silhouette on Tuesday July 14, 2015 @02:27PM (#9887020)
By adding Flash/Java to the browser you are increasing the attack surface of the browser "package" as a whole.

By adding HTML5 video and now its DRM-related infrastructure, WebGL, and other features that developers used to use Flash/Java for, you are also increasing the attack surface of the browser "package" as a whole. The comparison is a perfectly reasonable one.

Re:The Call to Kill Adobe’s Flash in Favor of HTML5 Is Rising by pyre on Tuesday July 14, 2015 @04:23PM (#9887771)
On the other hand, those will be separate implementations on different browsers, so it reduces the applicability of any one exploit. An exploit in Flash or Java becomes cross-browser.
Re:The Call to Kill Adobe’s Flash in Favor of HTML5 Is Rising by Silhouette on Tuesday July 14, 2015 @08:11PM (#9888958)
On the other hand, those will be separate implementations on different browsers

Unless more than one browser uses, say, the same video codecs, or the same third-party DRM-related module, or the same system services for doing hardware-accelerated 3D rendering.

There may be some marginal advantage to having different implementations in different browsers, but marginal is probably all it is. Realistically, as things we used to do in the likes of Flash or Java move into browser-native implementations, there is still no reason to assume that the people writing those implementations will magically produce completely secure implementations where no-one ever has before.