After working with PowerShell for awhile, then starting to write scripts, you quickly learn about PowerShell’s Execution Policy and other security features. You might even throw up your hands, and ask, “Why is this configuration so HARD? Why can’t it be as easy as VBS and Perl?” You can double-click on a VBS or CMD script and have it run automatically. Those scripts could invoke PowerShell anyways, so why put all this effort into security?

Double-click-to-run illustrates a weakness in vbscript’s design, not PowerShell’s. You could also double-click an EXE and have it do whatever you want. We’re concerned about being the entry point for an attack, not the means by which it is carried out.

The problem is that the world is extremely sensitive to scripting security. More sensitive than they are about EXE security. This is mostly driven by an over-reaction to a rude awakening: in the times of Melissa / ILoveYou, many people didn’t even know that these things called “scripts” were functionally equivalent to executables. That burned the Outlook developers, Exchange developers, network administrators, system administrators, and poor CEOs that thought a love letter must most naturally be about them.

During those outbreaks, millions of people watched their Outlook inbox fill with “love letters” from intelligent co-workers. Since the virus wasn’t a worm, each one of those was the result of somebody double-clicking on a script out of curiosity.

Fast forward a few years, and many of you already live in a world of retribution and over-reaction where “security experts” give guidance on how to remove WSH and scripting support from Windows: http://www.bing.com/search?q=uninstall+wsh. On the PowerShell team, we constantly hear from people impacted by these Mordac-like policies applied to PowerShell. Execution Policies often get abused as user restrictions, as misguided and ineffective as that is. See our Security Guiding Principles for more information about why Execution Policies are not user restrictions!

Being beyond reproach when it comes to security is crucial to PowerShell’s success. It’s the reason you can sing loudly from the rooftops for things such as this: http://it.slashdot.org/it/05/08/05/0411254.shtml.

Now, the lack of shell association indeed made it difficult to use PowerShell scripts from other automation programs in V1. While usability and security tend to conflict, we’re always looking for ways to get both. For example, in V2, we added the right-click option “Run with PowerShell” to address the interactive case. We added a “-File” parameter to PowerShell.exe to address the “dumb quoting and path translation” issues that used to make it difficult to launch PowerShell scripts from outside of PowerShell. We added an “–ExecutionPolicy” parameter (and other execution policy scopes) to let you use PowerShell.exe to automate tasks with no permanent system impact.

By writing a PowerShell script, you’re already among the very small population of computer users that understand scripting, security, and the impact of malware. It’s easy to lose track of the fact that not everybody has the same experience, background, and knowledge. PowerShell’s security features are designed to level the playing field for everybody else.