Meta data last download entry on files.

Cordy commented

2026-09-04 21:24:40 +00:00

Owner

— how can a “Last Downloader” of a file be tracked best? Scenario description: “someone leaks a file in our biotech startup, it is on reddit, we also downloaded the file from there again to check if it is truly our latest version. It is. Is there a possibility to see who leaked that information there technically? In the Audit log we see 10 people downloaded that specific file. Who was it?” Is there a implementation for this which is elegant, scalable, and not cost heavy on the Server-side?

Cordy added this to the v0.7 — Closed beta (dogfood + hardening) milestone

2026-09-04 21:24:40 +00:00

Cordy commented

2026-09-07 00:06:46 +00:00

Author

Owner

Legality research: per-jurisdiction deployability of download marking

Research snapshot: 2026-09-07. This table reflects the law as researched on this date; jurisdictions change their rules — treat entries older than this date as a starting point, not a current answer. Engineering research for product design, not legal advice; operators must verify locally before enabling.

What is being assessed: the feature as designed — off by default, embeds a pseudonymous random id (never a name; the id→person mapping stays on the operator's own server), disclosed to the operator with an explicit inform-your-users warning, admin-gated trace tool whose every use is itself audited, marks pruned with the audit log's retention. These properties are what keeps most of the world out of the red: nothing here is covert, content-revealing, or continuous behavioural surveillance — it is a per-download confidentiality measure.

Bottom line: no researched jurisdiction outright bans this design. The buckets are: 🟢 enable + inform users, 🟡 concrete prerequisites first, 🔴 conditionally blocked until a third party agrees (works councils / consent regimes) — the closest thing to a "hard no" that exists, and it is procedural, not absolute.

🟡→🔴 Strongest prerequisites (deployment blocked until satisfied)

Jurisdiction	Requirement before enabling
Germany	§87(1)(6) BetrVG: works council co-determination is mandatory for any technical system capable of monitoring behaviour/performance. Where a Betriebsrat exists, no agreement = no deployment. Plus GDPR notice + DPIA.
Austria	§96 ArbVG: control measures touching human dignity need works council consent (or individual consent where no council). Effectively the same veto as Germany.
Netherlands	Works Council (WOR Art. 27) instemming required for personnel-monitoring systems in companies with 50+ employees.
France	CSE consultation before deployment + CNIL expectations (charte informatique, proportionality, DPIA).
Norway	Dedicated email/monitoring regulation on top of GDPR; consultation + strict purpose rules.
South Korea (PIPA)	One of the strictest regimes researched: specific, informed consent is the practical basis; PIPC rejects boilerplate consent in employment contracts. Criminal penalties exist. Deploy only with a proper consent process.
Turkey (KVKK)	Advance written information mandatory; explicit consent is the safe basis per KVKK board practice on workplace monitoring.
China (PIPL)	Separate consent commonly required for employee personal information; localization concerns are neutralized by self-hosting (the ledger never leaves the operator's server). Verify with local counsel; state-secrecy adjacency for some sectors.
UAE (PDPL)	Current guidance treats employee monitoring as consent-based; obtain consent + notice.

🟡 Prerequisites (documented process, then enable)

Jurisdiction	Requirement
EU/EEA baseline (all 30 member/EEA states)	Art. 6(1)(f) legitimate-interest balancing test (documented), Art. 13 transparency notice to users before enabling, DPIA (systematic monitoring is a default DPIA trigger for most DPAs), storage limitation (covered: marks follow audit retention). Member states with works councils above are stricter.
United Kingdom	ICO "Monitoring workers" guidance (Oct 2023): transparency, necessity, proportionality, DPIA for high-risk monitoring.
Switzerland (home market)	ArGV 3 Art. 26 prohibits systems whose purpose is behavioural monitoring; systems for other legitimate purposes (security, confidentiality protection) are allowed if proportionate and known to staff. Framing matters: document this as a data-confidentiality measure, not performance surveillance; inform users; revDSG good-faith + proportionality. Deployable with that framing.
Canada	PIPEDA reasonable-purpose + openness; Ontario: written electronic-monitoring policy required at 25+ employees; Quebec (Law 25): privacy impact assessment + transparency, consent expectations higher.
Australia (NSW & ACT)	Workplace Surveillance Acts: written notice ≥14 days before computer surveillance starts (or a surveillance policy employees are aware of). Other states: general surveillance-devices acts, notice-based (Victoria has no dedicated workplace act).
Japan (APPI)	Specify the purpose in work rules / privacy notice as precisely as possible; proportionality; no consent needed for this design if properly noticed.
India (DPDP 2023)	Notice-based; employment "legitimate uses" likely cover it; rules still maturing — keep notice explicit.
Russia	Labour Code Art. 86: local act describing the processing + written acquaintance of employees; localization satisfied by self-hosting.

🟢 Enable + inform (notice is the requirement)

Jurisdiction	Notes
United States (federal)	No federal barrier for employer systems (ECPA business-purpose exception). State written-notice laws: Connecticut, Delaware, New York (NY also posting); California/Colorado/Texas privacy-act notices where applicable. Notice text = done.
Singapore (PDPA)	PDPC: monitoring of company systems permitted with clear notice; no explicit consent needed.
Brazil (LGPD)	Legitimate interest + transparency on company equipment/services; document the purpose.
South Africa (POPIA)	Notify + state purpose + proportionality; RICA relevant only for communication interception (not this).
Saudi Arabia (PDPL)	Lawful basis (legitimate interest/contract) + informing employees.
Israel, Mexico, Argentina, Kenya, Nigeria (NDPA) and most other GDPR-inspired regimes	Notice + purpose documentation under their data-protection acts; no researched blocker.
Countries without comprehensive data-protection law	Employment/contract law governs; notice remains best practice and is what our warning text instructs anyway.

Why the design keeps the map this green

Pseudonymous by construction — the marked file carries a random id, not personal data in the wild; the identity mapping never leaves the operator's server (also satisfies localization regimes: CN/RU/IN).
Off by default (GDPR Art. 25 privacy-by-default), enabling is a deliberate admin act behind a warning that names the operator's duties.
Not covert, not behavioural: purpose-limited to leak tracing of confidential files — the framing that keeps it inside Switzerland's ArGV 3 Art. 26 and outside "performance surveillance" everywhere.
Accountable use: the trace tool is admin-gated and every use writes its own audit event; marks expire with audit retention.
The docs ship the homework: the handbook gets this table (timestamped 2026-09-07) plus a model user-notice paragraph operators can adapt.

Sources (principal): ICO monitoring-workers guidance; EDÖB + SECO ArGV3 Art. 26 Wegleitung; BetrVG §87 / ArbVG §96 / WOR commentary; NSW Workplace Surveillance Act 2005 s10; Ontario ESA e-monitoring policy; Quebec Law 25 analyses; PIPC/PIPA and KVKK workplace-monitoring practice notes; PDPC Singapore employment guidance; LGPD & POPIA employment analyses; UAE/KSA PDPL employer guidance; US state notice statutes (CT/DE/NY).

## Legality research: per-jurisdiction deployability of download marking **Research snapshot: 2026-09-07.** This table reflects the law as researched on this date; jurisdictions change their rules — treat entries older than this date as a starting point, not a current answer. Engineering research for product design, **not legal advice**; operators must verify locally before enabling. **What is being assessed:** the feature as designed — **off by default**, embeds a **pseudonymous random id** (never a name; the id→person mapping stays on the operator's own server), disclosed to the operator with an explicit inform-your-users warning, admin-gated trace tool whose every use is itself audited, marks pruned with the audit log's retention. These properties are what keeps most of the world out of the red: nothing here is covert, content-revealing, or continuous behavioural surveillance — it is a per-download confidentiality measure. **Bottom line: no researched jurisdiction outright bans this design.** The buckets are: 🟢 enable + inform users, 🟡 concrete prerequisites first, 🔴 conditionally blocked until a third party agrees (works councils / consent regimes) — the closest thing to a "hard no" that exists, and it is procedural, not absolute. ### 🟡→🔴 Strongest prerequisites (deployment blocked until satisfied) | Jurisdiction | Requirement before enabling | |---|---| | **Germany** | §87(1)(6) BetrVG: works council **co-determination is mandatory** for any technical system capable of monitoring behaviour/performance. Where a Betriebsrat exists, no agreement = no deployment. Plus GDPR notice + DPIA. | | **Austria** | §96 ArbVG: control measures touching human dignity need **works council consent** (or individual consent where no council). Effectively the same veto as Germany. | | **Netherlands** | Works Council (WOR Art. 27) **instemming** required for personnel-monitoring systems in companies with 50+ employees. | | **France** | CSE consultation before deployment + CNIL expectations (charte informatique, proportionality, DPIA). | | **Norway** | Dedicated email/monitoring regulation on top of GDPR; consultation + strict purpose rules. | | **South Korea (PIPA)** | One of the strictest regimes researched: **specific, informed consent** is the practical basis; PIPC rejects boilerplate consent in employment contracts. Criminal penalties exist. Deploy only with a proper consent process. | | **Turkey (KVKK)** | Advance written information mandatory; explicit consent is the safe basis per KVKK board practice on workplace monitoring. | | **China (PIPL)** | Separate consent commonly required for employee personal information; localization concerns are neutralized by self-hosting (the ledger never leaves the operator's server). Verify with local counsel; state-secrecy adjacency for some sectors. | | **UAE (PDPL)** | Current guidance treats employee monitoring as consent-based; obtain consent + notice. | ### 🟡 Prerequisites (documented process, then enable) | Jurisdiction | Requirement | |---|---| | **EU/EEA baseline (all 30 member/EEA states)** | Art. 6(1)(f) legitimate-interest balancing test (documented), Art. 13 transparency notice to users **before** enabling, DPIA (systematic monitoring is a default DPIA trigger for most DPAs), storage limitation (covered: marks follow audit retention). Member states with works councils above are stricter. | | **United Kingdom** | ICO "Monitoring workers" guidance (Oct 2023): transparency, necessity, proportionality, DPIA for high-risk monitoring. | | **Switzerland (home market)** | ArGV 3 Art. 26 prohibits systems **whose purpose is behavioural monitoring**; systems for other legitimate purposes (security, confidentiality protection) are allowed if proportionate and known to staff. Framing matters: document this as a **data-confidentiality measure**, not performance surveillance; inform users; revDSG good-faith + proportionality. Deployable with that framing. | | **Canada** | PIPEDA reasonable-purpose + openness; **Ontario**: written electronic-monitoring policy required at 25+ employees; **Quebec (Law 25)**: privacy impact assessment + transparency, consent expectations higher. | | **Australia (NSW & ACT)** | Workplace Surveillance Acts: **written notice ≥14 days** before computer surveillance starts (or a surveillance policy employees are aware of). Other states: general surveillance-devices acts, notice-based (Victoria has no dedicated workplace act). | | **Japan (APPI)** | Specify the purpose in work rules / privacy notice as precisely as possible; proportionality; no consent needed for this design if properly noticed. | | **India (DPDP 2023)** | Notice-based; employment "legitimate uses" likely cover it; rules still maturing — keep notice explicit. | | **Russia** | Labour Code Art. 86: local act describing the processing + written acquaintance of employees; localization satisfied by self-hosting. | ### 🟢 Enable + inform (notice is the requirement) | Jurisdiction | Notes | |---|---| | **United States (federal)** | No federal barrier for employer systems (ECPA business-purpose exception). State written-notice laws: **Connecticut, Delaware, New York** (NY also posting); **California/Colorado/Texas** privacy-act notices where applicable. Notice text = done. | | **Singapore (PDPA)** | PDPC: monitoring of company systems permitted with clear notice; no explicit consent needed. | | **Brazil (LGPD)** | Legitimate interest + transparency on company equipment/services; document the purpose. | | **South Africa (POPIA)** | Notify + state purpose + proportionality; RICA relevant only for communication interception (not this). | | **Saudi Arabia (PDPL)** | Lawful basis (legitimate interest/contract) + informing employees. | | **Israel, Mexico, Argentina, Kenya, Nigeria (NDPA)** and most other GDPR-inspired regimes | Notice + purpose documentation under their data-protection acts; no researched blocker. | | **Countries without comprehensive data-protection law** | Employment/contract law governs; notice remains best practice and is what our warning text instructs anyway. | ### Why the design keeps the map this green 1. **Pseudonymous by construction** — the marked file carries a random id, not personal data in the wild; the identity mapping never leaves the operator's server (also satisfies localization regimes: CN/RU/IN). 2. **Off by default** (GDPR Art. 25 privacy-by-default), enabling is a deliberate admin act behind a warning that names the operator's duties. 3. **Not covert, not behavioural**: purpose-limited to leak tracing of confidential files — the framing that keeps it inside Switzerland's ArGV 3 Art. 26 and outside "performance surveillance" everywhere. 4. **Accountable use**: the trace tool is admin-gated and every use writes its own audit event; marks expire with audit retention. 5. **The docs ship the homework**: the handbook gets this table (timestamped 2026-09-07) plus a model user-notice paragraph operators can adapt. Sources (principal): ICO monitoring-workers guidance; EDÖB + SECO ArGV3 Art. 26 Wegleitung; BetrVG §87 / ArbVG §96 / WOR commentary; NSW Workplace Surveillance Act 2005 s10; Ontario ESA e-monitoring policy; Quebec Law 25 analyses; PIPC/PIPA and KVKK workplace-monitoring practice notes; PDPC Singapore employment guidance; LGPD & POPIA employment analyses; UAE/KSA PDPL employer guidance; US state notice statutes (CT/DE/NY).

Cordy referenced this issue from a commit

2026-09-07 00:21:14 +00:00

#423 red: download marking - marked files stay valid, tokens verify, ledger persists

Cordy referenced this issue from a commit

2026-09-07 00:23:48 +00:00

#423 one-shot: marks package + decorator + settings + trace endpoint (red then green)

forgejo-actions referenced this issue from a commit

2026-09-07 00:27:57 +00:00

#423: download marking - pseudonymous leak tracing, backend

Cordy referenced this issue from a commit

2026-09-07 00:35:15 +00:00

#423 one-shot: settings toggle + Trace tab frontend

forgejo-actions referenced this issue from a commit

2026-09-07 00:35:39 +00:00

#423: download marking - settings toggle + Trace tab

Cordy referenced this issue from a commit

2026-09-07 00:39:09 +00:00

#423 docs: leak-tracing handbook page (legality snapshot 2026-09-07)

Cordy referenced this issue from a commit

2026-09-07 00:39:32 +00:00

#423 docs: index row for leak-tracing.md

Cordy referenced this issue from a commit

2026-09-07 00:40:07 +00:00

#423 one-shot: CHANGELOG v0.6.137 + ARCHITECTURE marks decorator bullet

forgejo-actions referenced this issue from a commit

2026-09-07 00:40:18 +00:00

#423: CHANGELOG v0.6.137 + ARCHITECTURE marks-decorator entry

Cordy referenced this issue

2026-09-07 00:41:07 +00:00

#423: Download marking for leak tracing — pseudonymous marks, Trace tab, legality docs #444

Cordy referenced this issue from a commit

2026-09-07 00:43:28 +00:00

Merge pull request '#423: Download marking for leak tracing — pseudonymous marks, Trace tab, legality docs' (#444) from download-marks-423 into main

Cordy referenced this issue from a commit

2026-09-07 00:50:14 +00:00

one-shot: wiki Home entry for v0.6.137 (#423)

Cordy commented

2026-09-07 00:51:55 +00:00

Author

Owner

Shipped in v0.6.137 (PR #444), live on both dogfoods.

Decision record

What shipped. Runtime toggle Mark downloads for leak tracing (Settings → Audit, nested under Record access events, off by default, gated on the audit toggle at runtime — marks without an access trail are half-blind). Every authenticated download of PDF/docx/xlsx/pptx/PNG/JPEG carries a CAIRNMARK1.<cm-id>.<sig> token: random pseudonymous id + HMAC-SHA256 signature from a per-instance 32-byte secret, never a name. The id→download record (user, path, time, size) lives in an append-only marks ledger (monthly JSONL beside the audit log, pruned with audit.retainMonths). New Trace tab: drop a leaked copy → the one download it originates from, with a Query-prefill link for the full candidate list; distinct cards for pruned-ledger, foreign-signature, and no-mark results. Tracing is admin-gated and audits itself as mark-trace (new marks verb group in the registry, so the #433 tripwire covers it).

Design decisions, with reasons:

Segmented composite reader, not spooling. storage.Driver.Open returns io.ReadSeekCloser; every format's marked form is expressed as ≤3 segments (inner ranges + literals) — PDF trailing comment, zip EOCD comment, PNG tEXt before IEND, JPEG COM after SOI. O(1) memory, seek-preserving, so http.ServeContent and WebDAV range requests keep working. A container that does not validate is served untouched — marking must never corrupt a download.
No per-download audit verb. The ledger is the record of marked downloads; a download-marked audit event would duplicate every read event. Only the trace action gets a verb.
No content hash in v1. Hashing the marked stream would force a full double-read per download and fights the seek contract. The hit card claims "signature valid", not "byte-identical" (your point 3 is reflected in the caution text: identifies the download, not the leaker; evidence, not verdict).
Stat not wrapped. Listings report the original size; the marked transit copy differs by a few dozen bytes. Wrapping Stat would be a consistency trap (the stored object is unchanged). Sync-client caveat documented in the handbook.
Only authenticated reads marked. Anonymous/share-link reads have no person to map the id to.
Trace tab absent when off (your point 4) — unless historic marks remain traceable, so a past incident stays investigable after switch-off.
Mark lifetime = audit retention (your point 1): the id mapping and the access log are the same class of personal data and expire together, one knob.
Re-save strips the mark (your point 2): accepted as inherent to any content-preserving scheme; the Query trail is the documented fallback.

Legality (your point 5): full per-jurisdiction table (research snapshot 2026-09-07) in the comment above, now permanently in docs/handbook/leak-tracing.md together with a model user notice. No researched jurisdiction outright bans the design; DE/AT/NL-style works-council consent is the strongest gate, and the toggle carries the amber warning in all four languages. Default-off + pseudonymous id + non-covert purpose + audited trace is what keeps the map green.

Verified live: cairn_build_info{version="v0.6.137"} on files.c0rdyceps.ch; both dogfood pods rolled. Wiki Home has the release entry.

Shipped in **v0.6.137** (PR #444), live on both dogfoods. ## Decision record **What shipped.** Runtime toggle *Mark downloads for leak tracing* (Settings → Audit, nested under *Record access events*, off by default, gated on the audit toggle at runtime — marks without an access trail are half-blind). Every authenticated download of PDF/docx/xlsx/pptx/PNG/JPEG carries a `CAIRNMARK1.<cm-id>.<sig>` token: random pseudonymous id + HMAC-SHA256 signature from a per-instance 32-byte secret, never a name. The id→download record (user, path, time, size) lives in an append-only marks ledger (monthly JSONL beside the audit log, pruned with `audit.retainMonths`). New Trace tab: drop a leaked copy → the one download it originates from, with a Query-prefill link for the full candidate list; distinct cards for pruned-ledger, foreign-signature, and no-mark results. Tracing is admin-gated and audits itself as `mark-trace` (new `marks` verb group in the registry, so the #433 tripwire covers it). **Design decisions, with reasons:** 1. **Segmented composite reader, not spooling.** `storage.Driver.Open` returns `io.ReadSeekCloser`; every format's marked form is expressed as ≤3 segments (inner ranges + literals) — PDF trailing comment, zip EOCD comment, PNG tEXt before IEND, JPEG COM after SOI. O(1) memory, seek-preserving, so `http.ServeContent` and WebDAV range requests keep working. A container that does not validate is served **untouched** — marking must never corrupt a download. 2. **No per-download audit verb.** The ledger *is* the record of marked downloads; a `download-marked` audit event would duplicate every read event. Only the trace action gets a verb. 3. **No content hash in v1.** Hashing the marked stream would force a full double-read per download and fights the seek contract. The hit card claims "signature valid", not "byte-identical" (your point 3 is reflected in the caution text: identifies the download, not the leaker; evidence, not verdict). 4. **`Stat` not wrapped.** Listings report the original size; the marked transit copy differs by a few dozen bytes. Wrapping Stat would be a consistency trap (the stored object is unchanged). Sync-client caveat documented in the handbook. 5. **Only authenticated reads marked.** Anonymous/share-link reads have no person to map the id to. 6. **Trace tab absent when off** (your point 4) — unless historic marks remain traceable, so a past incident stays investigable after switch-off. 7. **Mark lifetime = audit retention** (your point 1): the id mapping and the access log are the same class of personal data and expire together, one knob. 8. **Re-save strips the mark** (your point 2): accepted as inherent to any content-preserving scheme; the Query trail is the documented fallback. **Legality** (your point 5): full per-jurisdiction table (research snapshot **2026-09-07**) in the comment above, now permanently in `docs/handbook/leak-tracing.md` together with a model user notice. No researched jurisdiction outright bans the design; DE/AT/NL-style works-council consent is the strongest gate, and the toggle carries the amber warning in all four languages. Default-off + pseudonymous id + non-covert purpose + audited trace is what keeps the map green. Verified live: `cairn_build_info{version="v0.6.137"}` on files.c0rdyceps.ch; both dogfood pods rolled. Wiki Home has the release entry.

Cordy closed this issue

2026-09-07 00:51:58 +00:00

Cordy referenced this issue

2026-09-07 01:12:29 +00:00

Docs run 2: EULA (draft v0.1) + consistency vs v0.6.132–137 #445

Cordy referenced this issue from a commit

2026-09-07 01:24:56 +00:00

#423 one-shot: trace drop-zone surface + live Trace tab after save

forgejo-actions referenced this issue from a commit

2026-09-07 01:25:07 +00:00

#423: drop zone gets a surface card; Trace tab appears on save

Cordy referenced this issue