Third-Party Storage

Users of Flash Player 8 and later have an option that’s similar to what many browsers provide for third-party cookies: Users may disable the reading and writing of client-persistent shared objects by SWFs from third-party domains. By default, third-party storage is enabled; users may disable it by visiting the Flash Player Settings Manager and unchecking Allow Third-Party Flash Content to Store Data on Your Computer. A third-party SWF is any SWF whose domain of origin does not match the primary domain the user is visiting—the domain shown in the browser’s address bar.

The third-party storage option affects both local shared objects and their lesser-known cousins, persistent remote shared objects, which are used only in conjunction with Flash Media Server (formerly Flash Communication Server).

When third-party storage is disabled, and a SWF attempts to obtain a shared object using SharedObject.getLocal() or SharedObject.getRemote(), Flash Player determines whether the calling SWF is a third party or not. Flash Player compares the SWF’s origin domain to the domain shown in the browser’s address bar and classifies the SWF as a third party if the two domains do not match exactly. If the SWF is a third party, the call to getLocal() or getRemote() returns null.

The third-party storage restriction does not affect local SWFs (those loaded from users’ filesystems); it affects remote SWFs only. Because the classification of third-party SWFs requires comparison to a browser URL, Flash Player observes the third-party restriction only when playing within the web browser; stand-alone players, projectors, and the Flash authoring players do not.

If You Are Affected

If your SWF is genuinely a third party—that is, it is being incorporated into someone else’s site—you must accept that certain users will not permit your SWF to read or write shared objects. See the next section for a discussion of why this is so.

If your SWF is being treated as a third party, but is used only within sites that are under your control, you may need to reorganize your site so that any SWFs that need to read or write persistent shared objects are always served from the primary domain that the user is visiting.

Why Limit Third-Party Storage?

Surfing the Web represents a tradeoff between privacy and convenience. Users generally cannot avoid revealing certain facts about themselves, such as their IP addresses and their choices of operating system and browser, but generally wish to keep most information about themselves private unless they deliberately provide that information to known, trusted parties. One aspect of users’ personal profiles that has been called into debate in recent years is browsing history, as revealed by tracking information stored by web content. If many different sites make a record of a particular user’s visit in a similar way, and the same or other sites are later able to read all of that information to build a picture of a user’s browsing habits, some users (and public advocates of user privacy) feel that their privacy has been violated.

There are generally two places such tracking records can be stored: on web servers and on a user’s own computer. Client technologies like web browsers and Flash Player can’t influence what happens on web servers, so this option remains available to parties who wish to learn users’ browsing history. However, storing browsing records on servers has some key disadvantages: storage space and server-to-server communication are needed, and both can be expensive. In addition, it is often difficult to identify a user across multiple visits, because identifying traits like IP addresses may vary with time, or may be shared by many users. Thus, history trackers prefer, if possible, to store records of browsing history on users’ own computers, building up a record of sites visited using a given computer.

Two technologies used to store such information are browser cookies and persistent shared objects in Flash. Browsers and Flash Player implement a same-origin security policy, which prevents sites from reading cookies or shared objects established by other sites. Because of this restriction, it is insufficient for each participating site to store a browsing record in its own data store; no other sites would be able to read this information to build up an aggregate history. Instead, a commonly used technique is to designate some single domain to record all the history information and then have each participating site reference a history-writing document from that domain, passing site-identifying information in the URL used to retrieve the document. On later visits, a history-reading document from the common domain can access all records written by the cookie-writing document, thus revealing part of the user’s browsing history.

Web browsers and Flash Player now give users control over how their history may be tracked with this technique. Browsers and Flash Player provide users with the option to disable the reading and writing of “third-party” persistent data. A third party, in this sense, is defined as any domain that does not match the primary domain the user is visiting—the domain shown in the browser’s address bar. For example, if a user has disabled third-party storage and then visits http://site1.com/index.html, and index.html includes http://common.com/writeHistory.html?domain=site1.com, and writeHistory.html attempts to read or write persistent data, the browser or Flash Player will not permit the operation because common.com is a third-party domain; the user is looking at site1.com in their browser, not common.com.