Talk:Local shared object

small changes
I added the 'unreferenced' tag to this article. This article (in my opinion) needs to be vetted for good and proper use of references. There also may be original research/NPOV issues, e.g. "To this day, there is little public awareness of ... LSOs" and the random list of LSO editing programs. Bowmanjj 21:17, 11 April 2007 (UTC)

Suggested fix for Mac OS X and Linux
On OS X, setting ~/Library/Preferences/Macromedia/Flash Player/#SharedObjects as a link to /dev/null appears to work fine. However I noticed that for a couple of websites Flash stopped working, notably theonion.com and grooveshark.com. Curious, I set #SharedObjects back to be a real directory and it worked again. Any ideas on this? Perhaps one should use /tmp or better, some other directory emptied on browser exit. You’ve also got to watch ~/Library/Preferences/Macromedia/FlashPlayer/macromedia.com/support/flashplayer/sys, the @#$%(:>:&@ thing puts them in there too. And why the hell is an external website required to manage a locally installed application? I can only think that it's because Flash plug-in is not a standalone app, but still, this whole idea stinks...

Privacy Concerns
I find it odd that my section gets edited within 1 hour of publication in an area that has not seen much attention. If there are errors in my section I would be glad to redact, but the content is accurate and I have provided the references. For future readers.. my edits are listed below. At least they can be seen in the discussion.

In addition to the marketing uses of cookies and flash (for demographic targeting), LSOs play a key role in an area known as Client Device Identification (CDI). Given that LSOs are leveraged by banks and merchants for validation of identify it is worth describing their use within this section. The term CDI was coined by Avivah Litan of Gartner Group. Within the flash based LSO form of CDI, either the domain or their 3rd party vendor (ex. RSA, Iovation, arcot ...) store LSOs and compare the customer/LSO combination to a known list. The primary reasons that LSOs are selected for this function is that they are not frequently deleted 

In the case of 3rd party vendors, although (technically speaking) the LSO is not read across domains, tracking by the third party is performed across domains. The ability for an LSO to be read across domains poses both a security and privacy risk. The security risk exists if the "writer" of an LSO puts sensitive information within it. The additional privacy risk is that a third party has ability to track website navigation as well as transactions (ex. Purchase, open a card account, top up a gaming account). . A number of vendors claim the ability to calculate a real time "risk score" based upon the previous existence of an LSO/Customer combination.

Vendors providing services to track LSO, Customers and IP Address included
 * Iovation [www.iovation.com]
 * RSA [www.rsa.com] [www.rsa.com/products/consumer/sb/9697_AATF_SB_0808.pdf]
 * Arcot [www.arcot.com]

Others are referenced in the 2009 Gartner report Magic Quadrant for Web Fraud Detection  —Preceding unsigned comment added by Xs4-guy (talk • contribs) 19:46, 27 March 2009 (UTC)


 * I have deleted your three paragraphs again. Tracking users using cookies (either "normal" ones or LSOs) is a common technique so there's no need to write so much about it. Additionally I seriously disagree that using LSOs represents a security risk for the user since only the creator of an LSO can access it again. I'm not sure how technical you are but you don't seem very familiar with the way Flash works. The link you've provided doesn't mention anything about security. Before adding this kind of statements again to the article, please try to establish a consensus in the discussion page first. Thanks. Laurent (talk) 20:40, 27 March 2009 (UTC)


 * re Security risk. Major US bank uses LSO and Cookies to recognize a "familiar" device. Authentication for device is different is LSO is present. LSOs can be copied (ex malware), hence online banking security flaw. See example malware Pinch . If your point is that LSOs cannot be read across domains then that is an accurate statement today. If your point is that LSOs cannot be compromised, and present no privacy risk, then this is not true. It is the bank's use of LSOs, and their dependency on the information within them to make decisions, that make them a privacy risk. You are speaking of the LSO technology, I am speaking of the LSO content and use. --Xs4-guy (talk) 18:00, 2 July 2009 (UTC)


 * Any system or software can potentially be compromised and can represent a security risk, it doesn't just apply to LSOs. Do you have a reliable source that discusses into details the risks (if any) of LSOs? Laurent (talk) 18:05, 2 July 2009 (UTC)


 * Re "reliable source". How about Bruce Schneir. http://www.schneier.com/blog/archives/2009/08/flash_cookies.html hope this is adequate. --Xs4-guy (talk) 21:17, 5 November 2009 (UTC)


 * >Mr. Laurent, quoting: Additionally I seriously disagree that using LSOs represents a security risk for the user . This seem to be POV and OR, and you may want to take a look at Code That Tracks Users’ Browsing Prompts Lawsuits New York Times,  September 20, 2010 - and then reinstate what you deleted You.dont.know.what.you.dont.know (talk) 21:06, 21 September 2010 (UTC)

