Protection must not take the form of exclusion

What it is

Protection by exclusion is achieving safety by keeping at-risk populations out: demanding video face verification because older users might be scammed, disabling account features for users with disabilities because of misuse risk, blocking an entire age band from a service because minors might be harmed. It reduces risk to zero by reducing service to zero — what the "protected" lose is access they were entitled to. Legitimate protection changes the shape of the service (safe modes, simplified flows, reinforced confirmation); it does not change who is allowed in.

Why it happens

Exclusion becomes the default because it transfers risk from the platform to the user: refusing service carries far less legal and reputational exposure than an incident after admission, so "keep them out" is the legally optimal move. But the costs of exclusion are externalized and invisible: people kept out do not complain (they never got in), generate no data, and appear in no metric — the price shows as zero on the dashboard. The excluded also bear the cost of substitute routes: people barred from official transfers move to less safe channels; minors kept off mainstream platforms spend time in environments with no age guardrails at all — under the banner of protection, risk merely relocates somewhere harder to reach. Verification-based exclusion adds a technical gate: the groups most needing inclusion (no documents, no stable address, low digital literacy) are the least able to pass the verification itself.

Where it stops holding

Exclusion is not always illegitimate: statutory age limits, financial compliance requirements, and explicit professional contraindications (medical device prohibitions) are mandatory exclusions; the problem is only smuggling "we could build a safer mode" into "we must block." The test is proportionality: does an equally effective non-exclusionary alternative exist, and is the inclusion cost for the residual risk commensurate with the benefit? "A safe mode is technically hard" is usually a prioritization statement, not an impossibility.

Applying it

• Route every "restrict this population" decision through an alternatives review: list at least two non-exclusionary options (safe mode, reinforced confirmation, companion-account mechanisms) with costs, and justify in writing why none is viable before an exclusion passes.
• Design degraded-but-useful paths for restricted high-risk populations: a limited mode that still delivers value, not a single line reading "this feature is unavailable for your user group."
• Pre-screen verification-based exclusion against accessibility standards: if the verification flow itself cannot be completed by users without documents, with low digital literacy, or on assistive technology, it is exclusionary design.
• Verify: track appeals and substitute-channel usage among restricted populations; when appeals cluster on "I want in but am blocked" rather than "I shouldn't be blocked," the restriction's legitimacy needs re-argument.

Related

• Same group: P4.04.6 Restraint applied to everyone beats differential treatment after identification · P4.04.5 Judging vulnerability itself requires extra sensitive data
• Adjacent: J1 Accessibility criteria and conformance · P4.05.3 Age verification itself involves a privacy trade-off
• Search terms: protection by exclusion · digital exclusion · inclusive design