Hubbry Logo
Local shared objectLocal shared objectMain
Open search
Local shared object
Community hub
Local shared object
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Local shared object
Local shared object
Local shared object
View on Wikipedia
from Wikipedia

A local shared object (LSO), commonly called a Flash cookie (due to its similarity with an HTTP cookie), is a piece of data that websites that use Adobe Flash may store on a user's computer. Local shared objects have been used by all versions of Flash Player (developed by Macromedia, which was later acquired by Adobe Systems) since version 6.[1]

Flash cookies, which can be stored or retrieved whenever a user accesses a page containing a Flash application, are a form of local storage. Similar to cookies, they can be used to store user preferences, save data from Flash games, or track users' Internet activity.[2] LSOs have been criticised as a breach of browser security, but there are now browser settings and addons to limit the duration of their storage.

Storage

[edit]

Local shared objects contain data stored by individual websites. Data is stored in the Action Message Format. With the default settings, the Flash Player does not seek the user's permission to store local shared objects on the hard disk. By default, an SWF application running in Flash Player from version 9 to 11 (as of Sept 1, 2011) may store up to 100 kB of data to the user's hard drive. If the application attempts to store more, a dialog asks the user whether to allow or deny the request.[3]

Adobe Flash Player does not allow third-party local shared objects to be shared across domains. For example, a local shared object from "www.example.com" cannot be read by the domain "www.example.net".[1] However, the first-party website can always pass data to a third-party via some settings found in the dedicated XML file and passing the data in the request to the third party. Also, third-party LSOs are allowed to store data by default.[4][5] By default, LSO data is shared across browsers on the same machine. As an example:

  • A visitor accesses a site using their Firefox browser, then views a page displaying a specific product, then closes the Firefox browser, the information about that product can be stored in the LSO.
  • If that same visitor, using the same machine now opens an Internet Explorer browser and visits any page from the site viewed in Firefox, the site can read the LSO value(s) in the Internet Explorer browser, and display dynamic content or otherwise target the visitor.

This is distinct from cookies which have directory isolated storage paths for saved cookies while LSOs use a common directory path for all browsers on a single machine.

Application to games

[edit]

Flash games may use LSO files to store the user's personal game data, such as user preferences and actual game progress. Backing up files such as these requires some technical understanding of software. However, both browser updates and programs designed to remove unused files may delete this data.

To prevent cheating, games may be designed to render LSO files unusable if acquired from another location.

Privacy concerns

[edit]

As with HTTP cookies, local shared objects can be used by websites to collect information on how people navigate them, although users have taken steps to restrict data collection.[6] Online banks, merchants, or advertisers may use local shared objects for tracking purposes.[7]

On 10 August 2009, Wired magazine reported that more than half of the top websites used local shared objects to track users and store information about them, but only four of them mentioned it in their privacy policy. "Flash cookies are relatively unknown to web users," the article said, "even if a user thinks they have cleared their computer of tracking objects, they most likely have not." The article further says that some websites use Flash cookies as hidden backups so that they can restore HTTP cookies deleted by users.[8]

According to the New York Times, by July 2010 there had been at least five class-action lawsuits in the United States against media companies for using local shared objects.[9]

In certain countries, it is illegal to track users without their knowledge and consent. For example, in the United Kingdom, customers must consent to the use of cookies/local shared objects:[10][11]

Cookies or similar devices must not be used unless the subscriber or user of the relevant terminal equipment:

  • is provided with clear and comprehensive information about the purposes of the storage of, or access to, that information; and
  • is given the opportunity to refuse the storage of, or access to, that information.

— Information Commissioner's Office

Local shared objects were the first subject to be discussed in the Federal Trade Commission (FTC) roundtable in January 2010.[12] FTC Chairman Jon Leibowitz has been talking with Adobe about what it describes as "the Flash problem." [13]

User control

[edit]

Users can disable local shared objects using the Global Storage Settings panel of the online Settings Manager at Adobe's website.[14] However, this places a permanent flash cookie on the computer, informing all other websites that the user does not want flash cookies stored on their computer. Users can opt out of LSOs from specified sites from Flash Player's "Settings", accessed by right-clicking the Player, or using the Website Storage Settings panel; the latter also allows users to delete local shared objects.[15]

Users may also delete local shared objects either manually or using third-party software. For instance, CCleaner, a standalone computer program for Microsoft Windows and Mac OS X, allows users to delete local shared objects on demand. There is also a Firefox add-on, Clear Flash Cookies, which will automatically clear out all LSOs each time the browser is restarted.[16]

