Trends privacy
opt-in counts, never one person.
The home screen can show which kinds of scams people checked in the last 7 days. The numbers come only from installs that opted in, and the rules below make sure no single person's check can be picked out.
01Opt-in, off by default
Sharing is off until the person turns on "Help others: share anonymous scam-type counts" in the History settings. The app explains: "Only a count per scam type is added, never what you checked. Turning it off stops new counts; counts already added stay, as they cannot be linked to you." Without a connected server the switch is off and disabled.
A check is counted only when its install had sharing on before the check started and still has it on when the check finishes. Checks with no scam type are not counted.
02What the app is shown
- Only whole closed days (UTC), the last 7 up to yesterday, worked out once a day.
- At least 5 different installs per day and type: a (day, scam type) counts only when at least 5 different installs checked that type on that day. A day on which one install checked a type never changes that type's count.
- Types below that are suppressed: a type with no such day is listed without a number.
- Rounded down to 5: every count shown is rounded down to a multiple of 5, which also blunts anyone who keeps a type above the threshold with installs of their own.
- A minimum sample: nothing is shown until the rounded counts add up to your minimum (console, Trends, Minimum sample: default 50 checks in 7 days, at least 20) and the busiest day of the window had enough different installs (Minimum installs: default 10, at least 5).
Until then the home screen says "Trends appear when there is enough data." Different installs cannot be matched across days, so the count of installs in a window is a lower bound: these rules can hide trends that would be fine to show, never the other way round.
03How installs are counted without keeping them
When a check finishes, the database adds 1 to the counter of (day, scam type). To know how many different installs took part, it also stores a keyed hash (HMAC) of the install id under a random salt of that day, once per (day, scam type). When the day is closed, those rows become two numbers per scam type (checks and different installs), and the hashes and the salt are deleted, so no install id, and no hash that could be recomputed, outlives the day. Deleted bytes are overwritten on disk too, and the tables keep no insertion order.
The trend counters are updated by the database itself when a check finishes, using functions the server registers when it opens the database. Changing check results with the sqlite3 command-line tool while those functions are missing fails; let the server make changes.
04In your privacy policy
Say that trend sharing is opt-in, what is counted (a scam type per day), and that counts already added stay after someone turns sharing off, because they cannot be linked to anyone.