update rum

docs/EU-RUM-PRIVACY.md

@@ -0,0 +1,164 @@
+# 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.