Since version 10.3 of Flash, the Online Settings Manager (letting users configure privacy and security permissions via Adobe's website) is superseded by the Local Settings Manager on Windows, Mac, and Linux platforms. It can be accessed via the Windows Control Panel or Mac OS System Preferences.[17] Users of other operating systems still use the Adobe Online Settings Manager. Since at least April 2012 (v 11.2.202.233), updating by downloading a new Flash version resets the security and privacy settings to the defaults of allowing local storage and asking for media access again, which may be against users' wishes.

Browser control

[edit]

Browser control refers to the web browser's ability to delete local shared objects and to prevent the creation of persistent local shared objects when privacy mode is enabled. As for the former, Internet Explorer 8, released on March 19, 2009,[18] implements an API that allows browser extensions to co-operate with the browser and delete their persistent data stored when user issues a Delete Browsing History command.[19] However, two years passed since its introduction until Adobe, on March 7, 2011, announced that Flash Player v10.3, which was still in development at the time, supports co-operating with Internet Explorer 8 or later to delete local shared objects.[20]

Also on January 5, 2011, Adobe Systems, Google Inc., and Mozilla Foundation finalized a new browser API (dubbed NPAPI ClearSiteData). This will allow browsers implementing the API to clear local shared objects.[21] Four months later, Adobe announced that Flash Player 10.3 enables Mozilla Firefox 4 and "future releases of Apple Safari and Google Chrome" to delete local shared objects,[20] so since version 4, Firefox treats LSOs the same way as HTTP cookies - deletion rules that previously applied only to HTTP cookies now also apply to LSOs.[22][23] This caused loss of data and backward-incompatible flash application behavior[24] for those Firefox and Flash users who used HTTP cookies and Flash local shared objects for different goals. Mainly this affected flash gamers, who rely on Flash LSOs to store saved games.[25][26] The resulting support requests cannot be solved favorably for Mozilla Firefox users without changes to the browser, because of the introduced equivalence between HTTP and flash cookies.[22][23] Currently, the workaround in use is to either configure the browser to never clear history data and cookies or to revert the part of the changes affecting this use case, using third-party patches.[27]

As for the behavior in browser's privacy mode, Adobe Flash Player 10.1, released on June 10, 2010, supports the privacy modes of Internet Explorer, Mozilla Firefox, Google Chrome, and Safari. Local shared objects created in privacy are discarded at the end of the session. Those created in a regular session are also not accessible in privacy mode.[28][29]

Third-party software

[edit]

Viewers and editors

[edit]
Software Developer Platform Abilities First public release Latest stable version License
Read Write Format
.minerva (GitHub) Gabriel Mariani Web platform Yes Yes AMF0/AMF3, JSON ~2008-07-15 (1.5.1) 4.3.5 (2025-09-19) BSD
.sol Editor Alexis Isaac Windows Yes Yes AMF0 Feb. 2005 1.1.0.1 (2005-02-21) MPL
SOLReader Alessandro Crugnola Windows Yes No AMF0/AMF3 2007-10-25 1.0.0 (2007-10-25) ?
FlashDevelop Mika Palmu, Philippe Elsass Windows Yes No AMF0/AMF3 2009-06-14 (3.0.0) 4.4.0 (2013-04-18) MIT
SolVE Darron Schall Windows, macOS Yes Yes AMF0 Nov. 2004 0.2 (2004-10-15) CPL

Libraries and frameworks

[edit]
Software Developer Abilities First public release Latest stable version License
Read Write Format
Dojo Toolkit Dojo Foundation No Yes AMF0/AMF3 (in browser via Flash) 2004 1.9.0 (2013-05-01) BSD, AFL
PyAMF (GitHub/PyPI) Nick Joyce Yes Yes AMF0/AMF3 2007-10-07 0.8.0 (2015-12-17) MIT
s2x Open Source Flash Aral Balkan Yes Yes AMF0, XML Dec. 2003 0.75 (Dec. 2003) Freeware

Cleaners

[edit]
Software Developer Platform First public release Latest stable version License
PrivacyScan SecureMac.com, Inc. macOS 10.6 - 10.10 2012-01-30 1.5 Shareware
Cookie Stumbler WriteIt! Studios Ltd. macOS 10.8 - 10.9 2011-04-01 2.1.2 Shareware
Cookie SweetP Productions macOS 10.6 - 10.10 2011 4.3.2 Shareware
Safari Cookies SweetP Productions macOS 10.5 - 10.10 2009-04-12 2.0 (2014-10-27) Freeware
MAXA Cookie Manager Maxa Research Windows ? 5.3 (2011-12-11) Shareware
Click&Clean Vlad & Serge Strukoff Windows, macOS, Linux, BSD, Firefox add-on 2010-01-23 (3.6.5.0) 4.1 (2013-03-16) MIT
CCleaner Piriform (company) Windows ? ? Freemium

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Local shared object

View on Grokipedia
from Grokipedia
A local shared object (LSO), commonly referred to as a , is a file generated by to enable persistent local retention of information on a user's device, allowing Flash-based applications to maintain state across browser sessions and device restarts. Unlike HTTP cookies, which are typically restricted to 4 KB of per domain, LSOs support up to 100 KB of structured data—such as objects, arrays, and binary elements—without requiring explicit user approval for initial creation, though larger sizes prompt for permission. Stored in the Flash Player cache directory (e.g., under user profiles on Windows or application support folders on macOS), LSOs are organized by domain and can be accessed or modified via code embedded in files. LSOs facilitated legitimate uses like saving user preferences in applications, storing offline progress, or caching form data to enhance interactivity on websites reliant on Flash content. However, their design enabled cross-domain tracking by advertisers, as they evaded standard browser cookie deletion mechanisms and could synchronize data with HTTP to "resurrect" cleared tracking identifiers—a technique documented in analyses of major networks. This persistence, combined with limited visibility in browser privacy tools, amplified concerns over unauthorized , prompting users to manage them separately via Adobe's settings panel or third-party cleaners. The obsolescence of LSOs accelerated after Adobe ended Flash Player support on December 31, 2020, rendering new creation impossible without legacy plugins, though residual files may linger on systems with prior installations. Their legacy underscores early practices that prioritized functionality over granular consent, influencing modern standards like IndexedDB and stricter regulations.

History

Introduction and development

Local shared objects (LSOs), a feature of developed by , originated as a client-side storage mechanism to enable persistent for interactive web content. Introduced in Flash Player 6, released on March 15, 2002, LSOs allowed Flash applications to write and read small amounts of data—up to 100 KB by default—to users' local file systems, overcoming the constraints of HTTP cookies, which were limited in capacity and primarily server-managed. The primary purpose was to support Flash's vector-based animations and multimedia experiences by storing user preferences or session data locally, eliminating the need for repeated server round-trips that could degrade performance in bandwidth-limited early-2000s environments. Through the SharedObject class, developers could create, access, and synchronize data objects, initially designed for scenarios where real-time updates between multiple files were required without external dependencies. Early implementations demonstrated LSOs' value in multimedia sites, where they stored settings such as audio volume levels or simple user progress in interactive content, persisting across browser sessions to enhance continuity and reduce load times. For instance, Flash MX-era applications leveraged LSOs to maintain state in embedded games or customizable interfaces, marking a shift toward more autonomous client-side functionality in .

Evolution within Adobe Flash

Local shared objects (LSOs) were first implemented in Flash Player 6, released in March 2002, via the SharedObject class in , enabling persistent client-side data storage in a binary AMF format that exceeded the 4KB limit and string-only constraints of HTTP . Following Adobe's acquisition of , completed on December 3, 2005, the SharedObject API persisted and integrated more deeply into Adobe's ecosystem, including 3.0 introduced with Flash Player 9 in June 2006, which refined object-oriented handling for LSO data properties supporting nested arrays, custom objects, and serialized binary content. A key expansion under involved enhanced support for remote shared objects, leveraging Flash Media Server (formerly Flash Communication Server) for bidirectional server-client synchronization, allowing real-time updates across multiple Flash applications without relying solely on local persistence. This complemented local LSOs by enabling causal data propagation in multi-user scenarios, driven by developer needs for scalable, stateful web experiences. Methods like setProperty() and onSync() events facilitated efficient and in distributed environments. By the mid-2000s, these capabilities fueled widespread adoption in rich internet applications (RIAs), where LSOs handled user sessions, preferences, and dynamic content far beyond limitations, peaking through the until alternatives emerged. Adobe's documentation emphasized LSOs' 100KB default size quota per domain—expandable via user prompts—as a deliberate balance for functionality versus storage intrusion, reflecting iterative refinements to meet developer demands for robust, cross-SWF .

Deprecation following Flash end-of-life

Adobe announced on July 25, 2017, that it would end support for Flash Player by December 31, 2020, accelerating the deprecation timeline due to persistent vulnerabilities—such as frequent exploits targeting the plugin—and the maturation of standards as viable alternatives for interactive . This decision rendered local shared objects (LSOs), which depend entirely on the Flash runtime for creation, modification, and access, functionally obsolete in web contexts, as no new Flash-based applications could reliably generate or interact with them post-support. Following the end-of-support date, implemented a content blockade on January 12, 2021, preventing Flash Player from executing any content, even in standalone installations, to mitigate unpatched security risks. Concurrently, major browsers enforced deprecation: removed Flash support in version 76 (July 2019) with progressive blocking leading to full disablement by 2021; Mozilla Firefox followed in version 85 (January 26, 2021); and aligned with Chromium's timeline, disabling Flash by default in early 2021 updates. These measures collectively halted Flash execution in browsers, eliminating the mechanism for LSO operations and confining any residual files to static storage without runtime integration. The causal irrelevance of LSOs stems directly from this enforcement, as their binary storage format and API access were proprietary to Flash Player, with no or migration paths provided by . Existing LSO files persist in operating system directories (e.g., under user application data folders on Windows or equivalents) but lack programmatic access, rendering them inert relics deletable only via manual tools, without automated removal by browsers or post-EOL. This outcome underscores the tight coupling of LSO functionality to Flash's lifecycle, leaving no supported pathway for their use in modern web environments.

Technical details

Storage mechanism and file format

Local shared objects are stored as binary files with a .sol extension in the Adobe Flash Player's application data directory, which varies by operating system but follows a structured hierarchy for isolation. On Windows, the base path is %APPDATA%\Macromedia\Flash Player\#SharedObjects\, containing subdirectories prefixed with hash values—typically digests—of the SWF file's URL or domain, followed by folders replicating the domain path, and individual .sol files named according to the SharedObject instance (e.g., settings.sol). This hashing and domain-based segregation enforces per-origin scoping, preventing access to data from unrelated sites as enforced by Flash Player's model. The internal format of .sol files employs Adobe's (AMF), a binary scheme designed for compact representation of data structures. AMF supports of primitive types such as integers, doubles, booleans, and strings, alongside composite structures including anonymous objects (key-value maps), arrays (dense or associative), XML documents, dates, byte arrays, and object references to avoid redundancy. Primarily using AMF3 for its trait-based object definitions and integer encoding optimizations, the format enables efficient persistence of nested, while maintaining compatibility with AMF0 for legacy applications. Flash Player's storage of LSOs in its own app-data location, separate from browser or cache directories, renders them resilient to standard browser privacy actions like cache clearing or cookie deletion, which target web-specific storages but overlook plugin-managed files. This design choice ensures continuity across browser restarts or profile switches but requires explicit intervention via Flash Player's settings panel or manual file removal to purge data.

Data capacity and persistence features

Local shared objects (LSOs) in Adobe Flash Player have a default storage capacity of 100 kilobytes (KB) per object for a given domain, significantly exceeding the typical 4 KB limit imposed on HTTP cookies by most browsers. This limit applies initially without user intervention, but developers can request additional space through the flush(minDiskSpace) method, prompting the user for approval if the required size exceeds the default quota; there is no absolute upper bound enforced by the player, provided user consent is obtained. LSOs exhibit high persistence, remaining intact across browser restarts, cache clearances, and even temporary file deletions that affect standard browser-stored , as they are saved in a dedicated Flash Player directory outside the browser's cache (typically under %APPDATA%/Macromedia/Flash Player/#SharedObjects on Windows). Unlike session cookies, LSOs do not expire automatically upon browser closure unless developers implement custom expiration logic, such as embedding timestamps and checking them on access to simulate time-bound storage. To ensure data durability, the flush() method must be invoked explicitly by the application to commit changes to disk, returning a status like SharedObjectFlushStatus.FLUSHED on success or PENDING if additional user approval for space is required; failure due to quota denial or disabled storage triggers exceptions or boolean false, necessitating error handling in code to retry or inform the user. This mechanism allows immediate writes but respects user-configured limits in the Flash Player settings panel.

Access and sharing between applications

Local shared objects (LSOs) enable among multiple Shockwave Flash (SWF) files originating from the same domain through the SharedObject.getLocal() method, which retrieves a reference to a persistent object identified by a unique name and optional local path parameter. When SWFs from the identical domain invoke this method with the same name, they access and modify the shared data object in real time, facilitating coordinated persistence without server intervention. This mechanism partitions data strictly by domain, ensuring that only SWFs served from the originating domain can read or write to the LSO, thereby enforcing sandboxed access. Cross-domain access to LSOs lacks native support, as Flash Player restricts local object retrieval to the serving domain unless explicitly permitted via a cross-domain policy file such as crossdomain.xml. Such policies, when configured on the target domain, grant Flash content from external domains limited permissions to load resources or scripts, but LSO storage remains inherently bound to the domain of the accessing , mitigating unauthorized inter-domain data leakage. Absent a valid policy, attempts to share LSOs across domains fail, enhancing by default. For scenarios requiring synchronization beyond local domains, remote shared objects (RSOs) utilize SharedObject.getRemote() in conjunction with a NetConnection to a Flash Media Server or compatible backend, enabling server-mediated real-time updates among connected clients. The server propagates changes via event-based mechanisms, such as onSync, allowing multiple SWFs—potentially from varied client locations—to maintain consistent states without direct exchange. This approach supports dynamic akin to multiplayer coordination, though it depends on persistent server connectivity.

Applications and use cases

General web and multimedia storage

Local shared objects (LSOs) were commonly employed in web applications to store user preferences, such as interface customizations or playback options, enabling persistent recall without server dependencies. For instance, in Flash-embedded video interfaces, LSOs retained settings like volume levels or resolution preferences across sessions, reducing load times and improving continuity for users revisiting content. This local persistence supported smoother interactions in dynamic web environments where Flash handled rendering and controls prior to the widespread adoption of alternatives. In multi-step web processes, such as product configurators or setup wizards, LSOs held temporary intermediate , like selected options or form states, safeguarding against loss from browser refreshes or interruptions while the process remained client-side. Developers leveraged the SharedObject.getLocal() method to instantiate these objects, writing via and persisting it with flush(), which ensured availability until explicitly cleared or storage limits enforced by Flash Player settings were reached. Flash-based advertisements utilized LSOs for maintaining metrics, such as impression counts or session-specific , across dispersed visits to the same domain, bypassing some browser restrictions on size and scope. This allowed advertisers to aggregate interaction histories locally, with capacities supporting structured beyond standard HTTP ' typical 4 KB limit, often extending to 100 KB per object. Integration with via the ExternalInterface API enabled hybrid workflows, where web scripts invoked Flash methods to read or write LSO data, effectively augmenting browser for scenarios requiring larger payloads or enhanced persistence in cross-application contexts. Such bridging, introduced in Flash Player 8 around 2005, facilitated seamless data exchange, as demonstrated in libraries that exposed LSO functionality through calls for domain-shared storage needs. This approach was particularly useful in legacy web architectures blending and Flash for robust client-side state management.

Specific applications in games and interactive content

In browser-based Flash games, local shared objects (LSOs) facilitated the local persistence of game states, such as player progress, high scores, and inventory items, allowing data to survive browser restarts and sessions without server dependency. Developers accessed LSOs via the ActionScript SharedObject.getLocal() method, storing serialized objects like score integers or array-based inventories, then invoking the flush() method to write up to 100 KB of data to disk. This mechanism was demonstrated in ActionScript 3 tutorials for saving current scores during gameplay events, ensuring retrieval on reload for titles lacking account systems. LSOs proved essential in casual single-player Flash games prevalent from the mid-2000s to early , including puzzle and arcade titles on portals like and , where local saves prevented progress loss amid frequent browser closures or cache clears. High scores, often stored as sorted arrays within LSOs, enabled leaderboards displayed locally, with updates triggered by surpassing thresholds—e.g., appending new entries and resorting before flushing. persistence similarly allowed retention of collected items or unlocked levels, as seen in platformers or RPG-lite games using LSOs to serialize object states like item counts or achievement flags. For interactive content emphasizing replayability, LSOs retained user customizations such as control schemes or visual skins across sessions, loading preferences like remapped keys or color themes to streamline re-engagement without reconfiguration. This local retention supported offline prototyping in game development workflows, where Flash IDE exports tested persistent states mirroring web deployment. In multiplayer Flash games, LSOs occasionally cached transient client-side states, like recent match histories or temporary sync offsets, to mitigate latency during reconnection, though primary relied on remote shared objects for inter-client data exchange.

Advantages

Enhanced user experience and functionality

Local shared objects (LSOs) in provided persistence that allowed applications to instantly retrieve user-specific data, such as preferences or session states, thereby accelerating interactions and minimizing repetitive inputs like re-entering form details or usernames. For example, multimedia or interactive content could resume playback positions or customized views without delay, as the data was loaded directly from local storage rather than requiring network fetches. This local immediacy reduced latency in user flows, enabling smoother continuity across browser sessions. The offline accessibility of LSOs further enhanced functionality for Flash applications, permitting data retrieval and basic operations in disconnected environments, such as aggregating or viewing previously stored content like blog feeds without server dependency. In scenarios with limited connectivity, users could maintain progress or settings in games and tools, avoiding complete resets upon reconnection. By storing customizations locally, LSOs granted users direct control over —such as site appearances or admin statuses—independent of remote servers, fostering tailored experiences without constraints or hurdles. This approach supported user-driven adaptations, like maintaining lists of preferences or states, enhancing autonomy in dynamic web interactions.

Developer efficiencies and reduced server load

The SharedObject in provided developers with a streamlined interface for local , requiring minimal code compared to alternatives like repeated server requests via URLLoader or XMLSocket. To store , developers invoked SharedObject.getLocal("appData") to retrieve or instantiate an object, assigned values to its data property (e.g., so.data.userPreferences = {theme: "dark"}), and called so.flush() to write changes to disk, typically handling up to 100 KB per object by default. This approach eliminated the need for custom , error handling for network failures, and logic inherent in server-polling implementations, which often involved timers for periodic send() or load() calls to backend services. By offloading non-critical —such as user settings, game progress, or temporary caches—to the client-side .sol files, SharedObject reduced server-side request volumes, as applications avoided fetching the same data on each session or interaction. documentation explicitly notes that "storing this information on the user's computer reduces server load," enabling without round-trip latency or bandwidth consumption for routine reads. In the pre- era, when Flash dominated rich internet applications (circa 2000–2010), this translated to measurable infrastructure savings; for instance, multiplayer games or media players could sync only deltas via Flash while relying on local objects for state, cutting polling overhead that might otherwise demand constant HTTP or RTMP connections. The API's abstraction ensured cross-platform consistency, with data handled uniformly across Windows, macOS, and via the Flash Player runtime, simplifying deployment without OS-specific file I/O code. Developers benefited from built-in features like automatic on flush() failures and size limits enforcement, reducing time versus manual disk operations or database queries. Overall, these efficiencies lowered development cycles for data-intensive Flash projects, as evidenced by widespread adoption in applications like Adobe's own tools, where local storage supplanted server-dependent alternatives for scalability.

Criticisms and concerns

Privacy tracking risks

Local shared objects (LSOs), also known as Flash cookies, facilitate persistent user tracking by storing up to 100 kilobytes of data per object—significantly more than the typical 4 kilobyte limit of standard HTTP —enabling detailed profiling of browsing habits across sessions. Unlike browser cookies, LSOs reside in a separate storage directory outside the browser's control, rendering them immune to routine cookie deletion or blocking tools, which allows websites to maintain unique identifiers for users even after measures are applied. This separation permits "respawning," a technique where Flash-based LSOs detect and recreate deleted browser cookies, effectively circumventing user attempts to anonymize their activity. Empirical studies from 2009 revealed widespread deployment of LSOs for purposes, with 54 of the top 100 websites setting them to track users via unique IDs, often without disclosure. For instance, employed LSOs in conjunction with third-party services like KISSmetrics to target ads and monitor viewership, respawning browser cookies to persist tracking data despite deletions, as documented in analyses of their implementation. Similarly, a 2010 class-action lawsuit targeted , , , and others for using Quantcast's LSOs to reinstate tracking cookies, alleging violations of user expectations by evading standard browser controls. Although LSOs are nominally domain-isolated, they can be aggregated with IP addresses, browser fingerprints, and cross-site Flash access to construct longitudinal user profiles spanning multiple domains and devices, amplifying risks of behavioral . Prior to the EU's in 2018, no legal framework mandated explicit user consent for LSO deployment, fostering reliance on implied permission through site usage and sparking debates over whether such practices constituted unfair absent opt-in mechanisms. These mechanisms underscored systemic gaps in early web enforcement, where of tracking prevalence outpaced regulatory responses.

Security vulnerabilities and persistence issues

Local Shared Objects (LSOs) in were susceptible to exposure through broader vulnerabilities in the Flash Player runtime, which suffered from numerous security flaws allowing . For instance, exploits documented in CVE entries, such as those enabling remote code execution via malformed Flash content, could potentially grant attackers access to local file systems where LSOs are stored, thereby risking the leakage of stored data like user preferences or identifiers. A key persistence issue arose from LSOs' storage mechanism, which operated independently of browser-managed data, evading standard cookie deletion processes during browser history or cache clearing. Unlike HTTP , LSOs required manual intervention via the Flash Player settings manager or direct deletion from directories such as %APPDATA%/Macromedia/Flash Player/#SharedObjects on Windows, complicating routine user cleanup. This durability extended to non-compliance with browser privacy features, including private or incognito modes, as LSOs persisted across sessions due to Flash Player's system-level file handling rather than browser-controlled temporary storage. Such persistence hindered adherence to data protection mandates like the "" under regulations such as the EU's GDPR, where incomplete erasure of LSOs could retain user data indefinitely without specialized tools. In , LSOs incorporated domain-specific isolation, storing data in subdirectories keyed to originating domains, which limited cross-site risks inherent in more global storage alternatives. Moreover, core vulnerabilities primarily afflicted the Flash runtime's and sandboxing—such as buffer overflows or type confusion errors—rather than the LSO itself, suggesting that secure deployment of the Player could contain exposure risks absent runtime compromise.

Management and controls

User-level deletion and settings

In the Flash Player Settings Manager, accessible via right-click context menu on Flash content or through the standalone control panel, users could manage local shared object (LSO) storage through dedicated panels focused on website-specific and global controls. The Website Storage Settings panel listed domains that had requested LSO storage, enabling users to adjust per-site disk space quotas using a slider (ranging from 0 KB to 100 MB or more, depending on version) or select a site and click "Delete data" to erase all associated LSO files and settings for that domain. This deletion reset the site's permissions to global defaults upon revisit, providing targeted user intervention without affecting other domains. The Global Storage Settings panel offered broader oversight, where users set a system-wide maximum disk space limit for LSOs across all websites, with the ability to reduce it to 0 KB to block creation universally and select "Never Ask Again" to enforce the restriction without prompts. When a website's Flash content attempted to exceed its quota, Flash Player displayed an on-screen dialog prompting the user to allow additional space, deny the request, or configure persistent options like "Always allow" or "Always deny" for that domain. These mechanisms allowed users to balance functionality—such as retaining game progress or preferences—with privacy by denying or limiting persistent data storage on a granular basis. For sites using debug versions of Flash Player, developers could implement methods like SharedObject.flush() or manual clearing in code, but end-users accessed these indirectly through the settings panels rather than scripting interfaces. Overall, these user-facing tools in Flash Player versions up to 32.0 (end-of-life in 2020) emphasized opt-in consent for storage, though enforcement relied on user awareness and manual checks.

Browser and system integration

Local Shared Objects (LSOs), also known as Flash cookies, were stored independently of standard browser cache and cookie mechanisms, persisting even after users cleared browsing data through browser interfaces. This separation required manual intervention for management, typically involving navigation to specific system directories such as %APPDATA%\Macromedia\Flash Player\#SharedObjects on Windows systems to locate and delete .sol files organized by domain. Users could also employ batch scripts to recursively remove contents from these directories, remaking empty folders afterward to prevent recreation errors, though such methods demanded familiarity with paths and carried risks of disrupting Flash-dependent applications. Limited registry modifications existed for broader Flash Player configurations, such as adjusting global storage permissions via Adobe's settings manager, but direct tweaks for LSO deletion were uncommon and often ineffective without complementary actions. Following updates around 2010, browsers like implemented out-of-process plugin execution for Flash, starting with version 3.6.4, which ran the plugin in a separate plugin-container.exe process to isolate it from the main browser thread, thereby reducing potential cross-contamination in memory access though LSO file persistence on disk remained unchanged. Third-party system utilities facilitated easier LSO management by scanning and batch-deleting these files. For instance, included options under its Applications tab to target data, allowing users to remove LSOs during routine cleanups without manual directory traversal. This integration enabled more accessible maintenance, particularly for non-technical users, by automating detection and erasure of LSOs stored across user profiles.

Legacy status and alternatives

Impact of Adobe Flash discontinuation

Adobe ceased support for Flash Player on December 31, 2020, after which no updates or security patches were provided, rendering the technology obsolete for active use. Major browsers enforced this by disabling Flash content: removed support in version 88 and later starting January 2021, while and blocked it by default from the same month. This timeline prevented runtime execution of Flash-based code, including mechanisms for creating, reading, or modifying Local Shared Objects (LSOs), effectively eliminating their role in contemporary web interactions as of early 2021. Legacy LSO files, stored as .sol extensions in system directories such as those under /Flash Player, persist on user devices but lack runtime accessibility without Flash execution, making them inert data remnants. Users can remove these files by searching for the .sol extension via operating system tools—typically located in application data folders on Windows (e.g., %APPDATA%\Macromedia\Flash Player) or equivalent paths on macOS and —and deleting them manually, a process that poses no functional risk post-discontinuation. No new vulnerabilities in LSO handling have emerged since the end-of-life enforcement, as Flash's absence blocks potential exploits tied to its storage mechanisms. Empirically, LSOs exhibit negligible presence in the modern web , with active Flash content comprising under 0.1% of by due to migration to alternatives, rendering LSO-dependent features obsolete. Emulators like Ruffle, designed for legacy preservation, emulate save data via browser local storage rather than fully replicating LSO functionality, and do not support importing or sharing original .sol files seamlessly, further limiting their viability. This incomplete compatibility underscores LSOs' diminished utility, confining them to archival or offline contexts without broader integration.

Modern web storage replacements

The primary modern replacements for local shared objects (LSOs) in web applications are the localStorage and IndexedDB APIs, standardized under the Storage Standard and W3C Indexed Database API, respectively. These mechanisms provide origin-bound persistent storage without relying on plugins like , adhering to the to isolate data per domain and prevent cross-site access. Unlike LSOs, which supported formats for efficiency in multimedia applications, these APIs emphasize structured text or object storage within browser sandboxes, trading some compactness for enhanced security isolation and cross-browser interoperability. localStorage offers a synchronous key-value interface for storing simple data, typically limited to 5-10 MB per origin depending on the browser implementation. It persists across browser sessions until explicitly cleared by the user or via storage quota management, similar to LSO persistence, but data is exposed to inspection, raising comparable risks if sites store tracking identifiers. Developers access it via methods like setItem(key, value) and getItem(key), with automatic of objects to strings, making it suitable for lightweight preferences or user state but prone to blocking the main thread on large operations. In contrast, IndexedDB provides an asynchronous, transactional for handling larger, structured datasets including blobs and hierarchical objects, with quotas often exceeding hundreds of MB or more based on available disk space rather than fixed limits. It supports indexing, querying, and cursors for efficient retrieval, addressing LSO limitations in data complexity at the cost of a steeper and verbose calls involving promises or callbacks. While offering non-blocking performance advantages over localStorage's synchronous nature, IndexedDB requires explicit transaction handling and error management, and like localStorage, its data can be cleared upon browser uninstallation or privacy-focused data wipes. These standards promote consistent behavior across browsers like Chrome, , and , reducing the proprietary fragmentation seen with LSOs, but they forgo binary storage efficiency in favor of sandboxed security that mitigates risks from untrusted code execution. localStorage suits with minimal overhead, while IndexedDB excels for applications requiring scalable, queryable , though both inherit exposure to origin-compromising attacks without additional encryption.

References

  1. https://airsdk.dev/reference/actionscript/3.0/flash/net/SharedObject.html
  2. https://apache.github.io/royale-docs/working-with-data/loading-external-data/localsharedobject
  3. https://www.computerlanguage.com/results.php?definition=local%2Bshared%2Bobject
  4. https://open-flash.github.io/mirrors/as2-language-reference/SharedObject.html
  5. https://cdn.aaai.org/ocs/1070/1070-6009-1-PB.pdf
  6. https://www.enzuzo.com/blog/local-shared-objects
  7. https://www.cookieyes.com/blog/flash-cookies/
  8. https://pandectes.io/blog/flash-cookies-explained-are-they-still-a-privacy-risk/
  9. https://www.permadi.com/tutorial/flashSharedObject/index.html
  10. https://www.kirupa.com/developer/mx/sharedobjects.htm
  11. https://www.zscaler.com/blogs/security-research/demystifyingabusing-flash-cookies
  12. https://www.nytimes.com/2005/04/19/technology/adobe-buys-macromedia-for-34-billion.html
  13. https://helpx.adobe.com/adobe-media-server/ssaslr/sharedobject-class.html
  14. https://blog.adobe.com/en/publish/2017/07/25/adobe-flash-update
  15. https://www.adobe.com/products/flashplayer/end-of-life-alternative.html
  16. https://www.zdnet.com/article/adobe-to-block-flash-content-from-running-on-january-12-2021/
  17. https://blogs.ed.ac.uk/dlam/2021/01/11/adobe-flash-player-eol-guidance/
  18. https://www.nirsoft.net/utils/flash_cookies_view.html
  19. https://rtmp.veriskope.com/pdf/amf3-file-format-spec.pdf
  20. https://towerwall.com/towerwall-security-alert-v13-79-clear-cookies-flash-cookies-local-storage/
  21. http://www.flashsec.org/wiki/Main_Page/local_shared_objects.html
  22. https://stackoverflow.com/questions/22966502/is-there-a-size-limit-for-localshared-objects-created-on-mobile-apps-ios-androi
  23. https://www.ghacks.net/2007/05/04/flash-cookies-explained/
  24. https://seo.ai/faq/local-shared-object---commonly-called-flash-cookies-lso
  25. https://www.practicalecommerce.com/An-Introduction-to-Flash-Cookies-How-to-Manage-Them
  26. https://airsdk.dev/docs/development/files-and-data/storing-local-data/shared-objects
  27. https://stackoverflow.com/questions/21499660/actionscript-3-0-sharedobject-flush-problems
  28. https://airsdk.dev/docs/development/security/shared-objects
  29. https://stackoverflow.com/questions/46112644/i-cant-display-shared-object-another-swf-on-air
  30. https://titling.tistory.com/2
  31. https://magp.ie/2010/03/22/javascript-externalinterface-flash-and-local-shared-objects/
  32. https://github.com/nfriedly/Javascript-Flash-Cookies
  33. https://airsdk.dev/reference/actionscript/3.0/flash/external/ExternalInterface.html
  34. https://as3gametuts.com/2012/02/28/actionscript-saving-and-loading-tutorial/
  35. https://gamedev.stackexchange.com/questions/12232/flash-high-scores
  36. https://stackoverflow.com/questions/20486291/how-to-store-flash-based-games-data-into-server
  37. https://helpx.adobe.com/adobe-media-server/tech-overview/media-server-architecture.html
  38. https://www.wired.com/2009/08/you-deleted-your-cookies-think-again/
  39. https://ashkansoltani.org/2011/08/11/respawn-redux-flash-cookies/
  40. https://www.privacypolicyonline.com/flash-cookies/
  41. https://yro.slashdot.org/story/10/07/27/2358238/lawsuit-hits-companies-using-zombie-flash-cookies
  42. https://www.pcworld.com/article/520423/privacy_watch_flash_cookies.html
  43. https://ashkansoltani.org/2009/08/09/flash-cookies-and-privacy/
  44. https://www.cisa.gov/news-events/alerts/2015/07/14/adobe-flash-and-microsoft-windows-vulnerabilities
  45. https://unit42.paloaltonetworks.com/unit42-traps-prevents-adobe-flash-player-zero-day/
  46. https://cookiecontroller.com/internet-cookies/flash-cookies/
  47. https://www.blackhat.com/presentations/bh-dc-09/Sutton/blackhat-dc-09-Sutton-persistent-storage.pdf
  48. https://hatsoffsecurity.com/2016/05/04/flash-cookies-aka-local-share-objects/
  49. https://hackmd.io/%40MEkcX1jJQ0C77ryTXCEcUA/BJzsXMP_gl
  50. https://www.cve.org/CVERecord/SearchResults?query=adobe%2520flash
  51. https://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html
  52. https://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html
  53. https://community.adobe.com/t5/flash-player-discussions/how-do-i-clear-my-flash-player-cache-and-settings/td-p/4015768
  54. https://community.adobe.com/t5/flash-player-discussions/disabling-local-shared-objects/td-p/9347576
  55. https://stackoverflow.com/questions/23021977/how-to-delete-all-created-localsharedobjects-in-as3
  56. https://palant.info/2009/03/02/getting-rid-of-flash-cookies/
  57. https://ardamis.com/2010/07/07/how-to-delete-flash-cookies/
  58. https://www.elifulkerson.com/articles/disable-flash-shared-objects-batchfile.php
  59. https://kb.mozillazine.org/Flash
  60. https://support.ccleaner.com/s/article/clean-flash-cookies-with-ccleaner-for-windows
  61. https://www.reputationdefender.com/blog/privacy/how-to-delete-flash-cookies-permacookies-and-zombie-cookies
  62. https://www.chromium.org/flash-roadmap/
  63. https://www.bleepingcomputer.com/news/microsoft/microsoft-to-finally-kill-adobe-flash-support-by-january-2021/
  64. https://smallbusiness.chron.com/delete-sol-file-26863.html
  65. https://datahorde.org/how-to-run-flash-in-2021-flash-player-eol-workarounds/
  66. https://github.com/ruffle-rs/ruffle/discussions/3816
  67. https://superuser.com/questions/1779029/where-does-the-ruffle-flash-player-save-permanent-files-to-like-game-saves-or
  68. https://storage.spec.whatwg.org/
  69. https://www.w3.org/TR/IndexedDB/
  70. https://dev.to/armstrong2035/9-differences-between-indexeddb-and-localstorage-30ai
  71. https://blog.openreplay.com/indexeddb-localstorage-sessionstorage/
  72. https://softwareengineering.stackexchange.com/questions/219953/how-is-localstorage-different-from-indexeddb
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.