164 lines
11 KiB
Markdown
164 lines
11 KiB
Markdown
# 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]
|
|
|
|
## Gate 2: GDPR personal-data processing
|
|
|
|
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]
|
|
|
|
## If consent is denied or withdrawn
|
|
|
|
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](../instrumentation.md#cookieless-diagnostics-and-consent).
|
|
|
|
## 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.
|
|
|
|
1. [ePrivacy Directive 2002/58/EC, consolidated 2009-12-19, Article 5(3)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02002L0058-20091219).
|
|
2. [GDPR, Regulation (EU) 2016/679](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng).
|
|
3. [EDPB Guidelines 2/2023, final page](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en) and [version 2.0 PDF](https://www.edpb.europa.eu/system/files/documents/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf), adopted 7 October 2024; page published 16 October 2024. Scope guidance, not an exemption catalogue.
|
|
4. [WP29 Opinion 04/2012 on cookie consent exemption](https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf), especially sections 3.3 and 4.3; historical guidance, subject to current national application.
|
|
5. [EDPB Guidelines 05/2020 on consent, final PDF](https://www.edpb.europa.eu/system/files/documents/files/file1/edpb_guidelines_202005_consent_en.pdf), paragraphs 120-123.
|
|
6. [EDPB: Process personal data lawfully](https://www.edpb.europa.eu/sme/be-compliant/process-personal-data-lawfully_en), legitimate interests and sensitive data.
|
|
7. [EDPB: Data protection basics](https://www.edpb.europa.eu/sme/learn-the-basics/data-protection-basics_en), identifiability and GDPR principles.
|
|
8. [CNIL: Sheet 16, analytics](https://www.cnil.fr/en/sheet-ndeg16-use-analytics-your-websites-and-applications), 11 June 2020; illustrative national guidance, not a current EU-wide exemption or RUM retention rule.
|
|
9. [EDPB: Respect individuals' rights](https://www.edpb.europa.eu/sme/be-compliant/respect-individuals-rights_en), information duties and objections. |