Local Shared Object

What a local shared object is

A local shared object, often called a Flash cookie, is a browser-adjacent storage file created by the Flash runtime. It let a site keep state on a device between visits, much like an ordinary cookie, but outside standard browser storage.

This mattered because the file could preserve preferences, identifiers, and other session-like data even when users cleared regular cookies. In practice, that made it useful for persistence, but also harder for users and defenders to notice and manage consistently.

How local shared objects behaved in the browser stack

Local shared objects lived at the boundary between web content and client-side runtime storage. They were not normal HTTP cookies, so they were not always controlled through the same browser settings, inspection tools, or privacy workflows that teams expected to apply to website state.

That difference in storage location is the key concept: the website still used the data as retained state, but the browser was not necessarily the only place where that state existed. For defenders, this meant “clear cookies” was not always equivalent to “remove all tracking or stored application state.”

Why websites used them

Sites used local shared objects for the same broad reasons they used cookies, including remembering user settings, maintaining continuity across sessions, and storing a stable identifier for returning visitors. For legacy Flash content, they were a practical way to preserve application state when browser-native storage was less capable or less standardized.

The trade-off was convenience versus visibility. Because the storage was tied to the Flash ecosystem, the data could outlive normal browser cleanup expectations and create a second persistence layer that users might not realise existed.

Security and privacy implications

Local shared objects created privacy and governance concerns because they could retain identifying data on the endpoint even after users believed they had reset their browser state. That made them attractive for persistent tracking, but also awkward for incident response, consent management, and data removal workflows.

They also created a larger cleanup problem for shared or unmanaged devices, where hidden application state can survive routine browser maintenance. Legacy browser persistence mechanisms like this are one reason modern privacy controls increasingly emphasise visible storage, explicit consent, and tighter lifecycle management for client-side data.

Risk and Threat Considerations

Local shared objects were a persistence mechanism, so the risk was not just storage, but hidden retention. If a website or attacker used them to cache identifiers, preferences, or tokens, the data could survive normal cookie-clearing habits and extend tracking or session continuity beyond what the user expected.

Failure mechanism: The file sits outside ordinary browser cookie workflows, so routine cleanup, user consent actions, or browser privacy settings may miss it while the runtime continues to read the stored state.

Impact: This can preserve identifiers longer than intended, complicate user privacy controls, and leave stale or unwanted application state on the device until the Flash storage layer is specifically removed.

Related resources from NHI Mgmt Group

• When should organisations choose local NVMe, shared file storage, or object storage for model weights?
• How should teams respond to a local Linux privilege escalation flaw in shared environments?
• What breaks when healthcare IAM is designed for local systems instead of shared records?
• Why do local Linux accounts and shared SSH keys increase security risk?