Wampum

The one thing missing both from the original article and from your post is where those files reside and how to delete them. From this site, we have:

Like cookies, shared objects are used to maintain data persistence. The object data is stored in an .sol file on the user's hard drive in the same directory as the Flash MX player. The files are stored in folders corresponding to the domain that generated the Flash movie.

Personally, I removed Macromedia Flash from my system a long time ago. Occasionally I need to install it to view a site that I need, but that's pretty rare and it's easy to uninstall again immediately afterward.

First, I can't claim even to know how to spell Flash. I've never built or installed a someone-else-built Flash module to Mozilla.

Second, Yngve, the senior developer for Opera asked yesterday "Any suggestions about how a client can control this situation?" The vendor has a story, which you can read here: http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html#117498

However, keep in mind that Macromedia has chosen not to go to the P3P Spec Comm (me et alia) and discuss putting privacy labels on .so writer and reader methods, so ... draw, or paint your own conclusions about where they are on privacy.

Eric, thanks for that one link about global and domain storage settings. There's also a technote which brings together the set of information onto one page:
http://www.macromedia.com/go/52697ee8

"Since about 40% of the best demographic flush their cookies regularly..." For what it's worth, I'm still skeptical of this original claim... in a followup, Jupiter noted how they asked people about their cookie behavior, rather than actually testing people about their current cookie status. I haven't seen the survey questions yet, but it's still a bit hard for me to believe that 40% of those on the web could tell you what a cookie is, much less say they delete it weekly...?

(Paul, I believe the quote you read was from an old document... domain data was indeed stored in domain-named directories at one point, but this provided a predictable path for such storage, and so was hashed about two years ago.)

Regards,
John Dowdell
Macromedia Support

John,

Since you're here on a Saturday morning ... I put early P3P data collection aka "privacy" metadata DTDizd gorp on customer profiles in (pre-XML schema) CPEX, and schematized P3P gorp on the cookie method in P3P (our original proposal was much closer to wicked compact EBNF), and schematized P3P-lite gorp in the XML-based EPP protocol which eventually gets ignored and everyone's telephone number and Mother's Maiden name dumped on the public WHOIS servers (but that's an ICANN policy problem).

So, since as a design choice, someone a MM signed off on stuffing state into the client's persistent store. Why not label the write, read, and re-read methods and the associated data? Presumably the value proposition for Flash isn't CPM based revenues, and MM has useful reasons to maintain state -- I've no idea what these could be, but my imagination always runs towards performance implications of link layer characteristics when ever I see thin wires and fat unidirectional flows.

Becoming a CPM superhighway seems about as smart as selling spyware.

Gratuitous suggestion -- kludge up a label-space and let the IE and MZ developers know that MM wants SOs to be policied. From experience (you don't want to know) they're a fairly tolerant lot and you'll have this buried in one release cycle.

Oh. I'm wicked impressed that you found my post in about 36 hours.

whoops, looks like I got lost after the "CPEX" acronym.... ;-)

I'll forward this URL among my colleagues this week, though. Another path towards requesting a codechange is the "Flash Player Team" address at the feature-request form:
http://www.macromedia.com/go/wish

jd/mm

I suppose I could post a tutorial...

CPEX is a bunch of large and complex retailers, like IBM, attempting to come up with a mechanism to move customer profiles around -- with divisions of some company, between companies, and so on. I put a pre-P3P metadata blob on the XML, and added record-route, so that the policy at each "stop" of a customer profile could be identified, so we could figure out where hypothetical leakage occured, or some other covert channel(s).

P3P on cookies means a large (in bytes) amount of overhead blob on a relatively small file (compared to the original model of baroque XML description of a URL. Both have to be evaluated by the browser or some agent. Optimizing for the in-browser evaluation of cookie metadata, and also the overhead of many cookies associated with a single URL for narrow-band users (narrow-band is not your problem, obviously) leads to much simpler syntactical representations than XML. A compromise with the XML purists was a reduced vocabulary for the poliby blob on cookies -- your que to do something policy-enabling and cluefull.

EPP is a protocol for provisioning .com-like registries, the syntax is (again) XML, and because not everyone wants to share their shoe size and email address with WHOIS data mining robots, I put a data collection policy glob on sessions.

NB. I don't use Flash, and I can't see myself requesting a feature.