I’ve spent the better part of the last month running a little experiment to see how much I would miss Adobe‘s buggy and insecure Flash Player software if I removed it from my systems altogether. Turns out, not so much.
Browser plugins are favorite targets for malware and miscreants because they are generally full of unpatched or undocumented security holes that cybercrooks can use to seize complete control over vulnerable systems. The Flash Player plugin is a stellar example of this: It is among the most widely used browser plugins, and it requires monthly patching (if not more frequently).
It’s also not uncommon for Adobe to release emergency fixes for the software to patch flaws that bad guys started exploiting before Adobe even knew about the bugs. This happened most recently in February 2015, and twice the month prior. Adobe also shipped out-of-band Flash fixes in December and November 2014.
Time was, Oracle’s Java plugin was the favorite target of exploit kits, software tools made to be stitched into hacked or malicious sites and foist on visiting browsers a kitchen sink of exploits for various plugin vulnerabilities. Lately, however, it seems to pendulum has swung back in favor of exploits for Flash Player. A popular exploit kit known as Angler, for example, bundled a new exploit for a Flash vulnerability just three days after Adobe fixed it in April 2015.
So, rather than continue the patch madness and keep this insecure software installed, I decided to the pull the…er…plugin. I tend to (ab)use different browsers for different tasks, and so uninstalling the plugin was almost as simple as uninstalling Flash, except with Chrome, which bundles its own version of Flash Player. Fear not: disabling Flash in Chrome is simple enough. On a Windows, Mac, Linux or Chrome OS installation of Chrome, type “chrome:plugins” into the address bar, and on the Plug-ins page look for the “Flash” listing: To disable Flash, click the disable link (to re-enable it, click “enable”).
In almost 30 days, I only ran into just two instances where I encountered a site hosting a video that I absolutely needed to watch and that required Flash (an instructional video for a home gym that I could find nowhere else, and a live-streamed legislative hearing). For these, I opted to cheat and load the content into a Flash-enabled browser inside of a Linux virtual machine I have running inside of VirtualBox. In hindsight, it probably would have been easier simply to temporarily re-enable Flash in Chrome, and then disable it again until the need arose.
If you decide that removing Flash altogether or disabling it until needed is impractical, there are in-between solutions. Script-blocking applications like Noscript and ScriptSafe are useful in blocking Flash content, but script blockers can be challenging for many users to handle.
Another approach is click-to-play, which is a feature available for most browsers (except IE, sadly) that blocks Flash content from loading by default, replacing the content on Web sites with a blank box. With click-to-play, users who wish to view the blocked content need only click the boxes to enable Flash content inside of them (click-to-play also blocks Java applets from loading by default).
Windows users who decide to keep Flash installed and/or enabled also should take full advantage of the Enhanced Mitigation Experience Toolkit (EMET), a free tool from Microsoft that can help Windows users beef up the security of third-party applications.