Guests on Gramps Web API could access private sub-object data attached to public genealogy records. Before the fix, list endpoints like GET /api/people/, GET /api/places/, and GET /api/events/ leaked details such as private alternate names, full addresses, and handles to private notes, citations, or media. Top-level private objects stayed hidden—only sub-data on public ones escaped.
This stems from a flaw in Gramps core’s PrivateProxyDb. Its iter_*() methods filter out private top-level objects but skip sanitizing the rest. They yield raw objects with private sub-references intact. Gramps Web API’s ModifiedPrivateProxyDb, used for non-admins, inherited this without changes. The same bug hits Gramps desktop: reports and exports via PrivateProxyDb might include private sub-data.
Affected Versions and Setup
All Gramps Web API versions before the patch qualify as vulnerable. The issue activates only if you mark sub-objects private in Gramps desktop—think alternate names (first/surname), addresses (street/city), notes, citations, media refs, or event refs. Gramps Web’s UI lacks toggles for this; users set flags in desktop, then sync or import to web.
Gramps is open-source genealogy software tracking family trees: people, places, events, sources. The web API enables sharing trees online, with roles like Guest for read-only access. Privacy flags hide sensitive data, crucial for living relatives or old scandals. Without them, public trees risk doxxing addresses or names.
Real-World Impact
A Guest hits a list endpoint on a public person and pulls private alternate names or street addresses verbatim. For places or events, they get handles to private notes/media—revealing existence but not content, since fetching by handle blocks Guests. No full private object dump, but enough to stitch sensitive profiles.
Severity lands at medium: niche trigger (desktop-marked subs), no RCE or mass exposure. Still, sloppy. Genealogy sites hold goldmines—SSNs slip in notes, photos tag locations. Public trees with private subs fool users into thinking data’s locked. A Guest scrapes lists? Boom, privacy stripped. Desktop exports compound it: share a PDF report, private addresses print.
Context matters. Gramps users often collaborate families or publish histories. 2023 stats? Gramps claims thousands of active trees; web API grows for hosted services. Similar bugs hit FamilySearch or Ancestry APIs historically—leaky proxies common in DB wrappers. Why care? Regulations like GDPR flag personal data; one leak invites fines or family drama.
Fix and What to Do
Developers overrode iter_*() in ModifiedPrivateProxyDb: now checks obj.get_privacy() post-load, calls sanitize_*() before yield. Matches get_*_from_handle() behavior. Efficient—no extra fetches.
Upgrade immediately. Verify via changelog or commit. Audit trees: scan for private subs in desktop before web sync. Test: as Guest, query lists—expect no privates. Skeptical note: core Gramps needs PrivateProxyDb fix too, or desktop lingers vulnerable.
Broader lesson: Proxy DBs demand consistent sanitization. Genealogy apps prioritize granular privacy; one iter_*() oversight undoes it. Users, lock subs private only if needed—overkill bloats trees. Providers, expose web privacy UI. This patch closes the gap, but vigilance beats fixes.
