In one paragraph
LocalStorage tracking before consent means the snapshot contained storage keys matched by this check's analytics or recording patterns before the scanner interacted. Device storage and access rules are not limited to cookies, but a key name alone does not prove its purpose or legal status. Review the real operation, applicable exemption, subsequent processing, and the choice lifecycle instead of moving identifiers between storage mechanisms.
Why it matters
ePrivacy Article 5(3) is technology-neutral within its scope. The EDPB's final technical-scope guidelines address device-related storage and access beyond ordinary cookies. A short session lifetime or storage API choice does not by itself exempt an operation.
Local storage does not automatically accompany HTTP requests like matching cookies can, but application code can read and transmit stored information. Whether and how it does so needs actual implementation review rather than a conclusion from one stored key.
Consent requirements and personal-data processing remain related but separate. Self-hosting or using a backend proxy does not inherently remove applicable duties. Classify purpose and operation before changing deployment simply to improve a detector result.
How WebAuditOS evaluates this finding
The supplied fresh-mobile snapshot enumerates localStorage and sessionStorage keys for the top-level page during its documented short observation window. Listed exact or prefix matches fail at medium severity; no recognised match passes; unavailable snapshots can be ungraded.
The source describes key-based grading rather than value interpretation. It does not cover every vendor, IndexedDB, Cache API, other-origin frames, delayed operations, or server-side processing. Broad prefixes such as mp_ can collide with unrelated application keys, so attribution needs confirmation.
How to fix it
- Inspect the exact storage type, origin, key, initial state, and observed timing without exposing identifier values in public reports. Establish a reproducible fresh-profile test.
- Identify which code writes and reads the key. Confirm whether a recognised prefix actually belongs to the presumed SDK or to your own unrelated application feature.
- Review the purpose and applicable device-access exemption. A necessary application preference and optional session-recording identifier are not equivalent simply because they use the same API.
- Initialise consent-dependent SDK behaviour only under the appropriate conditions. Check load-time defaults, retries, embedded libraries, and code paths outside the main tag manager.
- Test what happens after refusal, category grant, return visits, and withdrawal. Decide how stored information and future operations should be handled under the reviewed design; deleting one key is not the whole processing assessment.
- Inspect other storage and access mechanisms manually where relevant. Avoid moving an identifier to IndexedDB merely because the scanner does not enumerate it.
- Review network transmission separately. A key's presence does not prove which values were sent, while absence of the listed key does not prove no relevant data left the device.
- Rescan and retain a context-specific technical and legal record. A name-list pass or failure is limited evidence, not an independent consent-validity judgment.
What the fix can break
Indiscriminate storage clearing can remove a user's saved preferences or other necessary application state. Preserve the required service and distinguish optional tracking from functional data.
Changing SDK persistence can break account or analytics identity assumptions. Evaluate the resulting operation rather than only the storage location.
Do not publish real stored identifiers or a customer's session content as demonstration material. Reproduce with appropriate test data and minimal evidence.
Questions
Is sessionStorage exempt because it is temporary?
Not automatically. Assess actual storage or access and purpose under the applicable rules.
Does a known prefix always identify the SDK?
No. Prefix matching can overmatch unrelated application data.
Does this check cover IndexedDB and every frame?
Not in the supplied scope. Review other mechanisms and origins separately.
Which related checks help?
Review cookie timing, request timing, and the cookie consent guide.