Signal removal (#68) introduces a 30-day retention window: when a user removes their own signal, the document moves to removedSignals and is erased by a scheduled purge after REMOVED_RETENTION_DAYS = 30. The privacy policy has to say so before that ships.
This is not a code change
lib/src/widgets/privacy_policy_page.dart is a WebView onto https://www.helpapaw.org/privacypolicy. The text lives on the website, not in this repo, so nobody can find or fix this by grepping the codebase — which is why it is an issue rather than a TODO.
Why it matters
The design deliberately makes a user-initiated Delete recoverable rather than immediate. That is defensible — GDPR Art. 17 is a right to obtain erasure on request, not a requirement that a Delete button purge irreversibly the instant it is tapped, and a bounded "Recently deleted" window is an ordinary pattern — but only if three things hold:
- the window is disclosed,
- a purge actually runs (a retention window with no purge is just indefinite retention),
- there is a route to prompt erasure.
Points 2 and 3 are built: purgeRemovedSignals runs weekly, and "Delete permanently" plus the existing deleteAccount are the immediate paths. Point 1 is the outstanding one, and without it the other two do not add up to a defence.
Master spec §A2 already lists a data-retention policy among the needed-but-unwritten documents; this is the first concrete thing that requires it.
What the text needs to cover
- A signal a user removes is retained for up to 30 days, during which they can restore it from My Signals, and is then permanently deleted along with its photos, comments and history.
- The stored copy retains what the signal contained, including the contact phone number, for that window.
- Deleting an account erases removed signals outright —
deleteAccount purges them rather than anonymising them the way it anonymises live signals.
- "Delete permanently" is available at any point in the window for immediate erasure.
Keep it in step with the code
REMOVED_RETENTION_DAYS (functions/src/removeSignal.ts) is the enforcement; RemovedSignal.retentionDays (Dart) only draws the label, and test/removal_retention_guard_test.dart fails the build if the two drift. The website is a third copy with no such guard — if the window is ever changed, the policy text has to be changed with it, by hand.
Not legal advice
Written from the code, not from counsel. Worth having someone qualified review the wording, particularly for a Bulgaria/EU-facing service.
Signal removal (#68) introduces a 30-day retention window: when a user removes their own signal, the document moves to
removedSignalsand is erased by a scheduled purge afterREMOVED_RETENTION_DAYS = 30. The privacy policy has to say so before that ships.This is not a code change
lib/src/widgets/privacy_policy_page.dartis a WebView onto https://www.helpapaw.org/privacypolicy. The text lives on the website, not in this repo, so nobody can find or fix this by grepping the codebase — which is why it is an issue rather than a TODO.Why it matters
The design deliberately makes a user-initiated Delete recoverable rather than immediate. That is defensible — GDPR Art. 17 is a right to obtain erasure on request, not a requirement that a Delete button purge irreversibly the instant it is tapped, and a bounded "Recently deleted" window is an ordinary pattern — but only if three things hold:
Points 2 and 3 are built:
purgeRemovedSignalsruns weekly, and "Delete permanently" plus the existingdeleteAccountare the immediate paths. Point 1 is the outstanding one, and without it the other two do not add up to a defence.Master spec §A2 already lists a data-retention policy among the needed-but-unwritten documents; this is the first concrete thing that requires it.
What the text needs to cover
deleteAccountpurges them rather than anonymising them the way it anonymises live signals.Keep it in step with the code
REMOVED_RETENTION_DAYS(functions/src/removeSignal.ts) is the enforcement;RemovedSignal.retentionDays(Dart) only draws the label, andtest/removal_retention_guard_test.dartfails the build if the two drift. The website is a third copy with no such guard — if the window is ever changed, the policy text has to be changed with it, by hand.Not legal advice
Written from the code, not from counsel. Worth having someone qualified review the wording, particularly for a Bulgaria/EU-facing service.