Parental controls: a short activity summary — counts only, never content #14

New Issue

2026-09-04T18:42:01Z

paulhitt commented

2026-09-04 18:42:01 +00:00

(Migrated from gitlab.com)

A supervising parent can currently see the gates they set and nothing about what is happening. The three existing switches — contacts, stories, calls — are all preventative; there is no way to notice that something changed.

What to show

Counts, behind the existing PIN. Never content.

Messages sent and received, over a chosen window (today / this week).
Number of conversations, and how many are with people added recently.
Groups belonged to, and how many members each has.
Stories posted, and stories viewed.
Calls made and received, and total time.
Contact requests received, accepted and declined.

The line this must not cross, stated up front

🔴 Counts, not content, and the difference is the entire justification. "Fourteen messages to three people today" tells a parent that something changed. "Here is what your child said" is reading their mail, and a product that ships the second under the banner of the first has built surveillance and called it safety. There is no version of this that shows message text, story pictures, contact names or group names.

⚠️ Names are content. "Three groups" is a count; "in a group called [name]" is not, and it identifies other people's children who never agreed to any of this. Same for contact handles. This is the specific place where a well-meaning implementation slides across the line, so it is worth being explicit: the summary names nothing and nobody.

⚠️ The child must be able to see exactly what is shared. A supervised device that reports on somebody without their knowledge teaches them the app is not to be trusted — and the practical consequence is that they move to one that reports nothing at all, which is worse for them. The same screen, readable without the PIN, showing the same numbers.

What is genuinely hard

🔴 The counts have to come from the device, and the device is the thing being counted. A child who can turn the summary off, or clear the transcript, changes the numbers. Options, none free:

Count in the vault as things happen, sealed like everything else. Survives clearing a thread if the counter is separate from the transcript — which it should be, and that is a design decision worth stating rather than inheriting.
Derive from the transcript at read time. Simpler, and "delete for me" then rewrites history.

(1) is right, and it means the counters are their own record with their own retention.

⚠️ A count of received messages leaks something about the sender, weakly. Nobody outside the device learns anything — but a parent seeing "40 received today" and a child with one friend has effectively learned about that friend's activity. Worth naming; probably acceptable; not worth hiding.

Where it goes

Android: app/.../ParentalControls.kt for the gate, plus counters in Vault and increments in Session.
iOS: Sources/App/ParentalControls.swift, the equivalent in E2EInbox.

⚠️ Both clients or neither, same as android#13 / ios#63 — a summary on one platform is one a child avoids by using the other.

Relationship to the timed-content gate

Filed alongside android#13 / ios#63, which gates disappearing messages. They belong together: a summary is worth much less if the thing being summarised deletes itself, and that issue's out-of-scope note deliberately left this to be argued on its own terms. It has been.

A supervising parent can currently see the gates they set and nothing about what is happening. The three existing switches — contacts, stories, calls — are all preventative; there is no way to notice that something changed. ## What to show **Counts, behind the existing PIN. Never content.** - Messages sent and received, over a chosen window (today / this week). - Number of conversations, and how many are with people added recently. - Groups belonged to, and how many members each has. - Stories posted, and stories viewed. - Calls made and received, and total time. - Contact requests received, accepted and declined. ## The line this must not cross, stated up front 🔴 **Counts, not content, and the difference is the entire justification.** "Fourteen messages to three people today" tells a parent that something changed. "Here is what your child said" is reading their mail, and a product that ships the second under the banner of the first has built surveillance and called it safety. There is no version of this that shows message text, story pictures, contact names or group names. ⚠️ **Names are content.** "Three groups" is a count; "in a group called *[name]*" is not, and it identifies other people's children who never agreed to any of this. Same for contact handles. This is the specific place where a well-meaning implementation slides across the line, so it is worth being explicit: the summary names nothing and nobody. ⚠️ **The child must be able to see exactly what is shared.** A supervised device that reports on somebody without their knowledge teaches them the app is not to be trusted — and the practical consequence is that they move to one that reports nothing at all, which is worse for them. The same screen, readable without the PIN, showing the same numbers. ## What is genuinely hard 🔴 **The counts have to come from the device, and the device is the thing being counted.** A child who can turn the summary off, or clear the transcript, changes the numbers. Options, none free: 1. **Count in the vault as things happen**, sealed like everything else. Survives clearing a thread if the counter is separate from the transcript — which it should be, and that is a design decision worth stating rather than inheriting. 2. **Derive from the transcript at read time.** Simpler, and "delete for me" then rewrites history. (1) is right, and it means the counters are their own record with their own retention. ⚠️ **A count of received messages leaks something about the sender**, weakly. Nobody outside the device learns anything — but a parent seeing "40 received today" and a child with one friend has effectively learned about that friend's activity. Worth naming; probably acceptable; not worth hiding. ## Where it goes - Android: `app/.../ParentalControls.kt` for the gate, plus counters in `Vault` and increments in `Session`. - iOS: `Sources/App/ParentalControls.swift`, the equivalent in `E2EInbox`. ⚠️ Both clients or neither, same as android#13 / ios#63 — a summary on one platform is one a child avoids by using the other. ## Relationship to the timed-content gate Filed alongside android#13 / ios#63, which gates disappearing messages. They belong together: a summary is worth much less if the thing being summarised deletes itself, and that issue's out-of-scope note deliberately left this to be argued on its own terms. It has been.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-android#14