Viewing and editing LSOs section
I am a little unsure about the "Dojo JavaScript Toolkit" reference/link...  This seems like a multi-purpose javascript tool which just happens to have .SOL editing added in. Also there is no mention of what platforms each tool runs on, or any tools for Linux or Mac. Maybe the "Viewing and editing LSOs" section should describe what a .SOL file looks like, and what (if any) conversion is necessary to edit it, instead of listing tools.  I mean, by the title this really isn't a tools section. --128.227.127.228 (talk) 18:09, 26 November 2007 (UTC)

Added references section
I have added a references section and a number of references. Raffen (talk) 09:10, 5 December 2007 (UTC)

Raffen (talk) 09:10, 5 December 2007 (UTC)

Removed unreferenced tag
I feel the number of citations and references now justify removal of the 'unreferenced' tag. Raffen (talk) 10:05, 5 December 2007 (UTC)

Neutrality of "Hidden Control Panel for Automatic-Opt-In LSO Cookies" section
I don't know how others feel about this, and I may be talking rubbish. But to me, this section seems... slightly more scornful (possibly not the right word, but it's the only way I can describe it) than perhaps it should. I won't change it, as it may just be my imagination, but I think it's worth mentioning and, if necessary, tweaking. Randomoocookies (talk) 11:15, 27 July 2008 (UTC)

Extremely slanted article
This whole article reads with an extreme negative slant towards LSO's. Sure, they can be used for nefarious purposes, but they are just as innocuous, most of the time, as cookies. Pretty much all browsers' default cookie settings are to store them indefinitely without prompting, and Flash follows suit. You can disable LSO's if you want. Anyway, the article needs a heavy rewrite. 99.233.111.84 (talk) 04:26, 1 August 2008 (UTC)

The privacy concerns section should be "slanted". Many merchants and banks select LSOs because they are not normally deleted. This is what makes them unique. Firefox's latest version, as well as chrome default to delete cookies on exit so I don't know what "most" means above. Few people know that the chip ID Intel disabled in the PIII was not disabled for computers sent to China. Privacy and tracking are serious subjects, people outside of the US have their lives at stake, depending on the anonymity of the internet. We need to be able to discuss it. XS4-Guy 20Mar2009 —Preceding unsigned comment added by Xs4-guy (talk • contribs) 17:58, 27 March 2009 (UTC)


 * Ok but if there are security concerns, please provide third party reliable sources for your claims. I'm sorry but I've removed your last additions since there was no sources and the link to Adobe.com was for a security vulnerability that has nothing to do with LSOs, and that have been fixed by Adobe as soon as they found out about it. Also you keep adding to the article that LSO cannot be deleted easily like normal cookies - ok but if that's true please provide a source. Laurent (talk) 18:23, 27 March 2009 (UTC)


 * @Laurent1979, The privacy and security issue for settings on Adobe Flash Player are much more severe than standard privacy and security issues with cookies that track which web sites a user visits. When a user sets a flash player settings to prevent themselves from being literally watched and listened to via their own computers video and audio onboard equipment, and that setting is reset to a default that now enables an entity to remotely see and hear that user's activity without explicitly obtaining permission, that should be against the law. Why it isn't is beyond me. I realize I am extremely late to the game, and this may all be a moot point, but I feel the need to inform you that your edits appear to detract from the countless volunteered hours of time that Many People give up so that the information presented on wikipedia.org is accurate and as truthful as possible. To be blunt, I do not believe you do not understand the difference between data stored for a session and data stored indefinitely and the difference in difficulty to clear the data. Please refrain from removing content that make statements you know to be true because they lack  references and instead request references because when you do so it looks awful incriminating that you are an employee of a proprietary entity and attempting to alter wikipedia content for the purpose of higher sales. A quality company would focusing on how it could provide the customer with a product they value and not one that is deceptive.Dirtclustit (talk) 01:08, 12 April 2013 (UTC)

