GDPR Compliance & Privacy

How doable-server and doable-tracker handle personal data, and what consent gets you.

This document is intentionally plain-English. It describes what we collect, how long we keep it, and which deployment modes meet GDPR "affirmative consent" requirements out of the box.

TL;DR

doable offers two distinct ways to use the analytics stack:

The tracker-only mode is designed to be GDPR-compliant by default: no personal data is retained without explicit consent. One admin checkbox enables the consent banner and the job is done.

The proxy-routed mode requires the additional proxy-level controls (IP truncation, DNT as fallback, consent-aware aggregation) because the proxy necessarily sees every request before the tracker's consent logic runs.

Quick reference: decision precedence

Case 1: Tracker-only sites

What this looks like

Your site (e.g., mysite.com) is hosted wherever you like. You add this to your HTML:

<script src="https://doable.services/static/dt.min.js"></script>
<script>
  DoableTracker.init({
    trackingId: 'dt_xxx',
    apiKey: 'your_api_key'
  });
</script>

Your site's server never talks to doable-server. The only communication is: 1. The visitor's browser fetches dt.min.js from doable.services 2. The tracker fetches /api/v1/track/config/<tracking_id> to check consent settings (cached 1h) 3. The tracker posts events to /api/v1/track (only after consent granted)

What doable-server collects for tracker-only sites

Critically: the /api/v1/track endpoint bypasses proxy.py → log_access() entirely. No entries are written to AccessLog. No Graylog entries. The only persistent storage is ExternalAnalyticsEvent (raw events) and ExternalAnalyticsDaily (aggregated counters). Both handle IPs as SHA256 hashes, never raw.

What cookie consent adds

Before v2.6.23: tracker fires on every pageview regardless of visitor preference.

As of v2.6.23: admin toggles "Require cookie consent" on the tracking project. Tracker then: 1. Shows a neutral bottom banner with Accept and Decline buttons of visually equal prominence (GDPR Art 7(2) requires this) 2. Stores decision in the dt_consent cookie (SameSite=Lax; Secure; Path=/; Max-Age=31536000). Cookie is used rather than localStorage so the proxy layer can read the same decision. 3. Sends events only on granted; stays silent on denied 4. Creates the session ID only after Accept — before consent, nothing is written to the visitor's device (fixes ePrivacy Art 5(3) compliance) 5. On Accept, posts a lightweight consent_granted event to /api/v1/track/consent for audit trail (Art 7(1) accountability) 6. Shows an always-visible floating revoke icon (bottom-left, 32×32px) so withdrawing consent is as easy as giving it (Art 7(3))

No visitor is tracked in doable's systems without an affirmative Accept click. Decision persists across sessions and browser restarts. Revocable via the floating icon, doable('revoke'), or clearing the cookie.

Why this is GDPR-aligned out of the box

• Affirmative consent — Accept/Decline buttons equally prominent (GDPR Art 7 requires this)
• Granular retention — raw events 7 days, aggregates indefinite (but depersonalized)
• No raw IPs — hashed before storage
• Minimal residual logging — Apache access log entries for the script + config fetch (legitimate interest for operational/security; typical 30-90d rotation)
• Revocation — easy via doable('revoke'), no separate portal needed

What's NOT covered

• Apache's default access log still records the fact that a visitor requested dt.min.js (IP, UA). This is standard HTTP server logging, justifiable under legitimate interest for operations and security. To minimize further, configure CustomLog rotation aggressively (e.g., 14-day rotation).
• If your site has its own analytics (Google Analytics, etc.) alongside doable-tracker, those are separate concerns.

Case 2: Proxy-routed sites

What this looks like

Your site (e.g., tomasandre.se) routes through doable-server:

Internet → Apache (443) → Flask gateway (5000) → Backend on 192.168.x.x

The proxy sees every request and can inject metadata, enforce auth, rate-limit, and — historically — log everything about every visitor.

What the proxy logs

Important: all of this happens at the gateway — before the tracker ever loads in the visitor's browser. Cookie consent on the tracker alone doesn't prevent the proxy from recording the request.

What v2.7.0 changes (proxy data minimization)

