Why Change Local Security?

The local security changes in Flash Player 8 are motivated by one main concern: When users download SWFs to their computers, they should be able to trust that Flash Player will not permit those SWFs to take any harmful actions against them. Wherever security is concerned, users should feel as confident downloading and running SWF files on their computers as they do storing JPEGs or TXT files, rather than having to be cautious, as they must be with executable files.

Up through Flash Player 7, the treatment of local SWFs was motivated by the meaning of a local SWF for an author of Flash content: A local SWF is usually just a temporary local file that is intended eventually to be published on the web. In this context, there is no need to restrict what local SWFs can do. However, when a SWF is downloaded and run by a user who is not a Flash author, the user may not have sufficient knowledge of the SWF’s origin to trust that its intentions are honest. In Flash Player 7 and earlier, if a malicious party managed to convince a user to download and run a SWF, that local SWF would be able to combine two privileges to ill effect: It could read text files from known (or guessed) locations in the user’s filesystem—using, for example, XML.load()—and then send the contents of those files back to the attacker. It is this file-snooping pattern that the local security changes in Flash Player 8 are designed to prevent.

A huge factor in the long-term success of Flash has been the tendency for all new releases of Flash Player to be backward-compatible with all existing Flash content. Security changes sometimes violate this principle, frustrating Flash developers and users alike. Macromedia is aware of the impact these changes have on our customers and we do not undertake such projects lightly. We offer our sincere apologies if you find yourself affected.

Despite these challenges, improving our security model is the right course for a platform technology like Flash. Flash Player enjoys incredibly broad distribution, which is a crucial part of the value of Flash to customers. Secure behavior is a requirement if we want users and businesses to continue installing and upgrading Flash Player. In hindsight, things might have been easier had we devised a more secure set of rules for local Flash content earlier in the history of Flash Player. However, security threats evolve, as do our customers’ uses of Flash, and it sometimes takes multiple releases to get something right.

The good news is that much less content should be affected by the changes in Flash Player 8 than was affected by the changes in Flash Player 7. The changes in Flash Player 7 affected some content that was deployed on the web, whereas the changes in Flash Player 8 affect only content that is deployed as local files, which is considerably less common. With Flash deployments numbering in the millions worldwide, “less common” still means there are plenty of examples of locally deployed Flash content out there, but we expect many fewer developers to be affected than were affected by the Flash Player 7 changes.