Wired has an article that supports the negative view on LSOs: The article is also referenced on security expert Bruce Schneier's blog I think this adds credibility to the privacy concerns. Raffen (talk) 18:37, 26 August 2009 (UTC)

I have added reference to Bruce Schneier's article, and to UK privacy law outlining the legal ramifications for companies that place LSOs on a consumer's machine without their consent --Xs4-guy (talk) 21:32, 5 November 2009 (UTC)

Better Privacy [Firefox addon]
Completely deletes LSO's, manages them to your requirements. https://addons.mozilla.org/en-US/firefox/addon/6623 —Preceding unsigned comment added by 119.136.204.86 (talk) 14:46, 26 February 2010 (UTC)

Objection [Firefox addon]
Starting 2007, Greg Yardley and Trevor Hobson have developed Objection as an open-source tool to view and delete LSOs. —Preceding unsigned comment added by 76.227.70.194 (talk) 03:58, 30 September 2010 (UTC)

Changing permissions on the directories in question has been a reasonable solution for me in OS X & Linux
.... along the lines of linking to dev/null. On a Mac this is relatively easy if the user is only familiar with using the GUI and can be done in the Get Info panel for each directory. I've only ever changed permissions on the command line in Linux - I know I've seen the file properties box pop up listing permissions, but not sure about changing them.

As soon as I found them and before I was able to discern what their purpose was, only knowing that seeing domains like bin.clearspring.com, quantcast.com, suitesmart.com, uclick.com, and pagead2.googlesyndication.com meant one thing and one thing only - my web browsing was being tracked - coupled with the fact that I only had become aware of Flash just shortly before this occurred and I thought it was an Adobe plugin (I had no idea about the Macromedia connection) I immediately emptied the contents of what were seemingly the most troublesome directories:

~/Library/Preferences/Macromedia/Flash Player/#SharedObjects/XXXXXXXX      (I had 8 different sub-directories in #SharedObjects )

~/Library/Preferences/Macromedia/Flash Player/macromedia.com

into a disk image to look at later when I figured out what this stuff was.

I had had a similar issue with eSellerate's undisclosed, uninvited, and unwelcome licensing mechanism for a supposedly free product that would regenerate on re-boot after everytime I tried to delete it, and solved it by emptying its directory and changing the permissions. So I figured I'd just do the same here and simply changed the permissions on the now empty #SharedObjects directory and the macromedia.com directory to read only for Owner, Group, and Other.

Since then, that was a handful of years ago, the restricted permissions have never posed an issue - meaning I've never received any errors from any Flash being executed nor have I seen an adverse effect - with three exceptions:
 * 1) As part of user authentication, one of my banks first looks for a persistent browser cookie, and if there is none, the fall back is the LSO. If there is also no LSO, a vague "we don't recognize your new computer" error is thrown and then the user has to enter an authorization code sent to their choice of the email address on file or as a text message to a mobile phone.
 * 2) PayPal apparently relies on LSOs in some circumstances as part of the user authentication process because I had my account frozen for three months when I initiated a FIVE DOLLAR! transaction from a computer other than the one that contained the LSO. PayPal's vague response was that my log in process deviated from the norm I had established so the FIVE dollar transaction was suspect.
 * 3) Another one of my banks, while apparently not requiring a cookie or LSO to complete authentication for sign on, will take close to 2 full minutes, on a 1mbps up/5mbps down DSL connection, the progress bar inching along, the screen spitting out revolving messages about ensuring my identity, etc. If there is an LSO present, it takes less than 10 seconds.