As of v2.7.0, with defaults applied:

1. IP truncation (pseudonymization) — AccessLog.client_ip stores 192.168.44.0 instead of 192.168.44.123. Raw IP is kept only in-memory during the request for ban-check and rate-limiting. Configurable via PROXY_IP_TRUNCATE (default on). Note: /24 truncation is pseudonymization under GDPR Art 4(5), not full anonymization — a residence or small office may still be identifiable.
2. Consent-aware aggregation — visitor declines the cookie consent banner → dt_consent=denied cookie set → proxy reads it and skips update_analytics(). Only minimal access log entry (truncated IP, method, path, status) remains.
3. DNT as fallback — DNT: 1 header skips analytics aggregation only when no explicit banner decision has been made. Explicit Accept on the banner overrides DNT (the banner is specific and informed; DNT is a general preference).
4. Retention policy — AccessLog entries older than 90 days (configurable) are deleted by a scheduled cleanup script. Aggregates kept 2 years (already depersonalized). Consent audit logs kept 7 years (GDPR statute of limitations).
5. Apache log rotation mandate — deployment must include logrotate config with short retention (default 14d) to minimize residual IP exposure from pre-consent requests (dt.min.js and /api/v1/track/config/<id> fetches).

Together, cookie consent + proxy data minimization mean: - Consented visitor → full analytics, as today - Declined visitor → minimal truncated-IP access log only, no browser fingerprinting or UTM tracking stored - DNT visitor with no banner decision → same as declined - DNT visitor who clicked Accept → full analytics (explicit consent wins)

Known limitation: first-request blind spot

On proxy-routed sites with require_consent_proxy=True, the first request from a fresh browser cannot be aggregated — the banner hasn't rendered yet, so there's no cookie to read. Subsequent requests after Accept are aggregated normally. This means cumulative analytics slightly undercount unique visitors, but it's the correct behavior under GDPR (no consent = no tracking).

Why this is GDPR-aligned

• Proportionate data minimization — only data needed for the declared purpose is kept
• IP truncation (pseudonymization) aligns with GDPR Art 4(1) interpretations of personal data (CJEU Breyer)
• Short retention of identifiable data, longer for depersonalized aggregates
• Consent decision honored across both layers (tracker + proxy)
• DNT respected without requiring UI click

Data collected per endpoint (full table)

Comparison with other analytics

doable-tracker sits between Plausible's minimalism and Matomo's full-feature approach, with consent being a toggle rather than a separate integration.

Retention policy (defaults)

Aggregates are JSON counters like {"Chrome": 1043, "Firefox": 198} — they contain no per-user data and are safe to retain indefinitely for trend analysis.

For site operators: controller/processor relationship

Under GDPR Art 4(7-8), when you (the site operator) use doable-tracker to collect analytics about your visitors, you are the data controller and doable.services is the data processor acting on your instructions.

Data Processing Agreement (DPA) required

GDPR Art 28 requires a written DPA between controller and processor. The DPA must specify:

• Subject matter, duration, nature, and purpose of processing
• Types of personal data and categories of data subjects
• Obligations and rights of the controller
• Processor commitments (confidentiality, security, sub-processors, etc.)
• Assistance with data subject requests, breach notification, audits
• Return/deletion of data at end of contract

A template DPA is available at docs/dpa-template.md (forthcoming — contact your account). Customize with: - Your organization's legal entity details - The tracking project IDs covered - Retention periods matching your privacy policy

Sign it, keep a copy, and reference the signed DPA in your privacy policy.

Data transfer (international)

doable.services infrastructure is hosted in Sweden (EU). Visitor data is: - Collected in the EU - Processed in the EU - Stored in the EU

This means no international transfer under GDPR Art 44-49 for EU/EEA-based site operators and visitors. No Standard Contractual Clauses (SCCs) required.

If doable.services ever moves infrastructure outside the EU, site operators will be notified in advance and SCCs will be added to the DPA. Current status is always documented in config.py comments and at the top of docs/gdpr-compliance.md.

For site operators outside the EU: your local data protection law may still require equivalent agreements. Verify with a DPO.

Visitor rights

