Privacy

This document describes what Etherpad stores and logs about its users, so operators can publish an accurate data-processing statement.

Pad content and author identity

• Pad text, revision history, and chat messages are written to the configured database (see dbType / dbSettings).
• Authorship is tracked by an opaque authorID that is bound to a short-lived author-token cookie. There is no link between an authorID and a real-world identity unless a plugin or SSO layer adds one.

IP addresses

Etherpad never writes a client IP to its database. IPs only appear in log4js output (the access, http, message, and console loggers). Whether those are persisted depends entirely on the log appender your deployment configures.

The ipLogging setting (settings.json) controls what those log records contain. All five log sites respect it:

Setting value	Access / auth / rate-limit log contents
"anonymous" (default)	the literal string ANONYMOUS
"truncated"	IPv4 with last octet zeroed (1.2.3.0); IPv6 truncated to the first /48 (2001:db8:1::); IPv4-mapped IPv6 truncates the embedded v4; unknowns fall back to ANONYMOUS
"full"	the original IP address

The pre-2026 boolean disableIPlogging is still honoured for one release cycle: true maps to "anonymous", false maps to "full". A deprecation WARN is emitted when only the legacy setting is present.

Rate limiting

The in-memory socket rate limiter keys on the raw client IP for the duration of the limiter window (see commitRateLimiting in settings.json). This state is never written to disk, never sent to a plugin, and is thrown away on server restart.

What Etherpad does not do

• No IP addresses are written to the database.
• No IP addresses are sent to clientVars (and therefore to the browser). The long-standing clientIp: '127.0.0.1' placeholder was removed in the same change that introduced ipLogging.
• No IP addresses are passed to server-side plugin hooks by Etherpad itself. Plugins that receive a raw req can still read req.ip directly — audit your installed plugins if you need to rule that out.

Cookies

See cookies.md for the full cookie list.

Right to erasure (GDPR Art. 17)

Etherpad anonymises an author rather than deleting their changesets (deletion would corrupt every pad they contributed to). Operators trigger erasure via the admin REST API:

curl -X POST \
  -H "Authorization: Bearer <admin JWT / apikey>" \
  "https://<instance>/api/1.3.1/anonymizeAuthor?authorID=a.XXXXXXXXXXXXXX"

The endpoint is gated by the gdprAuthorErasure setting (see settings.json). It is disabled by default; set "gdprAuthorErasure": { "enabled": true } to expose it. While disabled, calls return HTTP 404 / API code 4 ("no such function").

What the call does:

• Zeros name and colorId on the globalAuthor:<authorID> record (kept as an opaque stub so changeset references still resolve to "an author" with no details).
• Deletes every token2author:<token> and mapper2author:<mapper> binding that pointed at this author. Once removed, a new session with the same token starts a fresh anonymous identity.
• Nulls authorId on chat messages the author posted; message text and timestamps are unchanged.

What it does not do:

• Delete pad content, revisions, or the attribute pool. If a pad itself should also be erased, use the pad-deletion token flow (PR1, deletePad).
• Touch other authors' edits.

The call is idempotent: calling it twice on the same authorID short-circuits the second time and returns zero counters. Pad-level deletion is covered separately by the deletion-token mechanism in docs/superpowers/specs/2026-04-18-gdpr-pr1-deletion-controls-design.md; the rest of the GDPR work is tracked in ether/etherpad#6701.

Pad retention (optional)

Etherpad keeps every pad forever unless you tell it otherwise. The padRetention block in settings.json deletes pads nobody has edited for a set number of days:

"padRetention": {
  "enabled": true,
  "dryRun": false,
  "deleteAfterDays": 90,
  "warnBeforeDays": 7,
  "sweepIntervalHours": 1,
  "excludeGroupPads": true,
  "excludePattern": null
}

It is off by default. When you first turn it on, leave "dryRun": true (the default). Etherpad then only logs the pads it would delete (would delete pad <id>), plus a summary after each sweep. Check the list, then set "dryRun": false.

How it works:

• Only edits count. Opening, reading or chatting in a pad doesn't keep it alive. A pad that was never edited counts from when it was created.
• Every pad is checked every sweepIntervalHours, starting a minute after Etherpad starts. A pad is also checked when someone opens it, so an overdue pad never loads with its old content.
• Deletion is permanent and complete, the same as the deletePad API: revisions, chat, the read-only link and the group entry are removed, and plugins clean up their own data through the padRemove hook. No copy is kept. Anyone still in the pad is disconnected.
• Someone opening a pad inside the last warnBeforeDays days sees a notice saying when it will be deleted, so they can edit or export it. Someone opening a pad that has just been deleted is told why it is new. Set warnBeforeDays to 0 to turn the warning off.
• Group pads (g.xxxxxxxxxxxxxxxx$name) are skipped while excludeGroupPads is true. Integrations such as Nextcloud and Moodle create these pads through the API and keep their own links to them. Only turn this off if those integrations expect pads to disappear.
• excludePattern is a regular expression for pad IDs to keep, for example "^(welcome|rules)$".

If a value is invalid (for example a negative number, or a pattern that isn't a valid regex), Etherpad logs an error at startup and leaves retention off.

Pair this with the privacy banner to tell users how long pads are kept.

Privacy banner (optional)

The privacyBanner block in settings.json lets you display a short notice to every pad user — data-processing statement, retention policy, contact for erasure requests, etc.

"privacyBanner": {
  "enabled": true,
  "title": "Privacy notice",
  "body": "This instance stores pad content for 90 days. Contact privacy@example.com to request erasure.",
  "learnMoreUrl": "https://example.com/privacy",
  "dismissal": "dismissible"
}

The banner is rendered as a persistent gritter notification at the bottom of the page (it inherits the same look as every other gritter on the pad — no custom skin needed). The body is plain text (HTML is escaped); each line becomes its own paragraph.

dismissal controls how the close (×) is handled:

• "dismissible" (default) — when the user closes the gritter, the choice is persisted in localStorage per origin and the banner is not shown again on subsequent pad loads.
• "sticky" — closing the gritter only hides it for the current session; the next pad load shows it again. (The close control is not removed; for an operator-enforced non-closable notice, render the policy out-of-band — e.g., a skin override or a reverse-proxy ribbon.)

Unknown dismissal values are coerced to "dismissible" with a logger.warn at settings load.