EU browser RUM error telemetry: privacy findings

Research date: 2026-11-04. Legal information, not a legal opinion or a deployment-specific compliance determination. SDK behaviour below is supplied context, not an independently audited implementation. No SDK change is proposed as automatically lawful.

Short answer

Not just cookies. Actual errors can sometimes be sent without consent, but only after two separate gates are satisfied. Replacing every error with Anonymous frontend event is not a universal EU requirement. Conversely, cookie-free, identifier-free or nominally anonymous browser telemetry is not automatically consent-exempt. Legitimate interests cannot override an ePrivacy consent requirement. [1-4]

Gate 1: ePrivacy terminal storage/access

Article 5(3) concerns storing information on, or accessing information already stored in, terminal equipment, whether or not it is personal data. The final EDPB Guidelines 2/2023 cover JavaScript-directed transmissions, locally generated information and RAM; there is no minimum storage duration. Thus no cookies, localStorage or sessionStorage is helpful but not decisive. An ephemeral in-memory page/session identifier can also matter. [1,3: paragraphs 4,6-12,32-39,52-56]

Consent is required unless the operation falls outside that scope or an exception applies: storage/access solely to transmit a communication, or strictly necessary to provide an information-society service explicitly requested by the user. Assess the actual collection operation and purpose under applicable national transposition and regulator guidance. Not every JavaScript API is forbidden, and an ordinary HTTP request does not inherently require consent. The EDPB's IP-tracking discussion distinguishes tracking from the technical use of IP addresses to establish/transmit communications. [1,3: paragraph 4, footnote 4, paragraphs 40,54-56 and footnote 28]

Security/reliability is not a blanket exemption. A narrowly necessary function protecting or delivering the requested service may qualify; general crash analytics, product improvement or performance measurement does not qualify merely because it helps the operator. WP29 gives user-centric login-abuse protection as a security example, but rejects a general first-party analytics exemption. Its examples are not approval of a RUM SDK. Country-specific analytics exemptions are not EU-wide permission: CNIL explicitly notes national variation. [4: sections 3.3,4.3; 8]

If the telemetry or its collection involves personal data, an Article 6 legal basis and the other GDPR requirements apply independently. IP addresses, device metadata, stack URLs and error messages often identify or relate to people, alone or in combination. Pseudonymous is not anonymous; hashing does not by itself anonymise data. Assess reasonably available identification/linkage means, including collector, proxy and vendor logs, not just the JSON payload. [2: Article 4, Recitals 26,30; 7]

Article 6(1)(f) legitimate interests may support narrowly necessary service reliability/security diagnostics without GDPR consent. Document a legitimate-interest assessment before collection: a specific lawful purpose, necessity (including less intrusive alternatives), and balancing against people's rights, reasonable expectations and risks. This is a possible application of the test, not an official finding that error telemetry always passes. Security is recognised in Recital 49; it does not make all reliability analytics necessary. Public authorities cannot rely on Article 6(1)(f) when performing their tasks. [2: Article 6(1)(f), Recitals 47,49; 6]

Provide Article 13 information, including purposes, basis, legitimate interests, recipients, retention period/criteria and rights. Apply Article 5 purpose and data minimisation, storage limitation and accountability. Under Article 21, handle objections based on the person's particular situation: cease the relevant processing unless the applicable overriding-ground/legal-claims exception is demonstrated. Special-category data needs an additional Article 9 condition; legitimate interests alone is insufficient. [2: Articles 5,9,13,21; 6,7,9]

Stop/do not start optional consent-dependent browser collection; do not relabel the same consent-required processing as legitimate interests after rejection. The EDPB requires selecting the basis in advance and rejects retrospective swapping from consent to legitimate interests. Independently established, accurately disclosed necessary diagnostics are a different question: they may continue only if both gates above are satisfied, not because refusal authorises them. Keep them separate from optional analytics/tracking. [3-6]

Ordinary application error logs generated on the server while serving an actual request do not, merely by being logged, add browser terminal storage/access. GDPR can still apply. Browser RUM additionally instructs the terminal to collect and transmit information, so a server-logging justification cannot automatically be imported. Request headers, identifiers and any additional terminal access still need their own assessment. [1-3: application of the scope test]

