On OSX, three locations are relevant for these:

1. /Users/<username>/Library/Preferences/Macromedia/Flash Player/#SharedObjects/<8 random alphanumeric characters>
   
2. /Users/<username>/Library/Preferences/Macromedia/Flash Player/macromedia.com/support/flashplayer/sys/
3. /Users/<username>/Library/Application Support/Microsoft/Silverlight/is/<8.3 random alphanumeric>/<8.3 random alphanumeric>/1/
   

The first is where Adobe Flash LSOs are stored, the second is where site-specific Flash configurations are stored and the final is where Microsoft Silverlight LSOs are stored. Adobe LSO's are stored in files with the .sol extension. Silverlight uses a more complex storage mechanism and stores the data in a series of .dat & .txt files.

At first I played with just nuking everything with a recursive force delete. This will clear out anything in the LSO stores. You can even safely go as high up the directory tree as to exclude the <random dirs> e.g. rm -rf /Users/<username>/Library/Application Support/Microsoft/Silverlight/is/*. However, this will not prevent future LSOs from being set. This will help provide anonymity (from techniques using these identifiers) between each clearing out, but not during, and frankly isn't good enough.

Next, I wanted to prevent them from being re-set. So, I looked at disabling the top-level storage directories by removing all permissions, but that causes undefined behaviour including Safari crashes and Flash/Silverlight universally not running. But Adam Shostack has helpfully sent me a script he had created which deleted the files, recreated blanks, and removed permissions. So, I set about experimenting with that. What I found was that while this works fine for Silverlight, it doesn't for Flash. Flash happily ignores the permissions and just overwrites the file (no symlink vuln here, I checked). Ok, so I then tried linking them to /dev/null, same thing, works for Silverlight, but Flash just sets them back. In some cases, Flash will even go so far as to temporarily use different file extensions to write the files, and move them over to the original once they're available again. Is it just me or is that overly persistent? I eventually worked out, by actually looking at Adam's code, that changing perms or symlinking to /dev/null on the directory containing the .sol rather than the .sol itself works. However, even then, the browser seems to still be able to create temporary LSOs in memory that persist until refreshed.

I eventually decided using the programs' own configuration options was probably the best way. Both Flash and Silverlight have a configuration option to limit the storage of LSOs. Flash uses the settings manager to modify the file /Users/<username>/Library/Preferences/Macromedia/Flash Player/macromedia.com/support/flashplayer/sys/settings.sol By flipping the second byte after the "allowThirdPartyLSO" keyword you can manually set the setting. I opted to just generate a good settings.sol that I could overwrite the existing one with, which allows changes in this file to be easily managed by just regenerating a new one. Silverlight is much easier; you can either use the built-in settings manager by right-clicking in any Silverlight app, or create a blank file in /Users/<username>/Library/Application Support/Microsoft/Silverlight/is/<random 8.3>/<random 8.3>/1/disabled.dat . Setting both of these permanently, and more robustly, disabled LSOs for both system.

However, one issue remains. Even with this setting, Flash still creates an entry is directory (2) above, to allow site-specific configurations items to be stored. This setting inherits from the global config, and won't allow custom data to be stored if all 3rd party LSOs are blocked. This setting is stored in /Users/<username>/Library/Preferences/Macromedia/Flash Player/macromedia.com/support/flashplayer/sys/#<domain.name>/settings.sol in the second byte after the "allow" keyword.  This certainly provides some useful info for forensic investigators: any time a user with all Flash local storage settings off and all privacy settings on visits a flash page, an entry will be created in the location above. You can't clear this from within the browser without the help of an extension which deletes the files. Also, less worryingly, Silverlight's file needs to be placed in the unique random directory structure that's created, which means a unique identifier persists. The solution there was just to change the directory name randomly, which Silverlight happily rolls with, and another UID bites the dust.

In short, the article above describes the best way to permanently disable LSO storage in Flash & Silverlight, and what not to try. The end result should be, that the evercookie won't be able to use them as locations. However, neither will legitimate applications. For the most part, this doesn't appear to break anything, as mostly apps store preference data, but there must be a few apps it will break. The solution to that will be detailed with some of the other, more interesting evercookie work at a later stage.