Per GDPR Art 15-22, visitors can request:

Site operators using doable-tracker should include this in their privacy policy.

Configuring for GDPR compliance (checklist)

Tracker-only sites

• [ ] Admin toggles "Require cookie consent" on tracking project
• [ ] (Optional) Custom consent_text in local language
• [ ] (Optional) privacy_url linking to your privacy policy
• [ ] Verify the always-visible floating revoke icon is enabled (default), OR provide your own revoke UI and set hideRevokeButton: true
• [ ] Update site privacy policy to mention doable-tracker, data collected, retention, visitor rights
• [ ] Sign DPA with doable.services (Art 28 requirement)
• [ ] Review data transfer section — verify doable.services' hosting region matches your visitors' jurisdiction

Proxy-routed sites (in addition to tracker-only)

• [ ] Admin toggles "Require cookie consent at proxy level" on the route
• [ ] Verify PROXY_IP_TRUNCATE=true in server config
• [ ] Deploy /etc/logrotate.d/apache2-doable-server with 14-day rotation (mandatory)
• [ ] Tune ACCESS_LOG_RETENTION_DAYS to your policy (default 90)
• [ ] Tune CONSENT_LOG_RETENTION_DAYS to match legal statute of limitations (default 2555 / 7y)
• [ ] Confirm retention cleanup cron is running (pm2 list should show access-log-cleanup)
• [ ] Configure Graylog retention separately in Graylog admin
• [ ] Document legitimate-interest basis for minimal access logs in your privacy policy
• [ ] Disclose the first-request blind spot in your privacy policy if strict completeness is important

AI Insights privacy note

Doable AI Insights analyses each resource's analytics summary once a day using a local Ollama instance. Specifically:

• Input to the model is the already-aggregated summary from /api/v1/summary/<id> (KPI deltas, top paths, top referrers, audience breakdowns). No per-visitor rows, no IPs, no user agents are sent to the model.
• Ollama runs on the doable-server host. Data never leaves the server. There are no outbound API calls to OpenAI, Anthropic, Google, or any other cloud LLM.
• Insights are stored in ai_insight_runs with a hash of the summary input so unchanged data is skipped within 23 h.
• Retention: AI_INSIGHTS_RETENTION_DAYS (default 365).
• Email alerts (when a deterministic significant finding triggers) contain only the finding text plus a dashboard link — no raw analytics data.
• Per-user opt-out at /dashboard/settings disables the email alerts for that user. The server-wide switch is AI_INSIGHTS_ENABLED.

Nothing about the AI Insights pipeline expands the personal-data surface established by cookie consent and proxy data minimization — it is a downstream consumer of the same already-minimized aggregate data.

Google Search Console privacy note

The GSC integration uses a shared service account authenticated to properties that users explicitly add the service-account email to as a Restricted user in Google Search Console. Specifically:

• Data returned by GSC is aggregate — queries with counts, landing pages with counts, device buckets, country buckets. GSC itself does not return individual-visitor information to any of its API consumers.
• Queries that matched fewer than GSC's own threshold are already filtered by Google for privacy before data reaches doable-server.
• The service account only accesses GSC properties for which it has been explicitly granted Restricted-user access. Removing the email in GSC revokes access immediately; after 3 consecutive failed sync attempts the integration flips to error and an owner email is sent with re-add instructions.
• GSC data is stored in gsc_daily_snapshots, gsc_query_daily, gsc_page_daily, gsc_device_daily, gsc_country_daily. Retention: GSC_RETENTION_DAYS (default 730).
• When an integration is disconnected, historical rows are retained for GSC_POST_DISCONNECT_RETENTION_DAYS (default 30) before cascade-purge.
• Service account credentials live in instance/gsc-service-account.json (chmod 600, gitignored). The service account email is public information by design — it's the copy-paste identifier users add to their properties.

Version history of privacy features

Disclaimer

This document describes the technical capabilities of doable-server and doable-tracker. It does not constitute legal advice. GDPR compliance depends on your specific deployment, jurisdiction, the nature of data you collect beyond what doable tracks, and your documented lawful basis. Consult a qualified data protection officer or lawyer for your use case.