In one paragraph
Cookies set before consent means the fresh-browser snapshot contained a cookie name matched by the scanner's curated analytics or advertising list before it interacted with a choice interface. Investigate the actual cookie and operation rather than inferring the complete legal situation from a name. Non-exempt device storage or access needs prior consent under applicable rules; a first-party domain or secure flag does not create an exemption.
Why it matters
A consent banner can coexist with storage that already happened. The operational question is whether each relevant operation waits for the appropriate choice, not simply whether the page displays a CMP logo.
Names are evidence, not identity proof. A custom cookie can collide with a vendor pattern, while an unknown or delayed identifier can avoid the list. Cookie security attributes and domain classification describe other properties and do not determine whether storage is strictly necessary.
The ePrivacy terminal-access framework and GDPR personal-data requirements need distinct assessment. A broad assertion that every detected vendor name proves an infringement is inappropriate, as is treating a non-detection as complete legal approval.
How WebAuditOS evaluates this finding
The supplied rule loads sampled pages in a fresh mobile context without clicking or scrolling and takes its documented short settle snapshot. It matches cookie names case-sensitively against known patterns, reports listed matches as high-severity failures, and counts other cookies as unclassified.
No listed match passes; absent render or snapshot can be ungraded. The documented grading uses names, domains, and lifetime context rather than interpreting identifier values. This is not a verified promise about every component of the scanner's data-handling pipeline. Delayed writes, unknown vendors, and name collisions limit the conclusion.
How to fix it
- Reproduce in a clean appropriate profile and record the exact page, time, initial state, domain, name, and lifetime. Do not publish cookie identifier values unnecessarily in evidence reports.
- Identify the issuer and actual purpose through implementation and vendor documentation. Confirm whether a matched name represents the listed technology or a coincidental custom use.
- Assess whether the operation qualifies for an exemption under applicable law. First-party, short lifetime, Secure, or HttpOnly alone does not establish strictly necessary purpose.
- Initialise consent and tag behaviour before consent-dependent writes. Review direct scripts, tag-manager triggers, provider embeds, response cookies, and custom code rather than gating only one SDK.
- Test before interaction, refusal, specific grants, saved choices, and withdrawal. A fresh initial opt-in and a previously valid stored grant are different cases; verify which state the evidence actually represents.
- For Consent Mode or similar designs, inspect the actual remaining cookies and transmissions. A denied flag does not cure another integration writing a consent-dependent identifier independently.
- Review delayed and interaction-triggered writes beyond the scanner window. Do not move an unwanted operation a few seconds later solely to make the snapshot pass.
- Rescan and document limits and manual findings. Use the technical record as evidence for a context-specific assessment, not as a conclusive public allegation or compliance certificate.
What the fix can break
Blocking every cookie can break a requested authenticated or transactional service. Classify actual necessity rather than disabling storage without a reviewed design.
A visual toggle update can leave server or vendor writes unchanged. Coordinate technical enforcement with the user choice.
Do not rename a tracking cookie or proxy it through your domain to avoid a pattern. The actual operation remains the relevant issue.
Questions
Are first-party cookies automatically necessary?
No. Their purpose and applicable exemption determine the assessment, not merely the domain.
Does a matched name prove its vendor and legal basis?
No. Validate the implementation, context, and actual operation.
Does no listed cookie prove there is no tracking?
No. Unknown names, other storage mechanisms, delayed behaviour, and server-side processing can remain outside scope.
Which related checks help?
Review pre-choice requests, web storage, and the cookie consent guide.