Thanks for your feedback. You're at a very small intersection of users who have installed both NPAPI and PPAPI Flash Players on Mac, with Update Notification enabled.
The standalone PPAPI distribution is a relatively new offering that we made available for the population that was using Chromium-based browsers besides Google Chrome, which happens to be a very, very small fraction of the population. What we saw in practice was that community wanted Flash, but were using suboptimal techniques for installing it, and we thought it was important to give them an officially sanctioned path quickly. As you've noted, there's clearly some room for incremental improvement, and I'm happy to open a bug to see if we can ideally just update everything at once, or at the very least, provide some better differentiation.
To answer your question about why you should enable automatic updates and address some of your concerns, iI'll give you some background and context. Obviously, it's your decision to make, but there's are really good reasons for making automatic updates the default.
The release cadence and the nature of the types of invasive changes that lead to hard-to-predict functional issues in the field are a response to an increasingly well-funded and sophisticated adversary on the security front.
We actually have something like 30k automated tests and a small army of test engineers that work diligently on this product. While we do our best to identify issues before the reach the field, the combinatorial scale of all the relevant browsers, operating systems, graphics and audio chipsets and drivers, and the existing body of both well- and malformed content is not something that you can test comprehensively.
It's more important that we respond to, and to the extent possible, stay ahead of bad actors than maintain perfect backward compatibility. It's also not always possible to predict when we make a very low-level change, what the side effects will be on real-world content. When faced with an ugly decision between functional and security risk, we're going to side with security, and that occasionally means that we break stuff. While we actually have several million people using our weekly beta builds, it's also the case that that population is sometimes to small for every issue to show up in. When we break things under those circumstances, it's unfortunate, and it probably means that my weekend plans are toast, but favoring security in the risk assessment is the right thing to do.
There's also an industrial-scale ecosystem dedicated to both blocking and detecting emerging threats that starts at endpoint protections supplied by hundreds of vendors to thousands of corporate and institutional networks, plus the whole personal virus scanner market, which ends at the deployment of malware signatures and software patches for vulnerabilities in the wild.
Much like epidemiology, Herd Immunity comes in to play on the Internet. Having the ability to patch a huge swath of the internet quickly in response to one of those notifications reduces the threat to the network overall (back in the 90's and 2000's, you'd see the same exploits working reliably for 6 months after we patched, because nobody updated manually), which means that even patched vulnerabilities remain valuable for a long time. In a world where we can patch the vast majority of the population within a couple days of someone discovering an exploit in the wild means that the cost of using an exploit stays very high, and on the other end, we use proactive defense-in-depth work to drive the cost of the actual development up. In short, make it really expensive to build a working exploit, then minimize the window in which an attacker can derive any value from it.
The problem with manual updating is that you have this long-tail of machines which aren't patched regularly, and where that attack remains viable and has value. The larger that population is, the less effective your disincentives are. You always have the state-sponsored guys who aren't motivated by money and have infinite resources, but the majority of this stuff is economically driven in nature, and if the activity isn't profitable, the bad guys will move on to something with a bigger ROI.
Because automatic updates ensure that you a.) get those patches as close to immediately as we can get them to you without pushing over the entire Akamai CDN, and b.) ensure that the value of exploits post-patch is effectively nil, we would really prefer that you use them. Automatic updates provided both the best possible defense to our users, and serve up serious economic disincentives for actors developing those exploits in the first place.
While the decision to delay updates is clearly yours to make, the truth is that we're seeing exploit kits reverse engineer fixes in the latest release in order to target unpatched versions, and they're getting really fast at it. We continue to up the ante with new defense-in-depth mitigations, but that's a cat-and-mouse game. There's a new attack for every defense, and defenses generally come at the expense of performance.
Personally, today in 2016, I don't believe that manual patch management is a wise approach outside of specific and extreme circumstances (mission-critical enterprise environments, etc), and feel that the value of fast and consistent patching outweighs the occasional inconvenience of a functional bug. If you have an IT department with system administrators that can vet patches and have a wealth of other defenses at their disposal, you're in a position to take the contrarian view... but for the vast majority of people, that's not the reality.
It's also true that I totally relate to, and have taken your stance on patching in the past. My thinking has evolved with the realities of the current security landscape, and at this point, I'm happy to deal with the inconvenience of the occasional functional bug vs. worrying about contracting a well-executed piece of malware that gave an attacker persistent, unnoticed access to my system -- particularly when you're talking about applications that process untrusted content.
1 Correct answer
4
Replies
AdChoices