But I only really use it to watch video. I don't play games. I don't cam with it.

I did a very non-scientific experiment a year ago and recently repeated it for part of a project I am working on. I set up a fresh, default Macromedia directory in the OS X Preferences directory and decided to test their silly lil cartoon of a privacy panel. For the purpose of testing, we used the panel to tell Flash Player to disallow third party access always, to always ask for microphone & cam permission, and we left the LSO size default at whatever it was at the time, 100kb for sites and to never ask again. We fired up MTV.com to watch "The Hills" and it wasn't but 30 seconds into the show before it started to sputter. Not only did it ask permission for more space, it had in fact already stored 120kb, running over the limit. And the video refused to budge - it just kept spitting out that same message. So we upped it to 140kb... sputtered again, asking for more space!!! And then we went to look in the directory, and there were LSOs from MTV's content distributors, 3rd party LSOs. Woah, something was broken because our settings remained unchanged according to the panel - it still displayed our choice to deny third party, as well as our 100kb limit and never ask again choice.

We didn't make any further adjustments on the panel. We went into the #SharedObjects and macromedia.com directories, deletex everything, changed permissions to read only, started up the exact same episode of "The Hills," and playback was flawless. No errors, no sputtering, no nothing.

It's encouraging to know something has changed at least because I recently replicated the experiment and everything behaved exactly as the settings describe and one would expect. It stuck to the 100kb file limit, it didn't ask for more space, and there was no 3rd party content. Improvement but not ideal.

When I reported my findings in an Adobe customer support forum - the forums where employees rarely post, its mostly other customers helping each other - an Adobe Product Manager bounced right onto the scene to defend the privacy panel and to lament how browser makers don't make the API available to Adobe to develop in browser controls (HELLO, FX IS OPEN SOURCE!).

My Dog Is Bart (talk) 07:44, 16 June 2010 (UTC)

File Format
Is there any information on the LSO file format that could be posted here? In particular, it seems that there are at least two different LSO file formats in use (an "old" and a "new" version, which seems to be related to ActionScript 2.0 vs ActionScript 3.0) -- it becomes especially relevant to the list of application support because many applications on the list can only open some .sol files and not others. Abeall (talk) 22:54, 7 August 2010 (UTC)

File format is not so complex... just re it like the authors of each program. —Preceding unsigned comment added by 78.147.40.215 (talk) 13:22, 26 September 2010 (UTC)
 * Huh? Abeall (talk) 02:07, 26 October 2010 (UTC)

File location MS Windows.
Does anyone have a feel for why there are 2 MS windows NT location sections. The data is exactly the same. — Preceding unsigned comment added by 67.248.181.72 (talk) 01:49, 27 August 2011 (UTC)

Requested move

 * The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section. 

The result of the move request was: Moved to Local shared object Mike Cline (talk) 16:08, 24 December 2011 (UTC)

Local Shared Object → Local shared object –

Per WP:MOSCAPS ("Wikipedia avoids unnecessary capitalization") and WP:TITLE, this is a generic, common term, not a propriety or commercial term, so the article title should be downcased. In addition, WP:MOSCAPS says that a compound item should not be upper-cased just because it is abbreviated with caps. Lowercase will match the formatting of related article titles. Tony  (talk)  14:03, 17 December 2011 (UTC)


 * Support, this is a generic technical name, it's not set by any institution and not trademarked. --Enric Naval (talk) 16:27, 23 December 2011 (UTC)


 * The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Editors and toolkits section needs introduction