Assessment of the initial SDK defaults

The described no-storage/no-cookie/no-beacon defaults, fetch with credentials: omit and no-referrer, and removal of stack URLs/context reduce exposure. Neither transport choice nor the label "anonymous" establishes anonymity or exemption; the collector can still receive IP/network metadata. Numeric performance measurements also require the same two-gate assessment. Consent enabling raw diagnostics and an in-memory page ID does not remove minimisation, security or sensitive-data obligations. [2,3,7]

Conclusion: blanket replacement of actual errors may be unnecessarily restrictive for a separately justified minimal diagnostic purpose, while the remaining performance collection may still need consent. Do not loosen the SDK based only on "no cookies" or a generic security claim.

Implemented policy controls

The SDK now separates count-only errors, an explicitly configured minimal diagnostics sanitizer, consented diagnostics and host-allowlisted development diagnostics. Unknown or rejected minimal events fall back to counts, not raw exception content. The application is responsible for sanitizing permitted output and independently justifying the policy before enabling it.

Development mode requires an explicit flag and an exact hostname allowlist; the host application must first establish its own access/acceptance flow and applicable legal basis. A development label, login, allowlist or SDK switch is not a legal exemption. Withdrawal disables development mode and drops queued data. Optional Web Vitals waits for permission unless independently enabled; already-installed library observers require a reload for complete teardown.

These are engineering controls, not additional legal findings. Configuration, limits and examples are documented in the instrumentation guide.

Candidate minimal-diagnostics policy, subject to both gates

These are engineering recommendations, not a statutory safe harbour:

Allow build/release, app-controlled route templates and an allowlisted safe exception category. Prefer static classification over arbitrary exception text.
Permit only demonstrably necessary, scrubbed messages/stack frames; exclude query strings, URL fragments, user content, auth tokens/headers, request or response bodies, emails and user-specific paths. Scrubbing is imperfect; unknown free text should be omitted rather than assumed anonymous.
No stable visitor ID or fingerprint; avoid even a page ID unless separately necessary and assessed. Use a first-party collector without cross-site profiles or vendor reuse. First-party hosting alone is not an exemption.
Minimise IP/device metadata at collection, including ingress/access logs. Apply short, justified TTLs, deletion and access controls. There is no universal numeric EU retention period for RUM; document purpose-specific periods.
Identify controller/processor roles, use required processor contracts (Article 28), and review any third-country access/transfers (Chapter V). Document the ePrivacy analysis, legitimate-interest assessment, notice and objection handling before enabling the policy. [2: Articles 5,13,21,25,28,32, Chapter V; 3-7,9]

Primary official sources and verification limits

Only legislation and official regulator material were used. The EDPB/WP29 PDFs and EDPB/CNIL pages below were retrieved and read. The requested EUR-Lex links were checked, but returned no extractable text in this environment; their full texts were not independently retrieved. Article 5(3)'s scope/exceptions were cross-checked in the final EDPB guidance; GDPR findings were cross-checked against the EDPB guidance below. Recheck current legislation and the relevant country's law/guidance before an operational decision. Guidance interprets legislation; this note does not establish a jurisdiction-specific exemption.

ePrivacy Directive 2002/58/EC, consolidated 2009-12-19, Article 5(3).
GDPR, Regulation (EU) 2016/679.
EDPB Guidelines 2/2023, final page and version 2.0 PDF, adopted 7 October 2024; page published 16 October 2024. Scope guidance, not an exemption catalogue.
WP29 Opinion 04/2012 on cookie consent exemption, especially sections 3.3 and 4.3; historical guidance, subject to current national application.
EDPB Guidelines 05/2020 on consent, final PDF, paragraphs 120-123.
EDPB: Process personal data lawfully, legitimate interests and sensitive data.
EDPB: Data protection basics, identifiability and GDPR principles.
CNIL: Sheet 16, analytics, 11 June 2020; illustrative national guidance, not a current EU-wide exemption or RUM retention rule.
EDPB: Respect individuals' rights, information duties and objections.

11 KiB Raw Permalink Blame History