ana/trust-issues
1
0
Fork 0
Code Pull Requests Actions Packages Projects Releases Activity

Publish the first trust story collection
validate / validate (push) Successful in 23s
Details

Browse Source
This commit is contained in:
Compleet
2026-07-14 13:58:14 +01:00
parent e7e690a8ed
commit eaf9a614d9
39 changed files with 1815 additions and 327 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/components/FrontCard.astro
+13 -5
View File
@@ -90,7 +90,7 @@ const formattedDate = date
.card-link {
display: flex;
width: 100%;
height: 100%;
min-height: 100%;
flex-direction: column;
color: inherit;
text-decoration: none;
@@ -98,13 +98,20 @@ const formattedDate = date
}
figure {
min-height: 210px;
flex: 1 1 52%;
height: 250px;
min-height: 0;
flex: 0 0 auto;
margin: 0;
overflow: hidden;
background: var(--blue-soft);
}
.size-side figure,
.size-standard figure,
.size-compact figure {
height: 210px;
}
img {
width: 100%;
height: 100%;
@@ -118,7 +125,7 @@ const formattedDate = date
.card-body {
display: flex;
min-height: 100%;
min-height: 0;
flex: 1 1 auto;
flex-direction: column;
padding: clamp(1.25rem, 2.6vw, 2rem);
@@ -273,7 +280,8 @@ const formattedDate = date
}
figure {
min-height: 220px;
height: 220px;
min-height: 0;
}
}
</style>
src/components/StoryCard.astro
+98 -172
View File
@@ -1,209 +1,135 @@
---
import type { CollectionEntry } from 'astro:content';
import { formatDate } from '../lib/content';
interface Props {
entry: CollectionEntry<'stories'>;
featured?: boolean;
index?: number;
}
const { entry, featured = false } = Astro.props;
const pattern = entry.data.trustPattern;
const status = entry.data.status;
const nodes = pattern
? ['CLAIM', 'TRUSTED', 'FAILURE']
: ['PERSON', 'SYSTEM', 'CONSEQUENCE'];
const { entry, index = 0 } = Astro.props;
const accentCycle = ['blue', 'soft', 'ink', 'amend', 'paper'];
const accent = entry.data.frontTone ?? accentCycle[index % accentCycle.length];
---
<article class:list={['story-card', { featured }] }>
<div class="visual" data-status={status}>
<div class="chain" aria-hidden="true">
<span>{nodes[0]}</span>
<i></i>
<span>{nodes[1]}</span>
<i class="fail-link"></i>
<span>{nodes[2]}</span>
<article class:list={['story-card', `accent-${accent}`, { 'has-image': entry.data.image }] }>
<a href={`/stories/${entry.id}`}>
{entry.data.image ? (
<figure><img src={entry.data.image} alt={entry.data.imageAlt ?? ''} loading="lazy" /></figure>
) : (
<div class="signal" aria-hidden="true"><i></i><i></i><i></i></div>
)}
<div class="story-copy">
<header>
<span>{entry.data.section}</span>
<span>No. {String(index + 1).padStart(2, '0')}</span>
</header>
<h2>{entry.data.title}</h2>
<p>{entry.data.description}</p>
<footer>
<span>{entry.data.tags.slice(0, 2).join(' · ')}</span>
<span>{entry.data.status}</span>
</footer>
</div>
{pattern && <p class="visual-claim">“{pattern.claim}”</p>}
</div>
<div class="story-copy">
<p class="eyebrow">Story · {formatDate(entry.data.published)}</p>
<h3><a href={`/stories/${entry.id}`}>{entry.data.title}</a></h3>
<p>{entry.data.description}</p>
<div class="card-foot">
<span>By {entry.data.author}</span>
<span>{entry.data.status}</span>
</div>
</div>
</a>
</article>
<style>
.story-card {
display: grid;
grid-template-columns: minmax(180px, 0.8fr) minmax(0, 1.2fr);
min-height: 280px;
border-bottom: 1px solid var(--rule);
min-width: 0;
min-height: 390px;
background: var(--paper-raised);
}
.visual {
a {
display: flex;
min-height: 230px;
align-items: center;
justify-content: center;
height: 100%;
flex-direction: column;
gap: 1.4rem;
padding: 2rem;
background: var(--blue);
color: var(--paper);
font-family: 'IBM Plex Mono', monospace;
font-size: 0.65rem;
letter-spacing: 0.1em;
}
.chain {
display: flex;
align-items: center;
flex-direction: column;
}
.chain i {
display: block;
width: 1px;
height: 2.8rem;
margin: 0.6rem 0;
background: #8ea7c1;
}
/* The failure link encodes the story's status. */
/* developing — the claim is still being tested: a dashed, uncertain link */
.chain .fail-link {
height: 3.4rem;
background: repeating-linear-gradient(
to bottom,
#8ea7c1 0 0.45rem,
transparent 0.45rem 0.9rem
);
}
/* disputed — the link is broken */
[data-status='disputed'] .chain .fail-link {
position: relative;
background: linear-gradient(to bottom, #8ea7c1 0 38%, transparent 38% 62%, #8ea7c1 62%);
}
[data-status='disputed'] .chain .fail-link::after {
position: absolute;
width: 0.8rem;
height: 2px;
top: 50%;
left: -0.38rem;
background: #ef765e;
content: '';
transform: rotate(-45deg);
}
/* resolved — the link holds */
[data-status='resolved'] .chain .fail-link {
background: #8ea7c1;
}
/* historical — the record stands, the heat is gone */
.visual[data-status='historical'] {
background: color-mix(in srgb, var(--blue) 55%, var(--ink));
}
[data-status='historical'] .chain .fail-link {
background: #8ea7c1;
}
.visual-claim {
max-width: 24ch;
margin: 0;
color: #c5d1df;
font-size: 0.68rem;
letter-spacing: 0.02em;
line-height: 1.55;
text-align: center;
text-transform: none;
}
.story-copy {
display: flex;
flex-direction: column;
padding: 2rem;
border-top: 1px solid var(--rule);
}
h3 {
max-width: 17ch;
margin: 0;
font-family: 'Newsreader Variable', Georgia, serif;
font-size: clamp(1.8rem, 4vw, 3rem);
font-weight: 600;
letter-spacing: -0.03em;
line-height: 0.98;
}
h3 a {
color: inherit;
text-decoration: none;
}
.story-copy > p:not(.eyebrow) {
max-width: 52ch;
color: var(--muted);
figure {
height: 190px;
margin: 0;
overflow: hidden;
background: var(--blue-soft);
}
.card-foot {
img {
width: 100%;
height: 100%;
object-fit: cover;
transition: transform 450ms cubic-bezier(.2, .7, .2, 1);
}
a:hover img {
transform: scale(1.025);
}
.signal {
display: flex;
height: 12px;
background: var(--blue);
}
.signal i {
flex: 1;
border-right: 1px solid color-mix(in srgb, white 45%, transparent);
}
.signal i:last-child { border-right: 0; }
.accent-soft .signal { background: #88a8c1; }
.accent-ink .signal { background: var(--ink); }
.accent-amend .signal { background: var(--amend); }
.accent-paper .signal { background: #a29d93; }
.story-copy {
display: flex;
flex: 1;
flex-direction: column;
padding: 1.35rem;
}
header,
footer {
display: flex;
justify-content: space-between;
gap: 1rem;
margin-top: auto;
padding-top: 1.25rem;
color: var(--muted);
font-family: 'IBM Plex Mono', monospace;
font-size: 0.65rem;
letter-spacing: 0.04em;
font-size: 0.6rem;
letter-spacing: 0.055em;
text-transform: uppercase;
}
@media (max-width: 650px) {
.story-card {
grid-template-columns: 1fr;
}
h2 {
max-width: 18ch;
margin: 2rem 0 0;
font-family: 'Newsreader Variable', Georgia, serif;
font-size: clamp(1.8rem, 3vw, 2.55rem);
font-weight: 600;
letter-spacing: -0.035em;
line-height: 0.98;
}
.visual {
min-height: 190px;
gap: 1rem;
}
p {
margin: 0.85rem 0 1.6rem;
color: var(--muted);
font-size: 0.86rem;
line-height: 1.5;
}
.chain {
flex-direction: row;
}
footer {
margin-top: auto;
padding-top: 0.85rem;
border-top: 1px solid var(--rule);
}
.chain i {
width: 2.5rem;
height: 1px;
margin: 0 0.65rem;
}
a:hover h2 { color: var(--blue); }
.chain .fail-link {
width: 3rem;
height: 1px;
background: repeating-linear-gradient(
to right,
#8ea7c1 0 0.45rem,
transparent 0.45rem 0.9rem
);
}
[data-status='disputed'] .chain .fail-link {
background: linear-gradient(to right, #8ea7c1 0 38%, transparent 38% 62%, #8ea7c1 62%);
}
[data-status='resolved'] .chain .fail-link,
[data-status='historical'] .chain .fail-link {
background: #8ea7c1;
}
@media (max-width: 620px) {
.story-card { min-height: 330px; }
figure { height: 210px; }
h2 { font-size: 2.25rem; }
}
</style>
src/components/TrustPattern.astro
+1 -1
View File
@@ -11,7 +11,7 @@ const { pattern } = Astro.props;
---
{pattern && (
<details class="trust-pattern" open>
<details class="trust-pattern">
<summary>The trust pattern</summary>
<dl>
<div><dt>Claim</dt><dd>{pattern.claim}</dd></div>
src/content.config.ts
+6
View File
@@ -18,10 +18,16 @@ const stories = defineCollection({
title: z.string(),
description: z.string(),
published: z.coerce.date(),
editorialOrder: z.number().int().positive(),
featured: z.boolean().default(false),
homepage: z.boolean().default(false),
section: z.string().default('Story'),
frontTone: z.enum(['paper', 'blue', 'ink', 'soft', 'amend']).optional(),
tags: z.array(z.string()).default([]),
image: z.string().optional(),
imageAlt: z.string().optional(),
imageCredit: z.string().optional(),
imageCreditUrl: z.url().optional(),
trustPattern: z
.object({
claim: z.string(),
src/content/stories/aadhaar-when-authentication-becomes-rations.md
+52
View File
@@ -0,0 +1,52 @@
---
title: "Aadhaar: when authentication becomes rations"
description: "A biometric match can be highly accurate at national scale and still be the wrong place to put the cost of a failed fingerprint."
published: 2026-07-14
editorialOrder: 12
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Identity"
draft: false
tags: ["aadhaar", "biometrics", "welfare", "exclusion"]
trustPattern:
claim: "Biometric authentication ensures benefits reach the correct person."
trusted: "Recipients must trust sensors, connectivity, databases, enrollment quality, local operators, exception procedures, and the official who recognises a genuine failure."
failure: "An anti-fraud control can turn a technical mismatch into denial of food, wages, or public service."
---
Aadhaar gives more than a billion people a twelve-digit identity number backed by demographic and biometric data. At that scale, even a very good authentication rate produces a large number of failures.
The crucial design decision is what failure means.
If a fingerprint does not match while unlocking a phone, the owner can enter a code. If it fails while collecting food or wages, the system has placed a technical confidence score between a person and an entitlement.
UIDAI's own materials acknowledge poor fingerprint quality, network availability and other technological or biometric limitations. They require service providers to maintain alternate identification and exception-handling processes so genuine residents are not denied service.
That requirement reveals the real architecture. Aadhaar is not only a biometric system. It is a biometric system plus the person at the point of service who recognises an exception.
## Fraud prevention meets asymmetric harm
The state has a legitimate interest in stopping duplicate or fraudulent claims. But fraud and exclusion distribute costs differently. A false acceptance costs a programme. A false rejection can cost a family dinner tonight.
Optimising only the central accuracy figure hides that asymmetry. The quality of the system depends on whether the exception path is available, dignified, fast and safe from arbitrary discretion.
This is a recurring lesson for digital identity. The fallback is not outside the design. It is where the design admits what it does not know.
Before connecting any credential to a necessity, ask:
- Is authentication evidence or a verdict?
- Who can override a failed match?
- Can the person obtain service before the dispute is resolved?
- Is the fallback monitored as carefully as the main path?
- Does preventing one kind of fraud create another kind of unaccountable gatekeeper?
A system should be judged not only by how confidently it recognises the majority, but by what it asks the uncertain person to survive.
### Sources
- [UIDAI: authentication error codes](https://www.uidai.gov.in/en/contact-support/have-any-question/305-faqs/authentication/aadhaar-authentication-history.html)
- [UIDAI: entitlement and exception handling](https://uidai.gov.in/en/304-english-uk/faqs/authentication/for-aadhaar-number-holders/16550-how-to-download-face-authentication-application.html)
src/content/stories/age-check-becomes-identity-check.md
+69
View File
@@ -0,0 +1,69 @@
---
title: "When does an age check become an identity check?"
description: "The EU's age-verification blueprint promises a simple yes-or-no proof. Its success depends on preventing that proof from becoming a reusable tracking handle."
published: 2026-07-14
editorialOrder: 9
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: true
section: "Identity / Now"
frontTone: paper
draft: false
tags: ["age-verification", "eudi", "children", "privacy"]
image: "https://images.unsplash.com/photo-1759215524530-a00b7768ce91?auto=format&fit=crop&w=1600&q=82"
imageAlt: "Hands holding a smartphone displaying a social media feed"
imageCredit: "Swello"
imageCreditUrl: "https://unsplash.com/photos/hands-holding-a-smartphone-displaying-social-media-feed-CkYIMdehoX4"
trustPattern:
claim: "A person can prove they are above an age threshold without revealing identity or date of birth."
trusted: "Users must trust enrollment, credential issuance, wallet software, verifier registration, pseudonym design, revocation, and the availability of non-digital alternatives."
failure: "A minimal proof can still become linkable, compulsory in practice, or expanded from exceptional uses into routine access control."
---
In April 2026, the European Commission urged member states to make its age-verification application available by the end of the year. The blueprint can operate as a standalone app or become part of a European Digital Identity Wallet.
The intended transaction is admirably small. A website asks whether someone is above a threshold. The app answers yes or no. It should not reveal a name, exact birth date or civil identity.
That is much better than uploading a passport to an adult-content site or asking a teenager to give a social platform another permanent identity document.
It still deserves cheerful suspicion.
## Three separate privacy questions
First: **what does the website receive?** A threshold proof can disclose much less than a document.
Second: **can the website recognise the same visitor next time?** A presentation that contains a stable or derivable identifier may be minimal and still linkable.
Third: **can other actors connect the event?** The credential issuer, wallet provider, verifier registry or colluding services may see different parts of the transaction.
These questions are easily collapsed into "the app does not reveal your identity." That sentence can be true at the visible interface while the system remains useful for tracking.
The Commission's technical work recognises unlinkability as a goal. Early designs use domain-specific pseudonyms and batch-issued credentials, while zero-knowledge mechanisms remain part of the privacy conversation. The engineering details matter because policy intent does not itself make two proofs unlinkable.
## Function creep begins with a good use case
Protecting children is a strong political reason to build infrastructure quickly. It is also a difficult setting in which to contest scope. Once a standard proof is available, other services may ask for it because they can: games, marketplaces, forums, health information, news, dating, messaging.
The question changes from "where is age legally necessary?" to "why would a responsible service not check?"
That is how optional infrastructure becomes a practical gate.
## The test before rollout
A credible age-checking system should make four promises testable:
1. the verifier learns only the threshold result;
2. separate verifiers cannot collude to follow a person;
3. repeat visits do not create an unnecessary stable identity;
4. people without a compatible device have a dignified alternative.
Age assurance is not automatically identity. But the difference will not survive on good intentions. It has to be built into the identifiers, proofs, logs, recovery paths and rules governing who is allowed to ask.
### Sources
- [European Commission recommendation, 29 April 2026](https://digital-strategy.ec.europa.eu/en/news/commission-urges-member-states-rollout-eu-age-verification-app)
- [Official age-verification technical specification](https://github.com/eu-digital-identity-wallet/av-doc-technical-specification/blob/main/docs/architecture-and-technical-specifications.md)
- [EDPS analysis of linkability](https://www.edps.europa.eu/data-protection/our-work/publications/techdispatch/2025-12-15-techdispatch-32025-digital-identity-wallets_en)
src/content/stories/certificate-transparency-does-not-prevent-mistakes.md
+41
View File
@@ -0,0 +1,41 @@
---
title: "Certificate Transparency does not prevent mistakes"
description: "It makes certificate authorities observable. That narrower promise has done more for trust than pretending misissuance can be designed away."
published: 2026-07-14
editorialOrder: 20
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: historical
featured: false
homepage: false
section: "Infrastructure"
draft: false
tags: ["certificate-transparency", "pki", "audit", "web"]
trustPattern:
claim: "Publicly trusted certificate authorities can correctly validate every certificate they issue."
trusted: "The web depends on authorities, browser root programmes, domain control checks, logs, monitors, and incident response."
failure: "A compromised or mistaken authority can issue a convincing certificate for a domain it does not control."
---
The encrypted web relies on certificate authorities. Browsers trust a set of organisations to issue certificates binding domain names to keys. A mistake or compromise at any one of them can create a certificate that looks valid for someone else's site.
Certificate Transparency does not solve this by finding a perfect authority. It requires publicly trusted certificates to appear in append-only logs. Domain owners and monitors can inspect the record and detect suspicious issuance.
The system changes the trust claim from "authorities do not make mistakes" to "important authority actions leave evidence."
## Auditability is not prevention
A logged bad certificate is still bad. Detection must be followed by investigation, revocation and, in serious cases, removal of an authority from browser trust stores. Logs themselves require operators, consistency checks and monitors.
But the evidence changes behaviour. Secret misissuance becomes harder. Browser vendors and domain owners gain a shared record. Post-incident arguments begin from an observable event rather than the authority's private database.
This is traceability: the ability to connect an actor to an outcome. It is narrower than radical transparency and more operational than a promise of zero failure.
Identity and agent systems need similar records. Not public dumps of personal activity, but tamper-evident evidence of issuance, delegation, revocation and rule changes available to the people who must contest them.
Trust improves when the system stops claiming infallibility and starts making repair possible.
### Source
- [Certificate Transparency Version 2.0, RFC 9162](https://www.rfc-editor.org/rfc/rfc9162)
src/content/stories/estonia-chip-that-broke-trust.md
+47
View File
@@ -0,0 +1,47 @@
---
title: "Estonia and the chip that broke trust"
description: "The model digital state survived a mass identity-card vulnerability because it had revocation, remote repair, alternatives and an institution willing to act."
published: 2026-07-14
editorialOrder: 14
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: historical
featured: false
homepage: false
section: "History"
draft: false
tags: ["estonia", "e-id", "roca", "recovery"]
trustPattern:
claim: "A certified smartcard provides a durable root of trust for digital government."
trusted: "Citizens also trust chip vendors, cryptographic libraries, researchers, certificate authorities, update systems, and alternative identity methods."
failure: "A flaw in one supplier's key generation can place a national identity layer at risk."
---
Estonia is the success story in almost every digital-government presentation. That is precisely why its 2017 identity-card crisis matters.
Researchers found that keys generated by certain Infineon chips were vulnerable to the ROCA attack. In Estonia, the affected hardware sat inside hundreds of thousands of identity cards used for authentication and digital signatures.
The cards had passed certification. The state had not made an obviously reckless choice. A weakness deep in a supplier's implementation travelled upward into national infrastructure.
Estonia restricted access to public keys, enabled remote certificate updates, suspended vulnerable certificates and maintained alternatives such as Mobile-ID and Smart-ID. Its later lessons-learned report says roughly 800,000 cards were affected and that 94 percent of electronically used cards were updated.
## The success was the response
It is easy to read the incident as proof that national e-ID is brittle. It is more useful to notice what made the system recoverable:
- the vulnerability was disclosed;
- certificates could be suspended and revoked;
- many cards could be repaired remotely;
- alternative authentication methods existed;
- a public authority could coordinate an emergency response;
- the event produced a lessons-learned document.
The root of trust was not the chip. The root was a socio-technical recovery system surrounding a fallible chip.
This is the standard by which new wallets should be judged. Not whether certified hardware can fail—it can—but whether a whole population can be informed, migrated and kept able to function when it does.
### Sources
- [Estonian Information System Authority: ROCA lessons learned](https://www.ria.ee/sites/default/files/documents/2022-11/Roca-vulnerability-and-eID-lessons-learned-2018.pdf)
- [Estonia resolves its ID-card crisis](https://ria.ee/en/news/estonia-resolves-its-id-card-crisis)
src/content/stories/eu-wallet-arrives-before-its-privacy-does.md
+76
View File
@@ -0,0 +1,76 @@
---
title: "The EU wallet arrives before its privacy does"
description: "Europe's identity wallet is real, useful, optional—and racing toward a privacy problem that selective disclosure does not solve."
published: 2026-07-14
editorialOrder: 1
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: true
homepage: true
section: "Identity / Now"
frontTone: paper
draft: false
tags: ["eudi", "digital-identity", "privacy", "europe"]
image: "https://images.unsplash.com/photo-1691256676376-357c3aa66c89?auto=format&fit=crop&w=1800&q=82"
imageAlt: "A hand holding a smartphone with a blank screen"
imageCredit: "personalgraphic.com"
imageCreditUrl: "https://unsplash.com/photos/a-person-holding-a-phone-in-their-hand-u1b6E6IkSGQ"
trustPattern:
claim: "A wallet can let Europeans prove facts without routinely handing over an entire identity document."
trusted: "Users must trust national wallet providers, credential issuers, relying parties, device security, certification, and the rules connecting them."
failure: "Selective disclosure can reduce what one verifier sees while still leaving repeated presentations linkable across time or services."
---
By the end of 2026, every EU member state is supposed to offer at least one European Digital Identity Wallet. That sentence used to sound like a policy aspiration. It now describes software, implementing regulations, certification work, six large-scale pilots, and a deadline.
The wallet is intended to hold more than a digital passport. A person may use it to present a driving licence, a diploma, a professional qualification, a bank-related credential, or a proof of age. Its use is legally optional. The application components installed on a user's device must be open-source licensed. Relying parties that are required to identify customers will in many cases have to accept it.
This is not nothing. Today, proving that you are over eighteen can mean showing a stranger a document containing your name, photograph, date of birth, nationality and document number. A well-designed wallet can answer the narrower question instead: **yes, this person is over eighteen**.
The European Commission calls this user control. The phrase is deserved, but incomplete.
## Four parties, not one wallet
The friendly picture is a phone containing your credentials. The working system has at least four kinds of actor:
1. the person using the wallet;
2. an issuer that signs a fact about them;
3. a relying party that asks to see it;
4. a scheme authority that decides which wallets, issuers and relying parties count.
Then come the phone maker, operating system, secure hardware, wallet provider, certification bodies, national registries, revocation services and whatever recovery process appears when the phone is lost.
The wallet moves some data and decisions toward the user. It does not remove the surrounding government and commercial trust system. It gives that system a new interface.
## Disclosure is not unlinkability
The urgent issue is not whether a credential can hide unnecessary fields. The technical formats can do that. The harder question is whether two presentations can be recognised as coming from the same person.
In its 2025 technical analysis, the European Data Protection Supervisor distinguished **selective disclosure** from **unlinkability**. Commonly deployed credential formats can reveal only selected attributes while retaining values or signatures that let a relying party recognise repeat visits. Colluding parties may gain more. Anonymous-credential and zero-knowledge systems can do better, but they bring different implementation and revocation costs.
This is not an argument to cancel the wallet. Paper documents overshare. Passwords are miserable. "Sign in with Google" is hardly a sovereignty programme. A common European alternative could be genuinely useful.
It is an argument for asking the right acceptance question. Not: *does the wallet share less data than a passport scan?* It often will. Ask: *which parties can tell that two apparently minimal disclosures belong to the same person, and under what conditions?*
The distinction will determine whether the wallet becomes a privacy tool that happens to identify us, or an identity system that happens to disclose selectively.
## The practical test
Before installing a national wallet, a person should be able to answer five questions without reading a standards repository:
- What will a service receive when I approve this request?
- Can this service recognise me next time?
- Can the issuer learn where I used the credential?
- What happens when I replace or lose my phone?
- Can I use the service another way?
If the interface cannot answer those, "full control" is still a policy claim rather than a user property.
### Sources
- [European Commission: EUDI Regulation and end-of-2026 rollout](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation)
- [Regulation (EU) 2024/1183](https://eur-lex.europa.eu/eli/reg/2024/1183/oj)
- [European Data Protection Supervisor: Digital Identity Wallets](https://www.edps.europa.eu/data-protection/our-work/publications/techdispatch/2025-12-15-techdispatch-32025-digital-identity-wallets_en)
- [Official Architecture and Reference Framework](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework)
src/content/stories/fraud-and-failure-leave-different-messes.md
+42
View File
@@ -0,0 +1,42 @@
---
title: "Fraud and failure leave different-shaped messes"
description: "A fraudulent organisation may coordinate brilliantly around a lie. A genuinely failing one often loses the ability to coordinate at all."
published: 2026-07-14
editorialOrder: 26
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Institutions"
draft: false
tags: ["fraud", "coordination", "institutions", "detection"]
trustPattern:
claim: "Internal dysfunction is an early warning of organisational fraud."
trusted: "Observers trust internal communication metrics to reveal whether activity serves the stated purpose rather than a coordinated deception."
failure: "A fraud can look highly coordinated because maintaining the false account requires intense, competent collaboration."
---
We expect a dishonest organisation to look broken inside. People hide information, incentives conflict, and the truth strains the structure.
Sometimes the opposite happens. Fraud demands coordination.
Executives align a narrative. Teams reconcile invented numbers. Lawyers, salespeople and communications staff manage inconsistencies. Messages increase as exposure approaches. The organisation may remain tightly connected because the deception is its actual project.
A legitimate failure often leaves a different trace. Teams fragment. Response times grow. Information stops crossing boundaries. Leaders receive filtered reports. The organisation still wants to perform its stated purpose and is losing the capacity to do so.
## Compare inside with outside
Internal health metrics cannot by themselves distinguish good coordination from coordinated harm. The missing measure is the gap between claims and externally observable reality.
This suggests a simple diagnostic pair:
- **claims versus outcomes:** is the public account outrunning evidence?
- **coordination trend:** is the organisation maintaining the ability to act together?
High coordination plus a widening claim-reality gap is a fraud warning. Declining coordination with relatively honest claims points toward a repairable institutional crisis. Both can coexist when a fraud begins to unravel.
The lesson travels beyond companies. A moderation team can coordinate censorship efficiently. A government office can administer exclusion consistently. A community can become extremely good at protecting a leader.
Coordination is capacity, not virtue. Trust depends on what the capacity is serving and whether affected people can compare the account with the world.
src/content/stories/identity-is-the-wrong-abstraction.md
+51
View File
@@ -0,0 +1,51 @@
---
title: "Identity is the wrong abstraction"
description: "A library needs to know that you may borrow a book. It usually does not need a universal account of who you are."
published: 2026-07-14
editorialOrder: 16
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Security"
draft: false
tags: ["capabilities", "authorization", "identity", "privacy"]
trustPattern:
claim: "Strong identity is the foundation of strong access control."
trusted: "The system must trust that identity attributes are necessary, current, correctly bound, and relevant to the requested action."
failure: "Identification collects and links a person when a narrow, revocable permission would have been enough."
---
Most access systems ask two questions in order: who are you, and what may you do?
Capability security asks whether the first question is necessary.
A ticket lets you enter a theatre without describing your employment history. A key opens a door without presenting a global name. A signed capability can grant one program permission to write one file without granting it an identity recognised everywhere.
The distinction is old. SPKI/SDSI and object-capability researchers argued for authorisation certificates, local names and unforgeable permissions rather than universal identity plus sprawling access-control lists.
## Identification creates a surplus
When a service learns who you are, it gains information beyond the immediate decision. The information can be logged, correlated, breached, compelled or reused to personalise a later judgement.
Sometimes identification is necessary. A hospital needs the correct medical record. A court must know which person is before it. But many systems ask for identity because their authorisation model has no smaller language.
The privacy-preserving move is not always a better ID. It may be a better permission:
- over eighteen, not birth date and name;
- licensed to perform this procedure, not a complete professional profile;
- allowed to read this document until Friday, not a permanent organisation account;
- paid member of this library, not a national identifier.
## The agent lesson
This becomes urgent with AI agents. An agent may act for several people and services. Giving it a stable identity does not express what it may do now. A scoped, revocable capability can.
Identity answers "which actor is this?" Authority answers "why may it perform this action?" Good systems need both sometimes. They should not use the first as a substitute for the second.
### Sources
- [SPKI Certificate Theory, RFC 2693](https://www.rfc-editor.org/rfc/rfc2693)
- [Mark S. Miller, Robust Composition](https://jscholarship.library.jhu.edu/bitstream/handle/1774.2/873/markm-thesis.pdf)
src/content/stories/money-is-a-memory-system.md
+39
View File
@@ -0,0 +1,39 @@
---
title: "Money is a memory system"
description: "A balance remembers past contribution, couples strangers and compresses many kinds of value into one number. That is why monetary failure feels like amnesia."
published: 2026-07-14
editorialOrder: 21
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Money"
draft: false
tags: ["money", "trust", "memory", "crypto"]
trustPattern:
claim: "Money works because the token or ledger entry has value."
trusted: "Participants trust that others will accept it, records will persist, rules will remain tolerable, and institutions will settle disputes and prevent arbitrary rewriting."
failure: "The token can remain physically present after the social capacity to exchange through it has collapsed."
---
Money solves three problems at once.
It remembers value across time. It connects people who want different things. It compresses incomparable goods and work into a common unit. The coin, note or database entry is the interface to those functions, not their ultimate source.
This is why a bank balance can buy a house while being only a number. It records a claim inside a network that expects the claim to remain legible and acceptable.
## Trust made transferable
Without money, exchange often requires a double coincidence: I want what you have, you want what I have, and we agree now. Money lets one transaction leave behind a portable memory that can be used with somebody else later.
The compression is powerful and lossy. A price makes comparison possible while forgetting need, effort, ecological cost, affection and power. What cannot enter the unit becomes easy to treat as valueless.
Monetary crises expose the substrate. During inflation, the unit's memory degrades. During a bank run, people doubt that recorded claims can be honoured at once. During currency collapse, notes still exist but no longer coordinate future acceptance.
Cryptocurrency changes the memory mechanism. A distributed ledger and fixed issuance rules can reduce reliance on banks or states for certain operations. Users then trust software, key custody, consensus, exchanges, governance and future demand.
The trust did not vanish. It changed form.
Money is useful because strangers can rely on a shared memory without knowing one another. The political question is who may write that memory, whose losses it forgets, and how people recover when the number no longer means tomorrow what it meant today.
src/content/stories/name-you-give-a-key.md
+40
View File
@@ -0,0 +1,40 @@
---
title: "The name you give a key"
description: "Petnames offer a modest way through the impossible demand that online names be secure, global, decentralised and easy to remember."
published: 2026-07-14
editorialOrder: 17
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Design"
draft: false
tags: ["petnames", "zookos-triangle", "naming", "keys"]
trustPattern:
claim: "A decentralised identifier can also be globally unique, secure and human-meaningful."
trusted: "Human-readable naming still depends on a registry, ledger, domain owner, introducer, local address book, or another authority over meaning."
failure: "The design can relocate naming trust while marketing the identifier as though it removed it."
---
Public keys are secure identifiers and terrible names. Human names are memorable and famously non-unique. Global registries make names usable by deciding who gets which one, thereby becoming an authority.
Zooko's Triangle describes the constraint: a naming system wants names that are secure, decentralised and human-meaningful, but traditionally gets at most two.
Blockchains are often said to defeat the triangle. More accurately, they place uniqueness and conflict resolution into ledger consensus and governance. That may be a worthwhile trade. It is not the disappearance of trust.
## The petname answer
A petname system declines the global ambition. The secure identifier remains a key. You attach a local name meaningful to you: "Mum", "the plumber from Alderney", "Ana's release key". An introducer may suggest a nickname, but your address book decides what you see.
Two people can use different names for the same key without conflict. A malicious global claimant cannot automatically overwrite the relationship you already recorded.
This is how humans already navigate trust. We rarely need a single universal name for everyone. We need stable reference inside a relationship, plus an explicit process for introduction.
The limitation is also the benefit. Petnames do not make discovery effortless. They make the source of meaning visible. The name is yours, the key is theirs, and the binding came from a particular encounter.
### Further reading
- [Marc Stiegler: An Introduction to Petname Systems](https://www.skyhunter.com/marcs/petnames/IntroPetNames.html)
- [Zooko Wilcox-O'Hearn: Names](https://zooko.com/distnames.html)
src/content/stories/network-state-needs-lost-password-desk.md
+51
View File
@@ -0,0 +1,51 @@
---
title: "A network state still needs a lost-password desk"
description: "Founding a cloud community is dramatic. Handling a dead founder, stolen key, contested vote or stranded member is what makes it political."
published: 2026-07-14
editorialOrder: 22
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Sovereignty"
draft: false
tags: ["network-state", "governance", "recovery", "community"]
trustPattern:
claim: "A highly aligned online community can become a sovereign polity through shared technology, economy and territory."
trusted: "Members must trust founders, treasuries, membership rules, vote systems, courts, key recovery, physical hosts, and the treatment of dissent."
failure: "A community designed for voluntary entry can reproduce arbitrary rule when the first serious exception has no legitimate process."
---
The Network State begins with an online community, builds a shared economy, crowdfunds territory and seeks diplomatic recognition. The sequence is intentionally grand. It asks digital communities to think beyond chat rooms and companies.
The test is mundane.
A member loses the key controlling their property record. A founder dies with treasury access. A vote is attacked by duplicated identities. Two members claim the same house. A family wants to leave but their livelihood depends on community credentials. A local host government orders data disclosure.
These are not implementation details beneath politics. They are politics.
## Alignment is not procedure
Highly aligned communities can coordinate quickly because many disputes appear settled in advance. Shared values reduce friction. They can also make disagreement look like betrayal.
Durable governance assumes alignment will fail. It creates procedures for appeal, succession, minority protection, conflicts of interest and exit under pressure. It limits the founder precisely when members still trust the founder.
The technical equivalent is recovery. A key-only system avoids discretionary account restoration until an ordinary accident produces an irreversible loss. A support desk reintroduces judgement. Multisignature custody distributes it. Social recovery makes relationships part of the constitution. Every option names governors.
A network state should therefore publish its ugly manual before its manifesto:
- Who restores a lost identity?
- Which decisions are reversible?
- Who judges disputed evidence?
- Can members fork records and assets, not merely social profiles?
- What duties survive exit?
- Which physical law outranks the network's law?
The answers need not resemble a nation-state. They do need to survive a bad Tuesday.
### Further reading
- [The Network State](https://thenetworkstate.com/)
- [Elinor Ostrom: institutional diversity](https://www.nobelprize.org/prizes/economic-sciences/2009/ostrom/lecture/)
src/content/stories/old-phone-real-identity-test.md
+77
View File
@@ -0,0 +1,77 @@
---
title: "Your old phone is the real identity test"
description: "Login demos happen on new devices. Trust is decided after a theft, a dead battery, a changed number, or a relationship someone needs to escape."
published: 2026-07-14
editorialOrder: 2
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: true
section: "Recovery"
frontTone: paper
draft: false
tags: ["recovery", "passkeys", "wallets", "safety"]
image: "https://images.unsplash.com/photo-1654944932733-bca31b703dd7?auto=format&fit=crop&w=1600&q=82"
imageAlt: "A bunch of keys, one inserted into an old wooden door"
imageCredit: "Raphael GB"
imageCreditUrl: "https://unsplash.com/photos/a-key-on-a-door-dofnXBVZ51c"
trustPattern:
claim: "Keeping credentials on a personal device gives the individual control."
trusted: "The person must trust device backups, account recovery, telecoms, support staff, and any family or platform account involved in synchronisation."
failure: "When the device disappears, control may quietly return to the institution—or to whoever controls the recovery channel."
---
Security products are usually demonstrated in the first five minutes of ownership. The phone is charged. The screen is intact. The face scanner recognises its owner. A credential appears with a satisfying animation.
The meaningful demonstration starts two years later.
The phone fell into the sea. The number was recycled. A cloud account is shared with a spouse the owner is trying to leave. The name on a government record changed but the bank's record did not. The person has their password but not the old device; their document but not the email address; their face but not quite the face the enrollment camera remembers.
At that point, the recovery system becomes the identity system.
## Recovery is governance
Passkeys, digital wallets and hardware-backed credentials can remove whole classes of attack. They can also make an account wonderfully easy to use on an ordinary day. But none abolishes the question of who restores access.
Recovery may depend on:
- another device already signed into the same platform account;
- a cloud-synchronised credential store;
- a phone number and mobile network;
- identity documents checked by support staff;
- a bank branch, municipal office or employer;
- trusted contacts or recovery codes;
- creating an entirely new credential and convincing every relying party to accept it.
Each option is a governance choice disguised as a help screen. It decides which evidence outranks which, who may make an exception, and who can be locked out by a person with access to their household devices.
## The safest default for whom?
"Ask the account owner" works badly when account ownership is itself contested. "Send a code to the phone" works badly after theft or coercive control. "Visit an office" may be a humane fallback for one person and an impossible journey for another. Social recovery distributes power, but it also reveals dependencies and assumes the social circle is safe.
There is no perfect answer. There are only threat models that admit whom they protect.
This suggests a better product review. Do not ask only whether enrollment resists fraud. Test the five ugly transitions:
1. lost device;
2. changed phone number;
3. changed legal name;
4. death or incapacity;
5. escape from a controlling household.
A system that cannot explain these cases has not finished its security model. It has stopped at the happy path.
## The constitutional layer
Recovery feels secondary because it is used less often. Constitutions are also used less often than ordinary procedures. Both matter most when normal authority breaks down.
Whoever controls recovery can override keys, records and prior consent. That actor may be a state, a platform, a bank, a group of friends or the user alone with a piece of paper. The choice can be reasonable. It cannot be absent.
The old phone is useful because it makes the hidden constitution visible. When the elegant credential is gone, whom does the system believe?
### Further reading
- [FIDO Alliance: Passkeys](https://fidoalliance.org/passkeys/)
- [European Digital Identity Wallet architecture](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework)
src/content/stories/one-score-to-rule-a-life.md
+45
View File
@@ -0,0 +1,45 @@
---
title: "One score to rule a life"
description: "Global trust scores are attractive because they make people easy to compare. That is also the reason not to build one."
published: 2026-07-14
editorialOrder: 23
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Reputation"
draft: false
tags: ["reputation", "scores", "goodhart", "governance"]
trustPattern:
claim: "Aggregating enough behaviour produces an objective measure of trustworthiness."
trusted: "People must trust the selected behaviours, weights, data sources, identity matching, appeal process, decay rules, and institution allowed to define the target."
failure: "The score becomes a target, strips context, protects incumbents, and turns a design choice into social fact."
---
A single score is a beautiful interface. It converts years of conduct into something sortable. Lenders, employers, marketplaces and strangers can make fast decisions. The system seems to replace prejudice with measurement.
Then the measured person starts living for the number.
Goodhart's law is the familiar warning: when a measure becomes a target, it stops being a good measure. Ratings inflate. Reviews are purchased. Drivers avoid difficult passengers. Creators optimise engagement rather than value. The platform adds hidden signals to defeat gaming, making the judgement less contestable.
## The score invents a person
No global trustworthiness exists to be discovered. There are narrower questions:
- Will this seller ship the item?
- Does this maintainer review cryptographic code carefully?
- Has this borrower repaid loans under comparable conditions?
- Is this neighbour reliable with a spare key?
Combining them creates a new political object: the generally trustworthy person. Whoever chooses weights decides what kind of life counts.
The score also creates an attractor. High-ranked people receive more opportunities, generating more evidence and stronger rank. Newcomers face a cold start. A mistaken penalty can propagate across contexts. The interface looks neutral while amplifying its own history.
Better systems preserve plural statements, uncertainty and domain boundaries. They show who made a claim and allow relevance to be argued. This is slower. The slowness is the cost of not pretending a human being is one variable.
### Further reading
- [Audun Jøsang, Ismail and Boyd: Survey of Trust and Reputation Systems](https://doi.org/10.1016/j.dss.2005.05.019)
- [Onora O'Neill: A Question of Trust](https://www.bbc.co.uk/radio4/reith2002/)
src/content/stories/repair-is-a-test.md
+45
View File
@@ -0,0 +1,45 @@
---
title: "Repair is a test, not a moral duty"
description: "Trying to fix a system can generate the evidence that the system itself—not one parameter—is wrong."
published: 2026-07-14
editorialOrder: 25
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Repair"
draft: false
tags: ["repair", "institutions", "failure", "change"]
trustPattern:
claim: "A flawed institution should be repaired because replacement destroys accumulated trust and knowledge."
trusted: "Participants must trust that repair attempts are bounded, measured, reversible, and capable of questioning the institution's basic categories."
failure: "Endless repair can force vulnerable people to subsidise a structure whose fixes contradict one another."
---
"Repair, do not replace" sounds mature. It respects accumulated knowledge, relationships and infrastructure. Replacement is expensive and often produces its own naïve failures.
"Keep trying" can also become a sentence imposed on the people already absorbing harm.
A useful repair has boundaries. Change one mechanism, observe what happens, and preserve evidence. Did errors decrease? Did access improve without moving the burden somewhere less visible? Did the fix survive outside the pilot?
## When repairs conflict
Sometimes every local fix breaks another part of the system. Stronger identity checks reduce fraud but exclude legitimate users. Easier recovery restores access but increases coercion and account takeover. More transparency produces privacy loss. Centralisation improves consistency while removing local judgement.
Trade-offs are normal. But repeated, mutually incompatible repairs can reveal that the system is using the wrong categories. Perhaps the problem is not the accuracy threshold but making one identity check govern every service. Perhaps the global reputation score cannot be made contextual because globality is the defect.
Repair attempts then become probes. Their failure is not wasted effort if it shows why the current structure cannot hold all required values at once.
## A finite obligation
Before asking people to remain inside a repair process, state:
- what will be tried;
- what evidence counts;
- how long the attempt lasts;
- which harms trigger an immediate stop;
- what replacement or exit becomes available after failure.
Repair deserves a chance. It does not deserve infinity.
src/content/stories/reputation-should-not-follow-you-everywhere.md
+68
View File
@@ -0,0 +1,68 @@
---
title: "Reputation should not follow you everywhere"
description: "Portable reputation sounds liberating until a rating earned in one room becomes a verdict in every other room."
published: 2026-07-14
editorialOrder: 4
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: true
section: "Reputation"
frontTone: soft
draft: false
tags: ["reputation", "context", "platforms", "power"]
trustPattern:
claim: "A portable reputation lets good work travel with the person who earned it."
trusted: "New audiences must trust the original context, metrics, raters, translation, decay rules, and the identity binding the record to a person."
failure: "A useful local signal can harden into a permanent, cross-domain judgement that nobody intended to make."
---
Reputation is compressed history. It lets you get into a stranger's car, buy from a seller you have never met, or accept code from a maintainer living on another continent. Ten thousand complicated interactions become 4.9 stars, a badge, a commit history or a familiar name.
That compression solves a real problem. Nobody can personally know everyone with whom they need to coordinate.
It also throws most of the truth away.
The score remembers the outcome and forgets the circumstances. It preserves what the platform could measure and discards what it could not. It combines interactions that may not belong together. Then, because the result is legible, it becomes tempting to move it.
## Portable to where?
People often say users should own and carry their reputation between platforms. The complaint is sound: a marketplace should not be able to confiscate ten years of honest work by closing an account.
But portability has a destination. A record that says somebody is a reliable open-source reviewer may help another software community. It says little about whether they are a safe babysitter, a careful driver, a good tenant or a wise political representative.
Trust is domain-specific. Reputation systems continually erase that boundary because one number is easier to display than a bundle of conditional statements.
The result is the halo effect when things go well and totalising punishment when they do not. Success in one domain masquerades as character. Failure in another becomes searchable everywhere.
## A reputation needs a label
A less dishonest portable record would carry its limits:
- who made the assessment;
- after what kind of interaction;
- in which community and role;
- using which criteria;
- how recent the evidence is;
- what did not transfer.
"Trusted" is nearly meaningless. "Five maintainers accepted twelve of Ana's security patches in this repository during the past year" is narrower and more useful.
The complexity is not clutter added to an otherwise pure score. It is the information the score removed.
## The right to become locally unknown
Good reputation design must also preserve a limited right to start again. Not a right to conceal relevant harm, but a right not to have every old context automatically govern every new one.
Memory needs decay. Translation needs friction. A person should be able to challenge the binding between a claim and their identity. Systems should distinguish direct evidence, hearsay and algorithmic inference.
The aim is not a universal reputation passport. It is a collection of accountable statements whose relevance must be argued at the boundary.
Portability without context gives a person ownership of the cage. The better promise is smaller: your record can travel, but its authority does not travel for free.
### Further reading
- [Onora O'Neill: A Question of Trust](https://www.bbc.co.uk/radio4/reith2002/)
- [Raph Levien and Alexander Aiken: Attack-Resistant Trust Metrics](https://www.usenix.org/publications/library/proceedings/sec98/full_papers/levien/levien_html/levien.html)
src/content/stories/safety-number-nobody-checks.md
+43
View File
@@ -0,0 +1,43 @@
---
title: "The safety number nobody checks"
description: "Signal gives every pair of correspondents a strong way to verify keys. Most people ignore it, and the design remains useful."
published: 2026-07-14
editorialOrder: 19
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Security"
draft: false
tags: ["signal", "encryption", "safety-numbers", "usability"]
trustPattern:
claim: "End-to-end encryption proves that a conversation is private."
trusted: "Correspondents still trust key distribution, device integrity, software updates, contact discovery, and their response when keys change."
failure: "Encryption can protect a channel to the wrong endpoint or produce warnings people have learned not to investigate."
---
Every Signal conversation has a safety number derived from the participants' identity keys. Two people can compare it in person or through another channel. Matching numbers provide strong evidence that the encrypted conversation terminates at the expected devices rather than a substituted key.
Most people never compare one.
This is often treated as a usability failure. It is also a useful separation of assurance levels.
Ordinary conversations receive end-to-end encryption and warnings when keys change. A journalist meeting a source, an administrator handling recovery codes or a family discussing an immediate threat can perform the stronger, pairwise check. The protocol does not require a global authority to label every person "verified" in advance.
## Verification belongs to a relationship
The safety number is not a blue tick attached to a universal profile. Alice verifies her channel with Bob. Carol's verification of Bob is a separate event.
That prevents trust from silently becoming transferable. Carol may introduce Bob, but Alice can still decide whether the relationship needs direct verification.
The remaining design challenge is key change. People replace phones and reinstall applications. A warning that fires frequently for harmless maintenance becomes background noise. A warning that is too quiet fails exactly when substitution matters.
The strongest interface therefore does not merely display cryptographic truth. It helps a person understand why the key changed and what action fits the stakes.
Signal's safety numbers are a good model precisely because they are optional, local and specific. Strong verification is available without turning every conversation into an identity checkpoint.
### Source
- [Signal Support: safety numbers](https://support.signal.org/hc/en-us/articles/360007060632-What-is-a-safety-number-and-why-do-I-see-that-it-changed)
src/content/stories/selective-disclosure-is-not-invisibility.md
+50
View File
@@ -0,0 +1,50 @@
---
title: "Selective disclosure is not invisibility"
description: "Showing fewer fields is good privacy. It does not necessarily stop a verifier from recognising you across presentations."
published: 2026-07-14
editorialOrder: 10
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Identity"
draft: false
tags: ["selective-disclosure", "unlinkability", "credentials", "privacy"]
trustPattern:
claim: "A selectively disclosed credential reveals only what the user chooses to share."
trusted: "The user must trust the credential format, identifiers, signatures, wallet implementation, issuer, verifier, and their resistance to correlation."
failure: "A presentation can hide a birth date while retaining enough stable structure to recognise the same holder again."
---
Imagine a digital driving licence that proves you are over eighteen without showing your address. That is selective disclosure: the verifier receives less.
Now imagine you present the proof at three shops. Each receives no name and no birth date, but each presentation contains a stable value derived from the same credential. If the shops compare notes, they may learn that the same unnamed person visited all three.
That is linkability: the verifier can connect events.
The two properties answer different questions.
## Less data, same trail
Privacy marketing tends to describe the contents of one transaction. "Only the necessary attribute is shared." This can be accurate while ignoring the trail formed by many transactions.
The European Data Protection Supervisor has warned that commonly used credential formats may provide selective disclosure without full unlinkability. Stable identifiers, attribute hashes or issuer signatures can allow repeat recognition, especially when relying parties collude.
There are mitigations: one-time credentials issued in batches, domain-specific pseudonyms, anonymous credentials and zero-knowledge proofs. None is magic. Batch issuance complicates revocation and operations. Pseudonyms intentionally preserve some linkability inside a domain. Advanced proofs need mature implementations and agreed standards.
## Ask the two-question version
When a wallet says it shares only what is needed, ask:
1. What does this verifier learn from this presentation?
2. What can this verifier—or several verifiers together—learn from repeated presentations?
The first question is about disclosure. The second is about the shape of a life over time.
Good privacy needs both. A minimal answer that leaves a durable trail is still an improvement over handing over a passport scan. It is simply not invisibility, anonymity or unlinkability, and should not be sold as though those words were interchangeable.
### Source
- [European Data Protection Supervisor: Digital Identity Wallets](https://www.edps.europa.eu/data-protection/our-work/publications/techdispatch/2025-12-15-techdispatch-32025-digital-identity-wallets_en)
src/content/stories/small-communities-federate.md
+65
View File
@@ -0,0 +1,65 @@
---
title: "Small communities do not scale. They federate."
description: "The intimacy that makes a neighbourhood, forum or practice group trustworthy is exactly what disappears when it becomes one enormous room."
published: 2026-07-14
editorialOrder: 6
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: true
section: "Community"
frontTone: paper
draft: false
tags: ["community", "federation", "ostrom", "governance"]
image: "https://images.unsplash.com/photo-1739298061707-cefee19941b7?auto=format&fit=crop&w=1800&q=82"
imageAlt: "A group of people in conversation around a table"
imageCredit: "Ninthgrid"
imageCreditUrl: "https://unsplash.com/photos/a-group-of-people-sitting-around-a-white-table-AekHsx1SxXQ"
trustPattern:
claim: "A successful community can preserve its culture while growing to a global scale."
trusted: "Members must trust moderators, ranking systems, bridge-builders, shared rules, and the translations imposed between unlike local groups."
failure: "Growth removes local knowledge, making governance either impersonal and gameable or concentrated in a distant centre."
---
A good small community contains knowledge that nobody has written down. People know who is joking, who always overpromises, who can repair a boiler, whose silence means discomfort, and which old disagreement explains today's careful wording.
Software cannot simply turn that knowledge into a database and retain the community. The knowledge works because it is situated, reciprocal and costly to fake.
This is why "scaling community" is often the wrong goal. Scale the ability of communities to cooperate. Do not scale one room until nobody recognises it.
## Local trust is cheap for a reason
In a small group, consequences attach naturally. A bad contribution is seen by people who understand its context. Help creates memory. Disputes can be resolved by people who expect to meet again.
At large scale, those conditions weaken. Moderators cannot know participants. Universal rules replace judgement. Metrics stand in for memory. A central team becomes responsible for translating millions of local situations into a single enforcement language.
The usual response is more machinery: identity checks, reputation scores, automated moderation, global policy. Each layer can solve a problem, but it also moves authority toward whoever builds the machinery.
## The federation move
Federation accepts that trust is local and translation is lossy.
Imagine many communities with their own membership, norms and memory. They cooperate through explicit bridges. A bridge does not announce that "Ana has a reputation of 0.87." It says something narrower:
> This open-source group has worked with Ana for a year and considers her reliable for code review. We do not know whether that assessment transfers to financial custody.
The limitation is part of the signal.
Elinor Ostrom's work on durable commons showed that successful self-governance often relies on clear local boundaries, community-shaped rules, monitoring, graduated sanctions, inexpensive conflict resolution and nested layers. This is neither the fantasy of no governance nor the claim that one authority must govern everything.
## A yoga class and a protocol
The principle is ordinary. A yoga teacher may trust one student to open the studio, another to help beginners, and a third to handle the mailing list. Nobody needs a universal rank. When the studio collaborates with a neighbourhood group, somebody translates between the two contexts.
A hacker project works similarly. Commit access, release authority and social standing are related but not identical. Another project may accept a signed release without importing the entire hierarchy.
Good federation makes these bridges visible and replaceable. Bad federation hides a global platform behind local branding.
The test is not how many users the system can place in one graph. It is whether groups can remain meaningfully different, cooperate anyway, and leave a captured bridge without losing themselves.
### Further reading
- [The Nobel Prize: Elinor Ostrom's work on governing commons](https://www.nobelprize.org/prizes/economic-sciences/2009/ostrom/facts/)
- [ActivityPub, a federated social-web protocol](https://www.w3.org/TR/activitypub/)
src/content/stories/sovereign-individual-favorite-verb-exit.md
+65
View File
@@ -0,0 +1,65 @@
---
title: "The Sovereign Individual's favourite verb is exit"
description: "Digital sovereignty begins as a technical promise and ends as a political question: who can leave, what can they take, and who is left behind?"
published: 2026-07-14
editorialOrder: 7
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: true
section: "Sovereignty"
frontTone: paper
draft: false
tags: ["sovereign-individual", "network-state", "exit", "politics"]
image: "https://images.unsplash.com/photo-1553697388-94e804e2f0f6?auto=format&fit=crop&w=1800&q=82"
imageAlt: "A traveller holding two passports"
imageCredit: "Spencer Davis"
imageCreditUrl: "https://unsplash.com/photos/person-holding-passports-0QcSnCM0aMc"
trustPattern:
claim: "Digital tools can give individuals credible exit from institutions that no longer serve them."
trusted: "The leaver must trust portable money, identity, communication, jurisdiction, physical safety, and a destination willing to recognise them."
failure: "Exit can become a luxury for the mobile while weakening the voice and shared infrastructure of everyone who cannot leave."
---
*The Sovereign Individual* made a durable prediction in 1997: information technology would weaken the nation-state's ability to tax, control and contain increasingly mobile people. The book is not a manual for identity systems. It is the atmosphere inside which many of them were imagined.
The recurring value is **credible exit**.
If a bank can freeze you, hold your own money. If a platform can erase you, hold your own key. If a country becomes hostile, make your work, wealth and community portable. If geography fixes political membership, build communities online first and territory later.
This logic runs from crypto custody through self-sovereign identity to Balaji Srinivasan's network state. It is attractive because exit disciplines power. An institution behaves differently when members can leave without losing everything.
## Exit has a dependency list
The sovereign person is often represented by a key. A key is not a country, an income, a supply chain or a safe home.
Meaningful exit may require:
- a recognised travel document;
- a jurisdiction willing to admit you;
- assets that remain spendable;
- credentials a new employer or school accepts;
- communication channels that survive platform pressure;
- family members who can also move;
- medical, linguistic and social support at the destination.
The further down the list you go, the more sovereignty becomes relational. Other people and institutions must recognise the exit.
## Exit and voice are not enemies
It is too easy to split the politics into state loyalists and crypto escape artists. Healthy institutions need both voice and exit. Voice without exit can become captivity. Exit without voice can become abandonment by the people best equipped to demand reform.
The distribution matters. A wealthy remote worker can route around a failing service. A carer, refugee, disabled resident or parent in a custody dispute may not. A design that calls both equally sovereign because both can generate a key has confused cryptographic capacity with practical option space.
This does not make portable identity or money unimportant. It makes the stronger test visible: **does the technology expand credible options for the people with the fewest?**
The best sovereignty tools may be the least theatrical ones—export, interoperability, recovery, non-discrimination, due process, and the ability to retain a history when changing providers.
Exit is valuable. But it is not the absence of trust. It is the construction of enough alternative trust relationships that one institution can no longer hold a life hostage.
### Further reading
- [The Network State](https://thenetworkstate.com/)
- [Albert O. Hirschman: Exit, Voice, and Loyalty](https://www.hup.harvard.edu/books/9780674276604)
src/content/stories/state-protects-privacy-and-sees-everything.md
+50
View File
@@ -0,0 +1,50 @@
---
title: "The state can protect your privacy and still see everything"
description: "China's national internet identity service reduces the need to hand civil-ID data to platforms by concentrating authentication in a public system."
published: 2026-07-14
editorialOrder: 13
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Government"
draft: false
tags: ["china", "internet-identity", "privacy", "centralisation"]
trustPattern:
claim: "A government internet number protects citizens by keeping real-name data away from private platforms."
trusted: "Users must trust the unified public service not to correlate, repurpose, compel, leak, or silently expand the authentication record."
failure: "Data minimisation at each platform can coincide with a more complete view at the centre."
---
China's national network identity authentication service began operating under final rules on 15 July 2025. A person can obtain an internet number and certificate derived from legal identity information. Participating services can verify the person without receiving their civil identity in plain text.
The privacy benefit is concrete. A platform that needs to confirm real identity need not store another copy of the user's document details. The official rules say participation is voluntary, platforms must retain alternative methods, and unnecessary identity data should not be collected.
The centralisation is equally concrete. Authentication that was previously fragmented among platforms can pass through one state-built service.
## Privacy from whom?
"Privacy-preserving" is incomplete without an adversary.
The internet number can improve privacy **from private platforms**. The platform receives a result rather than the underlying document. It may reduce leaks, overcollection and commercial reuse at that layer.
At the same time, the public service becomes a strategically important observer and dependency. The relevant questions concern logging, correlation, legal access, purpose limitation, deletion and whether voluntary adoption remains genuinely equal once the convenient route becomes normal.
This is not a uniquely Chinese paradox. Identity brokers, mobile operating systems and federated-login providers make the same bargain in different institutional settings: reveal less to many parties by trusting one party more.
## Do not average the trust
It is tempting to label the system either a privacy tool or surveillance infrastructure. It can be privacy-improving along one relationship and power-concentrating along another.
A useful audit therefore draws two data flows:
1. what the relying platform no longer receives;
2. what the central authentication service can now observe or compel.
The first is the product's benefit. The second is its constitution.
### Source
- [Cyberspace Administration of China: National Network Identity Authentication Public Service Measures](https://www.cac.gov.cn/2025-05/23/c_1749711107835487.htm)
src/content/stories/traceability-beats-transparency.md
+43
View File
@@ -0,0 +1,43 @@
---
title: "Traceability beats transparency"
description: "Making everything visible overwhelms the people meant to benefit. Linking decisions to actors and outcomes gives them something usable."
published: 2026-07-14
editorialOrder: 28
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Accountability"
draft: false
tags: ["traceability", "transparency", "accountability", "audit"]
trustPattern:
claim: "More disclosure makes institutions more trustworthy."
trusted: "The audience must trust selection, formatting, timing, completeness, and its own capacity to find the important fact in the disclosure."
failure: "Transparency can move the burden of investigation to the public while decision-makers remain insulated from consequence."
---
Transparency has a volume problem. An organisation can publish policies, meeting minutes, source code, impact reports and raw data until scrutiny becomes a specialised profession.
Nothing is technically hidden. Almost nothing is practically knowable.
Traceability asks for a narrower connection: who did what, under which authority, producing which outcome, with what route for challenge?
The distinction resembles the difference between an open kitchen and an ingredient label. Watching every movement may reveal more, but the person with an allergy needs a reliable statement tied to responsibility.
## Consequence needs an address
For a digital identity system, traceability may mean a user can see which relying party requested which attributes, which issuer signed them, which rule allowed the request, and where to report an abuse.
For an AI agent, it means connecting a tool call to an operator and a specific delegation. For a publication, it means a claim has an author, source, revision history and correction path.
This does not require making everyone's activity public. Radical transparency can destroy privacy, invite performance and advantage people with analytical resources. Traceability can be access-controlled, minimised and disclosed to affected parties.
## The maintenance advantage
Broad disclosure surfaces decay. Dashboards stop updating. Data schemas drift. Nobody reads the repository. Traceability can be built closer to the event: signed issuance, append-only logs, scoped receipts, version history.
It still needs institutions and review. Evidence does not interpret itself. But it gives disagreement an object.
The best trust systems do not promise that every observer can see everything. They make it difficult for consequential action to lose its author.
src/content/stories/trust-is-accepted-vulnerability.md
+59
View File
@@ -0,0 +1,59 @@
---
title: "Trust is accepted vulnerability"
description: "If nothing can be lost, betrayed or mishandled, you may have confidence, prediction or control—but you do not yet have trust."
published: 2026-07-14
editorialOrder: 8
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: true
section: "Theory"
frontTone: amend
draft: false
tags: ["trust", "vulnerability", "theory", "relationships"]
trustPattern:
claim: "Enough verification can remove the need to trust."
trusted: "Even a verified system depends on people choosing the specification, protecting exceptions, interpreting evidence, and bearing residual risk."
failure: "Calling residual vulnerability a technical defect can hide the person who was asked to accept it."
---
Trust is often sold as warmth: confidence, belonging, a reassuring check mark. Annette Baier offered a less comfortable definition. Trust is accepted vulnerability to another person's goodwill.
The vulnerability matters. If I cannot harm you, your reliance on me may be prediction. If a machine gives exactly one possible result, you may have confidence in the mechanism. Trust appears when another actor has room to disappoint, betray, neglect or reinterpret—and you proceed anyway.
This separates two conversations that technology likes to merge.
## Confidence in systems, trust in agents
I can have confidence that a signature verifies because the mathematics and implementation are reliable. I trust the maintainer not to ship a malicious update. I can verify that a credential came from a government issuer. I trust the official who decided which record was true and the process that corrects it.
Verification moves the boundary. It does not erase vulnerability.
"Trustless" systems usually reduce a particular discretionary relationship. A payment may no longer require one bank to approve a ledger entry. In exchange, participants rely on software, key custody, network consensus, economic incentives, governance and the assumption that the asset will remain meaningful to someone else.
The right question is not whether trust disappeared. It is where the power to disappoint moved.
## Vulnerability is distributed unevenly
The operator of an identity system risks fraud and regulatory liability. The user risks exclusion from work, money or travel. Both are risks, but they are not interchangeable.
Architecture diagrams flatten this difference. Boxes labelled issuer, wallet and verifier appear as peers. In life, one party may survive a 0.1 percent failure rate as a dashboard statistic while another experiences it as a lost week of wages.
Accepted vulnerability should therefore be specific:
- Who is vulnerable?
- To which action or omission?
- What would the loss mean to them?
- Did they have a real alternative?
- Who can repair the damage?
The language of trust becomes useful when it stops praising a system and starts locating exposure.
Trust is not bad. A life without accepted vulnerability would contain no friendship, delegation, credit, care or cooperation. The objective is not to remove it. It is to make vulnerability reciprocal where possible, bounded where necessary, and visible before the person with least power discovers it alone.
### Further reading
- [Annette Baier, “Trust and Antitrust”](https://doi.org/10.1086/292745)
- [Onora O'Neill: A Question of Trust](https://www.bbc.co.uk/radio4/reith2002/)
src/content/stories/trust-on-first-use.md
+45
View File
@@ -0,0 +1,45 @@
---
title: "The first connection is the dangerous one"
description: "SSH does not promise a global oracle for every server. It remembers the key it saw and becomes suspicious when reality changes."
published: 2026-07-14
editorialOrder: 18
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: historical
featured: false
homepage: false
section: "Security"
draft: false
tags: ["ssh", "tofu", "security", "keys"]
trustPattern:
claim: "Trust on first use securely identifies a remote host without central certification."
trusted: "The first connection, name-resolution path, key display, local known-hosts file, and user's response to warnings must all be trustworthy enough."
failure: "An attacker present at the first encounter can become the identity the system faithfully remembers."
---
The first time SSH connects to a server, it may not know the server's key. It shows a fingerprint, asks for a decision and records the result. On later connections, a changed key produces a warning.
This is trust on first use, or TOFU. It is not perfect identification. It is a small, honest mechanism for detecting change.
The weakness is in the name. The first use is trusted. An attacker who controls that first encounter can be remembered as the legitimate host. Users also learn to click through warnings, especially when servers are rebuilt and keys change for harmless reasons.
Yet TOFU has survived because it chooses a tractable problem. It does not attempt to build one global authority able to pre-certify every server. It creates local memory: *this is the key I saw for this name before*.
## Detection instead of omniscience
Many trustworthy systems work this way. They cannot prevent every bad state, so they make important changes observable. Certificate Transparency logs issued web certificates. Signal lets people compare safety numbers. File-integrity tools remember hashes.
The design pattern is modest:
1. establish a local reference;
2. preserve it;
3. warn clearly when it changes;
4. give the user a way to verify the new state;
5. do not make routine maintenance indistinguishable from attack.
TOFU's lesson is not to trust first encounters casually. It is that local continuity can sometimes outperform a grand certification system whose authority nobody understands.
### Further reading
- [OpenSSH manual: known hosts](https://man.openbsd.org/ssh_config#StrictHostKeyChecking)
src/content/stories/we-do-not-need-more-trust.md
+51
View File
@@ -0,0 +1,51 @@
---
title: "We do not need more trust"
description: "Calls to restore trust often ask the public to change its mood while leaving the reasons for distrust untouched."
published: 2026-07-14
editorialOrder: 24
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Theory"
draft: false
tags: ["trustworthiness", "institutions", "accountability", "theory"]
trustPattern:
claim: "Low public trust is a deficit that communication and transparency should repair."
trusted: "The institution asking for trust decides which evidence is visible, which criticism is reasonable, and whether declining confidence counts as a public failure."
failure: "A campaign for more trust can become pressure to ignore accurate signals of untrustworthiness."
---
Trust is down. Institutions worry about confidence. A campaign promises openness, publishes a dashboard and asks the public to believe again.
Onora O'Neill proposed a better objective: do not try to manufacture more trust. Build trustworthiness and support intelligent judgement.
The distinction is severe. Trust is something another person gives. Trustworthiness is a quality an actor must demonstrate. One can be requested with messaging. The other requires changing conduct, incentives and exposure to consequence.
## Transparency can increase fog
Institutions often respond by publishing more. Large disclosures can be technically transparent and practically illegible. The people with time, lawyers and analysts gain understanding; everyone else receives a wall of documents and a claim that nothing was hidden.
Accountability needs narrower connections:
- Who made the decision?
- What evidence supported it?
- Which interests were disclosed?
- Who bears the cost if it fails?
- How can an affected person challenge it?
These questions make trustworthiness assessable. They do not demand a positive answer.
## Distrust can be intelligent
Some distrust is prejudice, manipulation or trauma. Some is an accurate response to repeated experience. Treating all scepticism as a social pathology protects powerful actors from feedback.
A trustworthy system allows cautious participation. It limits the damage of betrayal, provides evidence, admits uncertainty and makes exit or appeal possible. It does not require warmth toward the institution.
The success metric is not how many people say they trust. It is whether people can make a competent decision about where reliance is warranted.
### Further reading
- [Onora O'Neill: A Question of Trust](https://www.bbc.co.uk/radio4/reith2002/)
src/content/stories/what-trust-issues-is-for.md
-45
View File
@@ -1,45 +0,0 @@
---
title: "What Trust Issues is for"
description: "A publication about authority that remains curious about systems and loyal to the people who must live inside them."
published: 2026-07-14
reviewed: 2026-07-14
author: "Ana"
maintainers:
- "Ana"
status: developing
featured: true
draft: false
tags:
- trust
- editorial
trustPattern:
claim: "Inspectability can make a publication more worthy of trust."
trusted: "Readers must still trust the author's judgement, sourcing, and willingness to correct the record."
failure: "Visible machinery can become theatre if review dates, challenges, and corrections are not honoured."
---
Every architecture diagram conceals a governance diagram. Somebody chooses the defaults, controls recovery, interprets the exception, or bears the loss when the elegant path stops working.
This publication follows those choices.
It begins with a friendly question: when a government, company, protocol, or autonomous system says something is verified, private, safe, self-sovereign, or trustless, **what does that mean here?**
That question is not an accusation. Sometimes the system is better than what came before. Sometimes a compromise is reasonable once it is named. Sometimes the marketing claim survives contact with reality. The point is to look.
## Authored, not anonymous
This is an independent publication by Ana. The writing should never hide behind the voice of an institution that does not yet exist.
Stories identify their author and, separately, their maintainer. Substantial corrections are visible. Review dates mean a human being performed a review. The public repository provides provenance, not a certificate of truth.
## People before machinery
Identity systems are usually described from the centre: issuers, wallets, verifiers, protocols, platforms. Their character is often clearest at the edge: the replaced phone, the changed name, the undocumented worker, the coercive partner, the delegated agent that acted beyond what its operator understood.
Technical systems matter. So do the lives they reorganise.
## A useful archive
The ambition is modest to state and difficult to earn: publish consistently, explain systems plainly, correct the record honestly, and leave behind an archive that becomes more useful with age.
No badge can establish that in advance. The work has to do it.
src/content/stories/who-sent-this-agent.md
+69
View File
@@ -0,0 +1,69 @@
---
title: "Who sent this agent?"
description: "An AI agent can have a name, a key and a polished voice while remaining unable to show who authorised the action it is taking now."
published: 2026-07-14
editorialOrder: 3
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: true
section: "Agents"
frontTone: paper
draft: false
tags: ["agents", "delegation", "authority", "security"]
image: "https://images.unsplash.com/photo-1691435828932-911a7801adfb?auto=format&fit=crop&w=1800&q=82"
imageAlt: "Ethernet cables connected to network equipment"
imageCredit: "Albert Stoynov"
imageCreditUrl: "https://unsplash.com/photos/a-close-up-of-a-network-with-wires-connected-to-it-dyUp7WPu5q4"
trustPattern:
claim: "An authenticated agent can safely act for its user."
trusted: "The service must trust the operator, model, tool descriptions, delegated credentials, policy layer, and evidence connecting this action to a human intention."
failure: "Authentication can prove which agent called while proving nothing about whether this particular action was authorised."
---
Suppose an agent emails an insurer, changes a booking, accepts a software licence, or transfers money. The receiving system can ask for a token. It can verify a signature. It may even know the agent's registered name.
None of those facts answers the first human question: **who sent it to do this?**
Identity and authority are easy to confuse because ordinary software keeps them close together. A person signs in; the application assumes actions in that session are theirs. Agents stretch the session across hours, tools and sub-agents. They transform an instruction, gather new context, and decide which intermediate actions appear necessary.
The distance between "I asked for help" and "the system did this" becomes a chain.
## Seven questions for one action
For any consequential agent action, ask:
1. What identifies the agent instance?
2. Who operates it?
3. Which person or organisation authorised it?
4. What exact actions were within scope?
5. Could it delegate again?
6. How could that authority be revoked?
7. What evidence remains afterward?
An API key answers perhaps one and a half of these. It identifies a credential and often an account. It rarely proves that the account holder intended the action, that the tool call remained inside the task, or that a delegated agent was forbidden from delegating again.
## Composability changes the threat
The modern agent is powerful because it can use tools. Tool descriptions enter its decision context. One tool may read a document, another may encode data, and a third may send a message. Each action can be legitimate in isolation while their composition creates an unauthorised disclosure.
This is why prompt-level permission language is not a security boundary. If a shell, browser or credential store remains technically reachable, an instruction saying "do not use it" is a behavioural preference. Real boundaries live in scoped tokens, sandboxes, policy enforcement, rate limits and human approval at the point of consequence.
The same applies to identity. Giving an agent a stable identifier does not make it accountable. Accountability requires a trace from actor to authority to action to outcome.
## The receipt we do not yet have
A useful agent receipt would say something like:
> Agent instance A, operated by service B, acted under delegation C from person D. The delegation allowed actions X and Y until time T, prohibited re-delegation, and was revoked at R. This action used tools M and N and produced result Z.
That is not a friendly consumer interface. It is the machinery from which a friendly interface could be built.
Until then, "AI agent" often names a capacity without naming an authority. The important question is not whether the agent is intelligent enough to act. It is whether everyone affected can establish why it was allowed to.
### Further reading
- [OAuth 2.0 Token Exchange, RFC 8693](https://www.rfc-editor.org/rfc/rfc8693)
- [NIST: AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
src/content/stories/why-digital-identity-projects-keep-dying.md
+50
View File
@@ -0,0 +1,50 @@
---
title: "Why digital identity projects keep dying"
description: "Passport, CardSpace, Persona and Web5 did not all fail for the same reason. Together they show that good identity architecture can still lose to habit."
published: 2026-07-14
editorialOrder: 15
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: historical
featured: false
homepage: false
section: "History"
draft: false
tags: ["identity", "microsoft", "persona", "web5"]
trustPattern:
claim: "A technically superior identity system will win once users understand its privacy and security benefits."
trusted: "Adoption depends on browser vendors, relying parties, defaults, integration cost, incentives, timing, and a reason for ordinary people to change behaviour."
failure: "The elegant system can remain unused while a cruder login button becomes infrastructure."
---
The identity industry has a graveyard full of respectable ideas.
Microsoft Passport tried to centralise internet login and personal data around Microsoft at the turn of the century. Backlash made the concentration legible. CardSpace later offered a more thoughtful identity selector across providers, but the simpler experience of federated login won. Mozilla Persona tried browser-centred email identity and could not solve relying-party adoption. Block's Web5 assembled decentralised identifiers and data nodes under a powerful brand, then was wound down in 2024.
These projects differ technically and politically. Their shared problem was not simply bad cryptography.
## Identity is a two-sided habit
A login system needs people to possess and understand it. It also needs services to accept it. Each side waits for the other. The incumbent—password reset, email link, Google button—already exists on both sides, however inelegant it may be.
That makes integration friction a governance force. A service chooses the identity option with libraries, support, fraud tooling and familiar recovery. Users choose the one already configured on their phone. Privacy gains arrive later and are hard to feel. Login failure arrives now.
The technically best architecture can therefore lose to the system with the shortest support queue.
## The useful question for a new wallet
Do not ask only whether the design improves control. Ask which repeated behaviour it makes easier on day one:
- What does a user accomplish faster?
- Why will a relying party integrate it before everyone has it?
- Who pays for recovery and fraud?
- Which old system can disappear?
- What happens when one major platform refuses?
Identity projects often pitch a new constitutional order while shipping a new login ceremony. The graveyard suggests reversing the order: earn one ordinary habit, then let the architecture prove what it protects.
### Further reading
- [Mozilla: Identity/Persona project archive](https://wiki.mozilla.org/Identity)
- [Block 2024 annual report](https://investors.block.xyz/financials/annual-reports-and-proxies/default.aspx)
src/content/stories/why-smart-people-join-high-trust-groups.md
+50
View File
@@ -0,0 +1,50 @@
---
title: "Why smart people join high-trust groups"
description: "Belonging, meaning and certainty can be genuine goods while the group quietly makes leaving each one more expensive."
published: 2026-07-14
editorialOrder: 27
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Belonging"
draft: false
tags: ["groups", "cults", "belonging", "exit"]
trustPattern:
claim: "A tightly bonded community protects members from an atomised and untrustworthy world."
trusted: "Members trust leaders, shared interpretations, social ties, information boundaries, and the group's account of outsiders and former members."
failure: "The same relationships that provide meaning can be restructured until doubt threatens a person's entire social and moral world."
---
High-control groups are often explained by stupidity or gullibility. This protects the observer: *I would notice*. It also misses what the group provides.
People enter during transitions, grief, isolation, migration, illness, political disorientation or a search for serious practice. A group offers attention, friends, language and a map. The benefits may be real.
The danger is not that every belief is false. It is that the benefits become load-bearing while alternatives are removed.
## Exit destruction
Control often grows gradually:
1. intense welcome establishes belonging;
2. the group's explanation organises confusing experience;
3. time and money commitments increase;
4. outside relationships weaken;
5. criticism becomes evidence that outsiders do not understand;
6. leaving threatens friends, purpose, identity and salvation at once.
Intelligence can make this worse. A skilled reasoner can defend a premise with extraordinary sophistication after the social cost of questioning it becomes high.
This is a trust architecture. The group centralises interpretation, concentrates social dependency and destroys alternative routes. Members may feel unusually safe inside because the boundary carries all uncertainty.
## Recovery begins with another world
Attacking beliefs directly can strengthen the boundary. A person may need an external relationship, housing, work and ordinary companionship before they can examine the system that supplied all four.
For people raised inside such a group, "return to your old identity" is meaningless. There may be no prior independent identity to restore. Leaving is construction, not recovery.
The useful warning sign is not unusual belief. It is shrinking option space: fewer outside relationships, fewer legitimate questions, fewer ways to leave without losing everything.
A trustworthy community can ask a great deal of its members. It must also preserve the conditions under which "no" remains thinkable.
src/content/stories/worldcoin-price-of-one-human.md
+65
View File
@@ -0,0 +1,65 @@
---
title: "Worldcoin and the price of one human"
description: "Proof of personhood answers a real AI-era problem. The Orb makes the bargain unusually visible: uniqueness in exchange for an irreversible measurement."
published: 2026-07-14
editorialOrder: 5
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: true
section: "Biometrics"
frontTone: paper
draft: false
tags: ["worldcoin", "biometrics", "proof-of-personhood", "privacy"]
image: "https://images.unsplash.com/photo-1665958465050-2c6f9727e10a?auto=format&fit=crop&w=1600&q=82"
imageAlt: "Extreme close-up of a human eye"
imageCredit: "Priscila Zovia"
imageCreditUrl: "https://unsplash.com/photos/close-up-of-a-persons-eye-kOyhxLvUw7Y"
trustPattern:
claim: "An iris-derived code can prove that one account belongs to one unique human without revealing that human's civil identity."
trusted: "Participants must trust the capture device, biometric processing, deletion and retention claims, uniqueness system, operators, governance, and future uses of the network."
failure: "A privacy-preserving proof can still begin with collection that is excessive, misunderstood, coerced by incentives, or impossible to replace after compromise."
---
The internet has a person problem. One human can create a thousand accounts. One agent can speak with a thousand human-sounding voices. Any system that distributes money, votes, attention or scarce access per person must decide what a person is and how many times they have arrived.
World's answer is the Orb. A participant looks into a specialised camera. The system analyses iris patterns and creates a World ID intended to prove uniqueness without publishing the participant's ordinary identity.
That is technically more interesting than "scan your eyes for crypto." It is also why the system deserves a more exact criticism.
## The claim is not facial recognition
Proof of personhood does not necessarily require attaching a name to a face. Its narrower objective is to stop one individual enrolling repeatedly. Cryptography can allow later proofs to reveal little more than "this is one enrolled human."
But privacy at presentation does not erase the enrollment ceremony. A biometric is not a password. If a password leaks, it can be replaced. Your iris is not waiting for a reset email.
The question therefore moves to the Orb, its software, the operator, the consent process, data retention, model training and the route for correcting a false match. The proof may be minimal while the trust surface is not.
## Regulators found the ceremony mattered
In 2024, Hong Kong's Privacy Commissioner concluded that Worldcoin's local operation had breached data-protection principles concerning collection, retention, transparency, access and correction. The investigation found 8,302 participants had undergone face and iris scanning. It considered the collection of face and iris images unnecessary and excessive for the stated purpose and objected to retention for up to ten years for model training.
Spain's data-protection authority separately ordered a temporary stop to collection and processing after complaints including insufficient information, collection involving minors and difficulty withdrawing consent.
These findings do not prove that private proof of personhood is impossible. They prove that a clever output does not excuse a bad input.
## Who needs one-human-one-account?
The strongest case for personhood proof is not universal login. It is a narrow system that truly allocates something per person and cannot tolerate duplicates. Even there, the operator should answer:
- Why is uniqueness necessary for this action?
- Must uniqueness persist across every action or only inside one community?
- Can a person enroll without creating a globally reusable identifier?
- What happens after a false duplicate result?
- Can the system survive without a token incentive that changes the meaning of consent?
The more universal the proof becomes, the more valuable its chokepoints become.
The Orb gives the internet a dramatic object on which to project its hopes and fears. The quieter issue is the architecture around it: which human problem actually requires global uniqueness, and who gains power when everybody accepts the same answer?
### Sources
- [Hong Kong Privacy Commissioner investigation](https://www.pcpd.org.hk/english/news_events/media_statements/press_20240522.html)
- [Spanish Data Protection Agency precautionary measure](https://www.aepd.es/en/press-and-communication/press-releases/agency-orders-precautionary-measure-which-prevents-Worldcoin-from-continuing-toprocess-personal-data-in-spain)
src/content/stories/your-wallet-has-a-government-inside-it.md
+54
View File
@@ -0,0 +1,54 @@
---
title: "Your wallet has a government inside it"
description: "The credential can sit on your phone while the rules about valid issuers, revocation and recovery remain thoroughly institutional."
published: 2026-07-14
editorialOrder: 11
reviewed: 2026-07-14
author: "Ana"
maintainers: ["Ana"]
status: developing
featured: false
homepage: false
section: "Governance"
draft: false
tags: ["wallets", "government", "governance", "issuers"]
trustPattern:
claim: "Holding a credential locally makes identity self-sovereign."
trusted: "Recognition still depends on issuer lists, certification, standards, revocation, registries, law, and the institutions that operate them."
failure: "Control of the container can be mistaken for control of the meaning and acceptance of what it contains."
---
A digital credential may live on your phone. You can choose when to present it. The private key may never leave secure hardware. These are meaningful forms of control.
They do not make the credential sovereign.
A university decides whether you earned the degree. A state decides whether the driving licence is valid. A professional body decides whether a qualification has been revoked. A verifier decides which issuers it accepts. A standard decides how the claim is expressed. Courts and regulators decide what happens during dispute.
The user controls a container inside a recognition system.
## Five layers of decentralisation
Calling a wallet decentralised compresses several questions into one:
- **Key custody:** who can use the credential?
- **Naming:** what binds a key or credential to a meaningful subject?
- **Discovery:** how does a verifier find keys, issuers and status information?
- **Recovery:** who restores access after loss?
- **Governance:** who changes rules and resolves disputes?
A system can be decentralised at one layer and centralised at another. Self-custodied keys may rely on a government issuer list. A decentralised identifier may resolve through a ledger governed by a small developer and validator community. An open-source wallet may be certified by a national authority.
None of these arrangements is automatically wrong. The problem is the adjective that hides their differences.
## Draw the second diagram
For every architecture diagram, draw a governance diagram. Put names beside the lists, standards, emergency switches and exception desks. Mark who can revoke an issuer, force an update, refuse a credential, recover an account and change the rules.
The result may show a reasonable public institution doing necessary work. That is a stronger argument than pretending the work disappeared because the credential moved to an edge device.
Your wallet can be private, useful and user-controlled while still having a government inside it. In a government credential, that may be exactly what gives the claim value. It should also be exactly what the interface makes legible.
### Further reading
- [EUDI Architecture and Reference Framework](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework)
- [Regulation (EU) 2024/1183](https://eur-lex.europa.eu/eli/reg/2024/1183/oj)
src/layouts/ArticleLayout.astro
+34
View File
@@ -13,6 +13,10 @@ interface Props {
reviewed: Date;
status: 'developing' | 'disputed' | 'resolved' | 'historical';
sourcePath: string;
image?: string;
imageAlt?: string;
imageCredit?: string;
imageCreditUrl?: string;
trustPattern?: {
claim: string;
trusted: string;
@@ -39,6 +43,16 @@ const props = Astro.props;
/>
<TrustPattern pattern={props.trustPattern} />
</header>
{props.image && (
<figure class="article-image">
<img src={props.image} alt={props.imageAlt ?? ''} />
{props.imageCredit && (
<figcaption>
Photo: {props.imageCreditUrl ? <a href={props.imageCreditUrl}>{props.imageCredit}</a> : props.imageCredit}
</figcaption>
)}
</figure>
)}
<div class="article-body prose">
<slot />
</div>
@@ -74,4 +88,24 @@ const props = Astro.props;
.article-body {
margin-top: clamp(3rem, 7vw, 6rem);
}
.article-image {
width: 100%;
margin: clamp(2.5rem, 6vw, 5rem) 0 0;
}
.article-image img {
width: 100%;
max-height: 680px;
object-fit: cover;
}
.article-image figcaption {
padding-top: 0.55rem;
color: var(--muted);
font-family: 'IBM Plex Mono', monospace;
font-size: 0.62rem;
text-align: right;
text-transform: uppercase;
}
</style>
src/pages/index.astro
+56 -93
View File
@@ -2,7 +2,6 @@
import { getCollection } from 'astro:content';
import FrontCard from '../components/FrontCard.astro';
import BaseLayout from '../layouts/BaseLayout.astro';
import { guidesByReview, newestFirst } from '../lib/content';
import { site } from '../site.config';
interface FrontPageItem {
@@ -17,99 +16,23 @@ interface FrontPageItem {
tone: 'paper' | 'blue' | 'ink' | 'soft' | 'amend';
}
const stories = newestFirst(await getCollection('stories', ({ data }) => !data.draft));
const briefings = newestFirst(await getCollection('briefings', ({ data }) => !data.draft));
const guides = guidesByReview(await getCollection('guides', ({ data }) => !data.draft));
const episodes = newestFirst(await getCollection('episodes', ({ data }) => !data.draft));
const featured = stories.find(({ data }) => data.featured) ?? stories[0];
const latestBriefing = briefings[0];
const frontPageItems: FrontPageItem[] = [];
if (featured) {
frontPageItems.push({
kind: 'Story',
title: featured.data.title,
description: featured.data.description,
href: `/stories/${featured.id}`,
date: featured.data.published,
meta: `By ${featured.data.author} · ${featured.data.status}`,
image: featured.data.image,
imageAlt: featured.data.imageAlt,
tone: featured.data.image ? 'paper' : 'blue',
});
}
if (latestBriefing) {
frontPageItems.push({
kind: `Briefing ${String(latestBriefing.data.issue).padStart(3, '0')}`,
title: latestBriefing.data.title,
description: latestBriefing.data.description,
href: `/briefing/${latestBriefing.id}`,
date: latestBriefing.data.published,
meta: 'This Week in Trust',
tone: 'paper',
});
}
const remainingItems: FrontPageItem[] = [
...stories
.filter((entry) => entry.id !== featured?.id)
.map((entry, index): FrontPageItem => ({
kind: 'Story',
title: entry.data.title,
description: entry.data.description,
href: `/stories/${entry.id}`,
date: entry.data.published,
meta: `By ${entry.data.author} · ${entry.data.status}`,
image: entry.data.image,
imageAlt: entry.data.imageAlt,
tone: entry.data.image ? 'paper' : index % 2 === 0 ? 'soft' : 'paper',
})),
...briefings.slice(1).map((entry): FrontPageItem => ({
kind: `Briefing ${String(entry.data.issue).padStart(3, '0')}`,
const stories = (await getCollection('stories', ({ data }) => !data.draft))
.sort((a, b) => a.data.editorialOrder - b.data.editorialOrder);
const toneCycle = ['blue', 'paper', 'ink', 'soft', 'amend', 'paper'] as const;
const frontPageItems: FrontPageItem[] = stories
.filter(({ data }) => data.homepage)
.slice(0, 9)
.map((entry, index) => ({
kind: entry.data.section,
title: entry.data.title,
description: entry.data.description,
href: `/briefing/${entry.id}`,
date: entry.data.published,
meta: 'This Week in Trust',
tone: 'paper',
})),
...episodes.map((entry): FrontPageItem => ({
kind: `Podcast ${String(entry.data.episode).padStart(2, '0')}`,
title: entry.data.title,
description: entry.data.description,
href: `/podcast/${entry.id}`,
date: entry.data.published,
meta: [entry.data.duration, ...entry.data.guests].filter(Boolean).join(' · '),
tone: 'ink',
})),
...guides.map((entry): FrontPageItem => ({
kind: 'Field guide',
title: entry.data.title,
description: entry.data.description,
href: `/guides/${entry.id}`,
date: entry.data.reviewed,
meta: `Reviewed · ${entry.data.status}`,
tone: 'soft',
})),
].sort((a, b) => (b.date?.valueOf() ?? 0) - (a.date?.valueOf() ?? 0));
if (site.book.enabled) {
remainingItems.unshift({
kind: 'Book',
title: site.book.title,
description: site.book.description,
href: '/book',
meta: site.book.sampleUrl ? 'Sample available' : undefined,
image: site.book.cover || undefined,
imageAlt: site.book.cover ? `${site.book.title} cover` : undefined,
tone: site.book.cover ? 'paper' : 'amend',
});
}
frontPageItems.push(...remainingItems);
href: `/stories/${entry.id}`,
date: index === 0 ? entry.data.published : undefined,
meta: entry.data.tags.slice(0, 2).join(' · '),
image: entry.data.image,
imageAlt: entry.data.imageAlt,
tone: entry.data.frontTone ?? (entry.data.image ? 'paper' : toneCycle[index % toneCycle.length]),
}));
const sizeCycle = ['wide', 'standard', 'compact', 'compact', 'compact'] as const;
---
@@ -117,7 +40,7 @@ const sizeCycle = ['wide', 'standard', 'compact', 'compact', 'compact'] as const
<BaseLayout>
<section class="front-grid shell" aria-labelledby="front-page-title">
<h1 class="visually-hidden" id="front-page-title">{site.title}</h1>
{frontPageItems.slice(0, 12).map((item, index) => (
{frontPageItems.map((item, index) => (
<FrontCard
kind={item.kind}
title={item.title}
@@ -132,6 +55,9 @@ const sizeCycle = ['wide', 'standard', 'compact', 'compact', 'compact'] as const
/>
))}
</section>
<div class="more-stories shell">
<a href="/stories">Read more <span>{Math.max(0, stories.length - frontPageItems.length)} more stories</span></a>
</div>
</BaseLayout>
<style>
@@ -144,6 +70,43 @@ const sizeCycle = ['wide', 'standard', 'compact', 'compact', 'compact'] as const
background: var(--rule);
}
.more-stories {
display: flex;
justify-content: center;
padding: clamp(1.5rem, 4vw, 3rem) 0 0;
}
.more-stories a {
display: inline-flex;
min-width: min(100%, 320px);
align-items: center;
justify-content: space-between;
gap: 2rem;
padding: 0.9rem 1rem;
border: 1px solid var(--ink);
font-size: 0.84rem;
font-weight: 650;
text-decoration: none;
}
.more-stories a:hover {
background: var(--ink);
color: var(--paper);
}
.more-stories span {
color: var(--muted);
font-family: 'IBM Plex Mono', monospace;
font-size: 0.62rem;
font-weight: 400;
letter-spacing: 0.04em;
text-transform: uppercase;
}
.more-stories a:hover span {
color: inherit;
}
:global(#main + footer) {
margin-top: clamp(2.5rem, 6vw, 5rem);
}
src/pages/rss.xml.ts
+6 -1
View File
@@ -15,20 +15,25 @@ export async function GET(context: { site?: URL }) {
description: entry.data.description,
pubDate: entry.data.published,
link: `/stories/${entry.id}`,
editorialOrder: entry.data.editorialOrder,
})),
...briefings.map((entry) => ({
title: entry.data.title,
description: entry.data.description,
pubDate: entry.data.published,
link: `/briefing/${entry.id}`,
editorialOrder: 1_000,
})),
...episodes.map((entry) => ({
title: entry.data.title,
description: entry.data.description,
pubDate: entry.data.published,
link: `/podcast/${entry.id}`,
editorialOrder: 1_000,
})),
].sort((a, b) => b.pubDate.valueOf() - a.pubDate.valueOf());
]
.sort((a, b) => b.pubDate.valueOf() - a.pubDate.valueOf() || a.editorialOrder - b.editorialOrder)
.map(({ editorialOrder: _editorialOrder, ...item }) => item);
return rss({
title: `${site.title} ${site.qualifier}`,
src/pages/stories/[id].astro
+5 -1
View File
@@ -15,7 +15,7 @@ const { Content } = await render(entry);
<ArticleLayout
title={entry.data.title}
description={entry.data.description}
kind="Story"
kind={entry.data.section}
author={entry.data.author}
maintainers={entry.data.maintainers}
published={entry.data.published}
@@ -23,6 +23,10 @@ const { Content } = await render(entry);
status={entry.data.status}
sourcePath={`src/content/stories/${entry.id}.md`}
trustPattern={entry.data.trustPattern}
image={entry.data.image}
imageAlt={entry.data.imageAlt}
imageCredit={entry.data.imageCredit}
imageCreditUrl={entry.data.imageCreditUrl}
>
<Content />
</ArticleLayout>
src/pages/stories/index.astro
+51 -9
View File
@@ -2,24 +2,66 @@
import { getCollection } from 'astro:content';
import StoryCard from '../../components/StoryCard.astro';
import BaseLayout from '../../layouts/BaseLayout.astro';
import { newestFirst } from '../../lib/content';
const stories = newestFirst(await getCollection('stories', ({ data }) => !data.draft));
const stories = (await getCollection('stories', ({ data }) => !data.draft))
.sort((a, b) => a.data.editorialOrder - b.data.editorialOrder);
---
<BaseLayout title="Stories" description="Reported and argued stories about trust, identity, and authority.">
<section class="shell archive-head">
<p class="eyebrow">Original reporting and essays</p>
<h1 class="display">Stories</h1>
<p>People first. Machinery explained. Claims followed to the point where somebody must decide, recover, consent, or bear the loss.</p>
<h1>Stories</h1>
<p>{stories.length} reports, histories and essays <span>First collection</span></p>
</section>
<section class="shell archive-list">
{stories.length > 0 ? stories.map((entry) => <StoryCard entry={entry} />) : <p class="empty-state">The first story is being prepared.</p>}
{stories.length > 0 ? stories.map((entry, index) => <StoryCard entry={entry} index={index} />) : <p class="empty-state">The first story is being prepared.</p>}
</section>
</BaseLayout>
<style>
.archive-head { padding: clamp(4rem, 9vw, 8rem) 0; }
.archive-head > p:last-child { max-width: 58ch; color: var(--muted); font-size: 1.05rem; }
.archive-list { display: grid; gap: 2rem; }
.archive-head {
display: flex;
align-items: baseline;
justify-content: space-between;
gap: 1.5rem;
padding: clamp(1.6rem, 4vw, 3.25rem) 0 1rem;
border-bottom: 1px solid var(--ink);
}
.archive-head h1 {
margin: 0;
font-family: 'Newsreader Variable', Georgia, serif;
font-size: clamp(2.4rem, 5vw, 4.5rem);
font-weight: 560;
letter-spacing: -0.045em;
line-height: 0.9;
}
.archive-head p {
margin: 0;
color: var(--muted);
font-family: 'IBM Plex Mono', monospace;
font-size: 0.65rem;
text-transform: uppercase;
}
.archive-head span { margin-left: 1rem; }
.archive-list {
display: grid;
grid-template-columns: repeat(3, minmax(0, 1fr));
gap: 1px;
margin-top: 1px;
border: 1px solid var(--rule);
background: var(--rule);
}
@media (max-width: 900px) {
.archive-list { grid-template-columns: repeat(2, minmax(0, 1fr)); }
}
@media (max-width: 620px) {
.archive-head { align-items: flex-start; flex-direction: column; gap: 0.65rem; }
.archive-head span { display: none; }
.archive-list { grid-template-columns: 1fr; }
}
</style>