Accountability partner
Haven Pro Plus.
Someone the user trusts is told when the protection is weakened. Not what they browse, not where they go — only that a guard was lowered.
Find it at Guard → Accountability partner.
Double opt-in#
A partner is never added unilaterally. Pairing takes two steps and requires the partner's own consent:
- The invitation. The user enters the partner's name and email address. Haven composes an invitation containing a six-character pairing code and hands it to the user's own email app to send.
- The confirmation. The partner reads the code back to the user, who types it into Haven. Only then does the partner become active.
Until the partner confirms, no event emails are produced at all. Being told about someone else's protection changes is something you agree to first.
The pairing code is generated with a cryptographically secure random source and uses an alphabet with the ambiguous characters removed, so it is easy to read aloud or type back without 0/O or 1/I confusion.
The user can remove the partner at any time.
What the partner is told#
| Event | Meaning |
|---|---|
| Disable requested | A cooldown to switch protection off has started |
| Protection disabled | The cooldown ran out and protection was switched off |
| Protection enabled | Protection is on again, including a cancelled disable request |
| PIN removed | The settings lock was taken off |
| Delete protection disabled | The device-admin uninstall protection was deactivated |
| Repeated proceed | A guarded money app was entered through the pause repeatedly |
| Learned block released | A strongly-evidenced automatic gambling block was overturned |
Each message says what happened and when. It carries no browsing data, no domain names, no app names, and no financial figures.
Note the presence of Protection enabled in that list. The partner sees the good news too; the point is a truthful picture, not a report card of failures.
How the messages are delivered#
Through the user's own email app. Haven composes the message and opens the device's mail chooser with the recipient, subject and body pre-filled.
That means:
- the message is sent from the user's own email account;
- it never touches Haven's servers;
- the partner's email address is stored only on the device and is never uploaded;
- the user sees every message before it goes out, which is why this is honest friction and not surveillance.
Events raised from a screen that closes immediately — the financial pause, for instance — are queued and offered the next time Haven is in the foreground, rather than throwing a mail chooser over the app the user was opening.
Two consequences follow from this design, and Haven does not pretend otherwise:
- A user could decline to send a composed message. Deactivating delete protection from system settings likewise cannot compose an email from the background.
- Both cases are still recorded in the local event history, so the gap is visible rather than silent.
The event history#
Every event is written to an on-device log — including when there is no partner at all — so the in-app history is complete and the user can always see their own pattern.
The history records what happened, when, and whether a notification was produced. It stays on the device.
Why it is built this way#
The obvious implementation is a server that emails a partner directly. It would be more reliable and it would close the gaps above.
It was rejected because it would mean Haven's servers holding a list of the people its users are accountable to, plus a stream of events about each user's relapse risk. That is exactly the data an app in this category should not be accumulating. Reliability was traded for the user keeping their own data — see Data handling.