Consensual Accountability vs. Surveillance: Where the Line Actually Is

Consensual accountability means one adult chooses, in a calm moment, to let a specific person see protection health and approve sensitive changes - and both of them know exactly what is and is not visible. Surveillance is watching someone's activity. A gambling blocker can do the first without doing the second.

The distinction is easy to state and easy to lose. Both arrangements involve one person knowing something about another, both are often set up with genuine care, and both can be described in the same warm language. So the line cannot be drawn by intent. It has to be drawn by properties of the arrangement that a reader can check.

Five tests

Apply these to any product or arrangement, including this one.

• Consent in a calm moment. The person being protected chose this, before a crisis, not during one. Consent produced by an ultimatum or extracted mid-argument is a different thing wearing the same word.
• Scope limited to protection events. What travels is whether protection is on, what was explicitly requested, and what changed - never browsing, never a record of an ordinary day.
• Symmetry. The person being protected knows exactly what the other one can see. If one side has to guess, the arrangement is not symmetric, whatever it is called.
• Exit rules agreed in advance. Both people know what asking to stop looks like, how long it takes, and what happens if one of them is unavailable or the relationship ends.
• A bright line to stalkerware. The Coalition Against Stalkerware defines stalkerware as software that lets a remote user monitor another user's device “without that user's consent and without explicit, persistent notification to that user.” Both halves matter, and the coalition adds that merely requiring physical access to the device, unlocking it, or logging in with the username and password does not establish consent.

The fifth test is the one people skip. In the coalition's terms, physical access or a successful sign-in does not establish consent, and general awareness that “something” is on the computer is not explicit, persistent notification of what is being sent. The arrangement needs both consent and that continuing notice.

What an accountability partner actually needs

Less than people assume. To play the role at all, the second person needs to know whether protection is working, whether something was asked of them, and whether something changed. That is the whole functional requirement.

In GuardianBlock that is four things: whether protection is healthy, offline, or needs attention; the explicit requests you chose to send; tamper and accountability alerts if protection is paused, removed, or interfered with; and whether your protection is current. Alerts follow protection, not behaviour, and an alert never approves anything on its own. The full list of states and what each one tells your keyholder is on the accountability alerts page.

Notice what is missing from that list: any information about what the person did. A partner can know that protection went offline at 2 a.m. without knowing anything at all about the evening. That gap is not an oversight. It is the design.

What they must never get

The list on the other side has to be sealed and published, not left to a privacy policy's discretion. In GuardianBlock a partner never sees your browsing history or the sites you visit, your search queries, keystrokes, messages, or screenshots, a feed of everywhere you go - there is no activity log to scroll - or anything beyond the explicit requests and health signals you opted into. The same list is published for both sides on the privacy page for partners and protected adults.

“

Accountability answers a question you agreed to be asked. Surveillance asks questions you never agreed to.

A published never-list does something a promise cannot: it lets the person being protected check the shape of the arrangement without trusting anyone's intentions. It also constrains the product. Once a list like that is public, adding the prohibited data later is not a feature decision, it is a broken promise.

Why this line is worth drawing carefully

A 2025 article in Social Media + Society notes earlier studies estimating that roughly a third of U.S. adults have looked through a partner's phone without that person's knowledge, and describes digital monitoring as a soft or casual surveillance practice. In its own survey of 378 Black and Latinx women living in the United States, past experiences of digital abuse and of offline psychological abuse predicted monitoring behaviour. That is an association in a specific survey sample, not a claim about any particular relationship or about adults generally.

That is the context a category like this one lives in. When checking a partner's device is ordinary, a product built on watching does not feel like watching to the people inside it, and the euphemisms come easily: keeping an eye out, staying involved, just being able to check. The tests above exist because the feeling of an arrangement is not evidence about the arrangement.

The law already treats the far end of this seriously. Canada's Criminal Code lists, among the conduct that can constitute criminal harassment, repeatedly following a person and “besetting or watching” the place where they live or work. Nothing here is legal advice, and none of it is a statement about anyone's situation. It is a reminder that watching a person is a category with weight, and that a product should be able to say plainly which side of it the product is on.

Both people get to say no

An arrangement one person cannot decline is not consent-based, and neither is one the other person cannot leave. The keyholder role is a real ask, and it is allowed to be declined - before it starts or later. What that role involves, and what it is not, is on the page for accountability partners.

The other direction matters just as much, because the failure mode of a two-person design is one person going quiet. In GuardianBlock, replacing a keyholder with their approval takes effect 24 hours after the new keyholder accepts and sets up multi-factor authentication. Without their cooperation, a seven-day identity-verified review applies, and documented safety, abuse, account-loss, or wrong-person cases can be expedited by support. A keyholder's refusal or silence never becomes an indefinite lock. The whole sequence is on the keyholder approval page.

The partner's own side deserves saying out loud too. Support for the people alongside someone who gambles exists and has been studied: a 2022 systematic review in the Journal of Behavioral Addictions identified nine interventions for concerned significant others and found that no specific intervention appeared more beneficial than the others. Holding a key is not a treatment role, and nobody should be asked to make it one.

How GuardianBlock draws the line

The protected adult sets it up and chooses the keyholder. The keyholder approves or denies specific changes from their own account with multi-factor authentication, and there is no password for them to hold and nothing for them to type on the protected adult's PC. What they see is protection health and the requests that were sent to them. What they never see is published in a list that does not move. Approval alone changes nothing: a 24-hour cooling-off period runs before any authorization exists, and the exit path is documented in advance rather than negotiated in the moment.

That is one arrangement among several defensible ones. A reader who prefers a different lock, or no second person at all, is answering the same five questions with different answers, and that is fine. What is not fine is a product that cannot answer them - or answers them differently depending on who is asking.