Flash SOL: Persistent Data with Local SharedObjects

By YUI TeamJune 23rd, 2009
Alaric Cole, Yahoo! Flash Platform Engineer

About the Author: Alaric Cole has been working in Flash since the advent of ActionScript and is currently a developer on Yahoo!’s Flash Platform team. You could say he’s grown with the language. Sure, he’s had his hand in independent film. Yeah, he wrote that one book. But his weekday ritual is still fooling about with Flash.

When he’s not crouched over a computer, you might find him riding brakeless in the Mission.

I’ve been working with Matt Snider of Mint.com to develop a new local storage utility for YUI. The utility will use a cascading storage system to detect the best way to store information through the browser, allowing a developer to store data more efficiently than a typical browser cookie — and in greater amounts. One of the storage mechanisms employs the Adobe Flash Player, and this use case has been the focus of my recent work.

Flash has a built-in persistent storage system called SharedObjects, which can be thought of as “super-cookies”, allowing the developer to store, by default, 100kb — or more, if the user allows. One of the benefits of SharedObjects, besides their capacity, is that they can store core ActionScript types, and even entire custom classes, in a binary format on the user’s hard drive. SharedObjects use the ActionScript Message Format (AMF), making them efficient and compact.

These SharedObjects are not encrypted, so while difficult to read, they are not what you would call secure storage. We’d never recommend storing important data such as user names, passwords, or other private data via a SharedObject unless you’ve implemented your own encryption mechanism. Also, SharedObjects are different from a cookie in more ways than capacity — SharedObjects are generally not attached to a specific browser but are stored independently.

These differences of the Flash storage system provide a number of benefits to the developer and the end user. However, while extremely convenient, they can also be misleading to the average user, many being unaware that such data even exists on their machine. While great lengths have been taken to provide transparency and control over private data to users via their browser (Firefox and Safari in particular providing a nice set of tools to view, edit, and remove cookies for various sites), the Flash storage system, due to its plugin nature, stores information in a separate location. This means that clearing your browser cookies does not clear these SharedObjects.

If you’re interested in viewing these bits of storage on your machine, you can check out the following locations:




/Library/Preferences/Macromedia/Flash Player/


/Application Data/Macromedia/Flash Player/

SharedObjects are typically stored in separate folders under these locations, in directories with such descriptive names as 8GKWKDQM and 227MDWL4. Under such folders are subdirectories corresponding to the domain in which the SharedObject came from.

The actual files have the *.sol extension, and there may be more than one for each domain. For instance, I found three separate SharedObject files on my machine under the youtube.com folder. They’re not human readable, as they are stored in binary.

When developing this storage utility, I wanted to be able to see the actual data stored in its raw form — but I didn’t have the time to parse through it all using a ByteArray, so I looked for a tool to do the job. I found a handy AIR application called Minerva, which can open a *.sol file and display its information. As of this writing, the current version doesn’t allow editing of the actual values stored, but there may be some other applications out there that I didn’t find.

Screenshot of Minerva application

If you’d like to remove some or all of these “Flash cookies”, you can simply delete the files or directories as needed. Note, however, that some sites make extensive use of SharedObjects, so removing them may cause unexpected behavior. Financial institutions in particular take advantage of them to aid in the security of their sites. So make sure you know what you’re doing, or create a backup before wreaking havoc.

An alternative to browsing through directories is to use Adobe’s Settings Manager. This is a Flash-based tool with special privileges that will allow you to view information about the storage on your machine, remove some or all of the stores, and set restrictions on future storage.

So, next time you want a clean slate for your browser, remember that there may be some additional information lurking on your machine that the browser can’t get to.


  1. Thanks for this detailed explanation, it confirms a lot of what I thought I knew. The one addition I would make is this disclaimer: calling the SharedObjects “Flash Cookies” implies that they are a type of cookie, which they are not. Cookies get sent with each request back to the server, and the server may alter cookies in a response. With SharedObjects, the data isn’t sent to the server and the server, in turn, can’t alter that data. Very important distinction between cookies and Flash SharedObjects.

  2. [...] the way, I also recently posted an article on the YUI Blog entitled Flash SOL: Persistent Data with Local SharedObjects. Thought I’d share it with you all, if you didn’t see [...]

  3. Flash Develop comes with a Sol reader.
    Tools >> Flash Tools >> SharedObject Reader

    There’s also an application called Sol Reader that allows you to edit shared objects (Can’t find the link).

    @Nicholas.C.Zakas Very clear distinction you’ve made. Thanks.

  4. Hi Nicholas:

    Could you point me to the source that is the basis for your disclaimer? I’m doing some ad hoc product research on possible development environments the very tiny company I work for could adopt. (When I say ad hoc I mean to imply that my boss just gave me the task and told me to run with it – I actually run HR!)

    Thanks in advance,

  5. @cisnky SOLReader is actually what was merged into FlashDevelop. Again it’s only a reader and not an editor.

    I’m actually the developer of .minerva. The reason why I haven’t added the ability to edit the files is it’s a lot more difficult to edit than read. Maybe if i ever get quite a bit of time i could probably add it in. But right now i just don’t have the time to do that. But it’s great to see that people appreciate my tool.