Social Backup

Overview

Trusted contacts may hold encrypted fragments, secret shares, recovery codes, or instructions. A threshold of participants can help reconstruct a secret or authorize a new signer. The design aims to reduce dependence on one physical backup.

Human relationships and availability change. Participants can collude, lose information, misunderstand duties, become unreachable, or be targeted through coercion and phishing. Informal splitting of seed words may leak information or produce a backup that is difficult to reconstruct reliably.

Users should use a defined scheme, choose independent participants, explain responsibilities, and record threshold and replacement rules. Shares need secure storage and discreet identification. Periodic checks should confirm availability without combining secrets. Recovery should include owner verification, notification, delay where appropriate, and post-use rotation.

Evidence for Social Backup should preserve incident time, affected identifiers, last known state, claimant and approver checks, backup or share version, actions performed, credentials revoked, assets verified, discrepancies found, and final owner acceptance. For Social Backup, sensitive recovery material must not appear in the incident record.

Social Backup differs from ordinary retry or customer support because it restores authority after a control failure. For example, reinstalling an application is not successful recovery until the correct accounts, networks, balances, policies, and transaction history are reproduced and compromised authority can no longer act.

A controlled Social Backup process moves through detection, containment, claimant verification, approval, restoration, validation, credential or guardian replacement, reconciliation, and closure. For Social Backup, emergency access should be time-limited and should not silently weaken the authorization policy used during normal operation.