Add the personal-data catalog and the check that keeps it true #83

Merged

jcoffey-dev merged 1 commits from feature/privacy-catalog into main

2026-09-28 14:32:24 +00:00

jcoffey-dev commented

2026-09-28 13:54:39 +00:00

Owner

Phase 2 of docs/spec/features/personal-data-catalog.md.

resources/privacy/catalog.toml: all 316 schema objects, the 12 inbuxa objects, and 20 non-object sources, classified.
tools/fork/privacy-check.py in the fork-checks job: unclassified objects, typed-sensitive properties left to a default, stale objects/properties/settings/code paths, and words outside the vocabulary all fail.
strip.py: new "Unclassified in the privacy catalog" report section.
13 unit tests in tools/fork/tests, also run in CI.

The catalog isn't read by the server yet; that is Phase 3.

Phase 2 of `docs/spec/features/personal-data-catalog.md`. - `resources/privacy/catalog.toml`: all 316 schema objects, the 12 inbuxa objects, and 20 non-object sources, classified. - `tools/fork/privacy-check.py` in the fork-checks job: unclassified objects, typed-sensitive properties left to a default, stale objects/properties/settings/code paths, and words outside the vocabulary all fail. - `strip.py`: new "Unclassified in the privacy catalog" report section. - 13 unit tests in `tools/fork/tests`, also run in CI. The catalog isn't read by the server yet; that is Phase 3.

jcoffey-dev added 1 commit 2026-09-28 13:54:39 +00:00

Add the personal-data catalog and the check that keeps it true

ci / fork-checks (pull_request) Successful in 52s

Details

ci / build (pull_request) Successful in 37m38s

Details

a8dde68800

Phase 2 of the personal-data catalog spec.

resources/privacy/catalog.toml classifies every object in the schema
(316) and inbuxa's own JMAP objects (12): each property that can hold
personal data, with its categories, and for objects that hold any,
whose data it is, where it lives, its scope and what bounds its
retention (a named setting where there is one). Twenty sources that
are no object -- the log file, exporters, webhooks, spam lookups, the
Explain cache, relays and hooks, push, legacy-use records -- carry the
same facts plus the settings that turn them on, whether the data
leaves the host, and the code that writes it. Classifications of
objects that hold data about people are from the spec's source map;
the rest are typed from the schema alone (address, IP, secret).

tools/fork/privacy-check.py fails CI when an object or inbuxa object
has no entry, when a property the schema types as an address, IP or
secret is left to its object's default, when an entry names an
object, property, setting or code path that is gone, or when it uses
a word outside the catalog's vocabulary. --unlisted prints starting
entries. strip.py's report gains "Unclassified in the privacy
catalog": objects and fields new in an import and not classified,
informational like the Enterprise flags.

Tested: 13 unit tests (tools/fork/tests): the check passes on this
tree; fails on an unclassified object, an address hidden behind a
default, a secret in a set or object reference, stale properties,
objects, settings and code paths, an unlisted inbuxa object and a
word outside the vocabulary; --unlisted's entries; and the strip
report on a synthetic import. The check and the tests run in the
fork-checks job.

jcoffey-dev merged commit 18b28fad27 into main

2026-09-28 14:32:24 +00:00

jcoffey-dev deleted branch feature/privacy-catalog

2026-09-28 14:32:24 +00:00

jcoffey-dev referenced this issue from a commit

2026-09-28 15:19:28 +00:00

Merge main into merge/upstream-v0.16.24

jcoffey-dev referenced this issue from a commit

2026-09-28 19:22:38 +00:00

Release 2026.9.28.4

jcoffey-dev referenced this pull request

2026-09-28 19:22:39 +00:00