The section "Editors and toolkits" is just a table. It would be helpful to have at least a sentence explaining what the table is. For instance "The following table lists software with capabilities for editing, managing, or blocking local shared objects." Preferably a slightly more detailed sentence. I don't want to write it because I'm not expert in this area, so I don't have a good idea of the range of software included in the list, and how complete the list is. These are issues I think should be (briefly) addressed, though. MorphismOfDoom (talk) 15:29, 5 December 2012 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on Local shared object. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20090323020859/http://news.prnewswire.com/ViewContent.aspx?ACCT=109&STORY=%2Fwww%2Fstory%2F03-19-2009%2F0004991142&EDATE= to http://news.prnewswire.com/ViewContent.aspx?ACCT=109&STORY=%2Fwww%2Fstory%2F03-19-2009%2F0004991142&EDATE=

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 02:38, 25 May 2017 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 3 external links on Local shared object. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20100529082335/http://www.adobe.com/products/flashplayer/articles/lso/ to https://www.adobe.com/products/flashplayer/articles/lso/
 * Added archive https://web.archive.org/web/20110224183417/http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications/the_guide/cookies.aspx to http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications/the_guide/cookies.aspx
 * Added archive https://web.archive.org/web/20071221091949/http://www.maxa-host.net/ to http://www.maxa-host.net/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 23:01, 4 January 2018 (UTC)

Wikipedia is not a manual
Since it's just been expanded again, it seems worth pointing out that Wikipedia is not an instruction manual, and absolutely none of this horrifically-formatted faff is even remotely encyclopedic or relevant. 

File locations
The default storage location for local shared objects is operating system-dependent, and depends on the flash plugin being NPAPI or PPAPI.

NPAPI, ActiveX and standalone projector
On Microsoft Windows NT 5.x and 6.x, they are stored in:
 * %APPDATA%\Macromedia\Flash Player\#SharedObjects\
 * %APPDATA%\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys\

On Mac OS X, they are stored in:
 * ~/Library/Preferences/Macromedia/Flash Player/#SharedObjects/
 * ~/Library/Preferences/Macromedia/Flash Player/macromedia.com/support/flashplayer/sys/

On Linux or Unix, they are stored in:
 * ~/.macromedia/Flash_Player/#SharedObjects/
 * ~/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/

For Linux and Unix systems, if the open-source Gnash plugin is being used instead of the official Adobe Flash, they will instead be found at:
 * ~/.gnash/SharedObjects/

PPAPI
When using Google Chrome the location for the Pepper Flash (PPAPI) storage is:
 * Windows: %localappdata%\Google\Chrome\User Data\Default\Pepper Data\Shockwave Flash\WritableRoot\#SharedObjects
 * Mac OS X: ~/Library/Application Support/Google/Chrome/Default/Pepper Data/Shockwave Flash/WritableRoot/#SharedObjects/
 * Linux: ~/.config/google-chrome/Default/Pepper Data/Shockwave Flash/WritableRoot/#SharedObjects/

In Microsoft Edge with Chromium, the location for the Pepper Flash (PPAPI) storage is: Unless someone objects I'm just going to circular-file the entire section. -- FeRDNYC (talk) 03:26, 2 September 2020 (UTC)
 * Windows: %localappdata%\Microsoft\Edge\User Data\Default\Pepper Data\Shockwave Flash\WritableRoot\#SharedObjects
 * Mac OS X: ~/Library/Application Support/Microsoft/Edge/Default/Pepper Data/Shockwave Flash/WritableRoot/#SharedObjects/
 * Hearing no objections after 11 days, I shall be bold and can the entire section. It exists both here and in the article history, should anyone wish to retrieve it for some reason. -- FeRDNYC (talk) 00:06, 14 September 2020 (UTC)

Update needed?
Support of Adobe Flash ended, see Adobe Flash Player EOL General Information Page. Does it mean LSO are no more used? Could they still be a security issue? Tnx,--Riha (talk) 07:11, 17 December 2021 (UTC)