HumanKey

The Internet Was Never Designed to Count People

Most internet authentication systems answer some version of the same question: Can you prove that you control this credential?

That credential might be an email address, phone number, password, authentication application, OAuth account, security key, device, or passkey. Those systems can be extremely secure, but they still prove control of a credential. They do not prove human uniqueness.

A platform can verify ten email addresses without knowing whether those addresses belong to ten humans or one human. Credential uniqueness is not human uniqueness.

On most platforms, creating another identity is cheap. Create another email address. Buy another phone number. Clear the browser. Use another device. Change the IP address. Register another username. The credential changes. The human does not.

HumanKey moves the uniqueness boundary from the credential to the person.

We Are Already Sharing the Internet With More Machines Than Humans

Automation itself is not bad. Search engines, businesses, security systems, and accessibility tools all use automation. The problem begins when automated systems impersonate independent human participants.

According to Imperva's 2026 Bad Bot Report, automated systems accounted for more than 53 percent of global web traffic during 2025. Human traffic represented approximately 47 percent.

Artificial intelligence makes this considerably more important. The old bot was obvious. Those clues are disappearing. A capable automated persona can intentionally make mistakes, use slang, wait before responding, remember conversations, disagree with another bot, and maintain a fictional history.

Trying to determine whether somebody is human solely by examining what they write is going to become increasingly unreliable. HumanKey takes the opposite approach. Instead of asking whether content looks human, it asks whether the participation identity was established by a unique living human.

The Real Problem Is Not Bots. It Is Synthetic People.

There is an important difference between automation and synthetic identity. A bot that retrieves weather information is automation. A bot pretending to be an ordinary citizen while arguing about a public issue is something entirely different. That is a synthetic person.

Synthetic people become far more dangerous when they operate in groups. Five hundred apparently unrelated accounts supporting the same position can create a powerful social signal. If those accounts belong to one operator, the crowd exists only on the screen.

That is synthetic consensus.

Duplicate Accounts Distort Almost Everything

Duplicate accounts are not a minor moderation problem. They corrupt the meaning of the social graph itself.

They can manipulate follower counts, likes, polls, comments, reports, trends, hashtags, apparent popularity, apparent opposition, political enthusiasm, product popularity, and community sentiment.

They also enable ban evasion, reputation resets, harassment through alternate accounts, sockpuppeting, account farming, fake grassroots support, manufactured customers, and manufactured fans.

What a Bot Farm Can Actually Do

A bot farm does not need to convince everybody. It only needs to alter the environment around the conversation.

A coordinated network can introduce a narrative, repeat it through apparently unrelated accounts, like and share those accounts, attack competing narratives, create the appearance of momentum, expose genuine humans to the content, and encourage genuine humans to continue the amplification.

The machine does not need to replace human opinion. It only needs to influence the environment in which human opinion develops.

Russian Influence Operations

In July 2024, the United States Department of Justice announced action against a Russian government-linked social media bot farm involving 968 fictitious accounts. The operation incorporated artificial intelligence and created false personas that frequently purported to belong to people in the United States.

Those personas were used to distribute narratives supporting Russian government objectives.

A message openly issued by a foreign government is interpreted one way. The same message apparently coming from hundreds of ordinary Americans is interpreted another way. That difference is exactly why synthetic identities have value.

Chinese Influence Operations

The United States Department of Justice has documented another example involving China's Ministry of Public Security. Federal prosecutors alleged that members of the 912 Special Project Working Group created thousands of fake social media personas. Some purported to be Americans.

According to DOJ, those personas were used to promote PRC narratives, attack critics, harass dissidents, and create the appearance that ordinary users supported positions favored by the Chinese government.

The technological change is the ability to surround propaganda with synthetic citizens.

Manufacturing Consensus

The traditional internet account model makes identity multiplication economically attractive.

Without proof of personhood, one operator plus automation plus 10,000 credentials can appear to be 10,000 humans.

HumanKey changes the resource requirement. The security objective is straightforward: 10,000 independent HumanKey identities should require something approaching 10,000 independently enrolled humans.

That does not eliminate coordinated movements. Ten thousand real people can still organize. What changes is the ability of one person to impersonate those 10,000 people.

Hash Humanity

Hash Humanity begins with a different assumption about social media. People should not have to compete with unlimited artificial identities simply to have a conversation.

The platform is built around one human, one account; human verification without mandatory public identification; persistent identity; no engagement-ranking algorithm designed to maximize provocation; no behavioral advertising dependency; and freedom of human expression.

HumanKey proves humanity and uniqueness. It does not determine whether somebody's opinion is correct.

HumanKey Architecture

HumanKey separates security problems that are often incorrectly treated as one problem: live presence, biometric uniqueness, privacy-preserving membership, routine authentication, recovery, and abuse resistance.

The protocol asks whether a live person is physically participating, whether that person appears to have enrolled already, whether the person can later demonstrate valid HumanKey membership without exposing the underlying biometric record, whether the established human can authenticate securely through a passkey, and whether that human can recover the same identity after losing authentication credentials.

No single component is expected to solve the entire problem. HumanKey uses layers, and the security boundary between those layers matters. A successful liveness result does not by itself create a social account. A biometric match does not by itself authorize arbitrary actions. A zero-knowledge proof does not replace passkey authentication. Each component answers a narrower question.

Consent Comes First

HumanKey does not treat access to a camera as permission to conduct biometric processing.

Biometrics are sensitive. HumanKey therefore gates biometric operations behind the required consent state. The implementation includes automated tests covering consent gating and invalid session behavior.

Liveness

HumanKey uses AWS Face Liveness as its production liveness provider. The purpose is to determine whether a live participant is physically present rather than simply accepting a facial image.

HumanKey's implemented policy has used a liveness confidence threshold of 85.

Liveness makes attacks involving photographs, displayed images, prerecorded material, and other presentation techniques more difficult. It is one part of a larger security system and is not presented as mathematically infallible.

What Happens to the Face

HumanKey does process a person's face. There is no honest way to perform facial biometric comparison without processing facial information.

AWS Rekognition collections store mathematical face vectors used for comparison rather than the source face images themselves. Those vectors are still biometric information and HumanKey treats them as sensitive.

The privacy distinction is not that biometrics disappear. The distinction is that persistent uniqueness comparison can rely on a mathematical biometric representation instead of treating the enrollment record as a public photograph. HumanKey therefore separates public social identity from the underlying biometric uniqueness layer.

Duplicate Detection

After liveness succeeds, HumanKey compares the candidate against the enrolled biometric population. The production AWS path has used SearchUsersByImage with a UserMatchThreshold of 90.0.

If the candidate strongly corresponds to an existing HumanKey participant, the system does not simply issue another identity. The event becomes duplicate protection or account recovery depending upon context.

For a new unique participant, the AWS enrollment path includes creation of the Rekognition user and facial association process.

HumanKey's current production policy uses a UserMatchThreshold of 90.0. That number is an application configuration rather than a universal biometric accuracy guarantee. Face matching is probabilistic, so the threshold remains subject to empirical calibration, adversarial testing, demographic performance evaluation, and production monitoring.

This is the heart of HumanKey's duplicate-account resistance.

Why Duplicate Resistance Matters So Much

A banned user on a conventional platform can create another email address. A scammer can abandon a damaged reputation. A harasser can create five accounts. A political operator can create hundreds of credentials.

HumanKey changes that equation. Another email address does not create another face. Another browser does not create another human. Another phone does not create another human. Another IP address does not create another human.

The uniqueness check follows the human rather than the credential.

That dramatically raises the cost of sockpuppeting, account farming, ban evasion, harassment through alternate accounts, follower inflation, poll manipulation, reputation resets, fake grassroots campaigns, coordinated artificial amplification, and manufactured consensus.

This is not merely a login feature. It changes what an account means.

Zero-Knowledge Membership

Establishing that a person is a unique human creates an immediate privacy question. If biometric information is used during enrollment, should the social platform need access to that biometric information every time the person participates?

No.

HumanKey separates establishment of humanity from later proof of membership.

HumanKey uses Semaphore components for its zero-knowledge membership layer. A Semaphore identity contains private cryptographic material controlled by the participant and a public identity commitment derived from that identity.

The public commitment can be added to a Semaphore group without publishing the participant's underlying identity secret. Semaphore groups are represented with Merkle trees whose leaves contain member identity commitments.

Membership in that tree can later be proven with a zero-knowledge proof.

Conceptually, the proof demonstrates that the participant controls an identity whose commitment exists inside the authorized HumanKey group. The verifier can validate group membership without requiring the participant to reveal which specific member of the group generated the proof.

The witness used to construct the proof contains the information necessary to demonstrate membership, including the participant's private identity material and the Merkle path that proves the corresponding commitment belongs to the current group tree. Those private values are inputs to proof generation rather than values that need to be publicly disclosed.

The verifier instead works with public proof information such as the applicable Merkle root, the proof itself, signal or message information when used, and the nullifier information required by the particular action.

This creates an important architectural boundary. Biometrics answer the enrollment question: is this a live and sufficiently unique human? Zero-knowledge membership can answer a later authorization question: is this participant a member of the authorized human set?

Those should not be treated as the same operation.

HumanKey therefore does not require a new biometric comparison merely to prove ordinary membership. Once enrollment is complete, routine authentication can be performed with passkeys and eligible privacy-preserving actions can use the zero-knowledge membership layer.

Zero knowledge also does not magically make the surrounding application anonymous. IP addresses, timestamps, browser characteristics, account identifiers, application logs, network metadata, and behavioral patterns can create linkability independently of the cryptographic proof.

HumanKey's privacy model therefore depends not only on the proof system but also on disciplined handling of application metadata and deliberate separation between biometric enrollment records, cryptographic membership material, authentication credentials, and public social identity.

Nullifiers and Scoped Accountability

Anonymous or pseudonymous membership creates another problem. A system may need to allow a valid human to perform an action while preventing that same valid member from performing the identical restricted action repeatedly.

Nullifiers provide a mechanism for enforcing that constraint without requiring the member's legal identity to become public.

A nullifier is associated with the participant's cryptographic identity and an external scope defined by the application.

The scope is important. HumanKey should not use one universal nullifier for unrelated activities because doing so could unnecessarily make separate actions linkable.

Instead, an application can define a specific scope for an operation. Examples might include one vote in a particular poll, one registration action, or another event where the system requires one eligible member to act only once.

When the same eligible member attempts to signal twice within the same protected scope, the verifier can detect reuse of the corresponding nullifier and reject the second action.

This provides an important distinction between anonymity and absence of accountability. HumanKey can support privacy-preserving membership while still enforcing rules against duplicate scoped actions.

Passkeys and Routine Authentication

A person should not need to perform biometric enrollment every time they sign into Hash Humanity.

Once HumanKey establishes the human and binds the resulting participation identity, routine authentication moves to passkeys using WebAuthn public-key cryptography.

The private credential key remains with the user's authenticator or credential provider. HumanKey stores the information necessary to verify the resulting public-key assertion rather than storing the participant's private authentication key.

Every authentication ceremony requires a server-generated challenge. The returned assertion must correspond to the expected challenge and relying-party context before authentication succeeds.

Challenges must be short-lived and single-use. Once consumed, the server must reject reuse. This is part of HumanKey's replay-protection model.

WebAuthn also binds passkeys to a relying-party domain and includes origin information in the authentication ceremony. Correct server-side verification therefore includes validating the expected relying-party ID, origin, challenge, credential, and signature.

This separation reduces unnecessary biometric processing while giving routine authentication the phishing-resistant properties of origin-bound public-key credentials.

Account Recovery

Recovery is not an afterthought in HumanKey. It is one of the most important security boundaries in the protocol.

A user can lose a phone. A computer can fail. A passkey can be deleted. An authenticator can become inaccessible. The human still exists.

HumanKey follows a simple recovery principle: Recover the human. Do not recreate the human.

Enrollment asks whether this is a new unique human. Recovery asks whether this is the human who already owns an existing HumanKey. Those are completely different operations.

The HumanKey Recovery Process

Recovery does not intentionally create another HumanKey identity. The same human returns to the same account.

The One-Scan Recovery Design

During development, a recovery problem was identified where facial verification could occur twice. That was not the intended architecture.

Recovery should require one live biometric ceremony for the recovery event. The corrected design allows the successful liveness result to continue through identity resolution rather than automatically requiring another redundant scan.

This reduces unnecessary biometric processing, user friction, provider calls, and the possibility of conflicting biometric state.

Recovery Preserves One Human, One Account

Recovery therefore reinforces HumanKey's Sybil resistance rather than bypassing it.

Recovery Failure

A failed recovery match must not become a shortcut to creating another account.

If the system cannot establish a sufficiently strong relationship with an existing HumanKey, the correct result is controlled failure or retry.

Security-sensitive ambiguity should fail closed. HumanKey development has also included handling for stale biometric-only states so legitimate users are not incorrectly trapped by inconsistent identity state.

Recovery Security Testing

The test run followed investigation of the redundant face-scan behavior. When the corrective patch was subsequently checked, the implementation reported that the relevant correction was already present and no additional file changes were required.

The regression suite completed 10 passed and 0 failed. This does not mean HumanKey can never contain another bug. It means every test in that recovery regression suite passed at that point in development.

Broader HumanKey Testing

Recovery is only one part of the testing program.

Testing has covered biometric consent, AWS gating, invalid sessions, required capture state, recovery, duplicate detection, provider response handling, biometric searching, passkey authorization, replay protection, state transitions, calibration, multi-template behavior, rate limiting, and blocked attempts.

The purpose of the test suite is not merely to prove that legitimate enrollment works. A security system must also prove that invalid operations do not work.

Rate Limiting

Proof of personhood does not make humans harmless. A real human can spam, scrape, automate activity, or attack an API.

HumanKey combines identity scarcity with rate controls. Implemented safeguards have included 3 applicable liveness attempts within a 24-hour control window, a 60-second cooldown, a 500-per-day global AWS liveness ceiling, HTTP 429 rejection, idempotency protections, an administrative kill switch, and automated blocked-attempt testing.

Proof of personhood limits identity multiplication. Rate limiting limits action multiplication.

Replay Protection

A successful security ceremony should not become a permanent reusable ticket.

This principle applies to passkey challenges, enrollment sessions, recovery sessions, and other one-time authorization artifacts. Security-sensitive results should be bound to the expected session or challenge, expire within a defined window, and become unusable after successful consumption.

Server-Side Authority

The browser is not trusted to decide whether somebody is human.

A malicious user controls their browser. They can modify JavaScript, alter requests, manipulate local storage, and bypass interface screens.

Security decisions therefore belong on the server. The interface can request a state transition. The server determines whether the transition is valid.

HumanKey's server-side authority model treats client state as untrusted input. Enrollment stage, liveness completion, uniqueness status, recovery authorization, passkey challenge state, proof validation, and replay state must be checked against authoritative server-side records before sensitive transitions are accepted.

Software Architecture

HumanKey and Hash Humanity use different technologies for different jobs.

HumanKey uses Python for biometric and security service logic and testing, FastAPI for the API layer, Pydantic for structured validation, AWS Face Liveness for production liveness verification, AWS Rekognition for production biometric uniqueness and matching, Semaphore components for zero-knowledge membership, and passkeys for cryptographic routine authentication.

Hash Humanity uses React, JavaScript and JSX, HTML, CSS, and Firebase for appropriate application, hosting, account, and real-time functionality.

The biometric authority is deliberately separated from the presentation layer. That separation reduces the amount of security-critical trust placed in browser code and allows biometric, proof, authentication, and social application responsibilities to be reasoned about independently.

Language Accessibility

A human network should not define humanity according to language.

Hash Humanity has been developed with internationalization support including English, Spanish, Portuguese, Chinese, German, French, Malay, and Korean.

The HumanKey white paper is published using separate crawlable language URLs with localized metadata so people and search engines can reach the same technical material in supported languages without changing the meaning of the protocol.

If the objective is a human social network, geographical and linguistic boundaries should not determine who can participate in the conversation.

Security Threat Model

HumanKey considers several attacker classes.

Automated bot: attempts participation without a legitimate human. Defense includes liveness, server-side enrollment state, and identity controls.

Single-human Sybil attacker: attempts to create many identities. Primary defense is biometric uniqueness.

Account farm: attempts to manufacture large numbers of verified accounts. Defenses include liveness, uniqueness, and rate limits.

Presentation attacker: attempts photographs or prerecorded imagery. Defense is AWS Face Liveness.

Credential attacker: attempts to steal login access. Defense is passkey public-key authentication plus correct challenge, RP ID, origin, credential, and signature validation.

Replay attacker: attempts to reuse previously valid security artifacts. Defenses include expiry, consumption state, challenge binding, and server-side transitions.

Ban evader: attempts to return under another identity. Defense is persistent biometric uniqueness.

Influence operation: attempts to manufacture thousands of apparent independent citizens. Defense is changing the scarce resource from accounts to actual humans.

Metadata correlation attacker: attempts to link supposedly private proof activity through IP addresses, timing, application identifiers, logging, or behavioral patterns. Mitigation depends on minimizing unnecessary metadata and maintaining separation between biometric enrollment, proof membership, authentication, and public social identity.

False biometric match or non-match: probabilistic biometric systems can produce errors. Mitigation requires threshold calibration, recovery safeguards, testing, monitoring, and a fail-closed posture for security-sensitive ambiguity.

What HumanKey Does Not Do

HumanKey does not determine truth.

A verified human can still lie, spread misinformation, be paid, participate in propaganda, harass somebody, or simply be an asshole.

HumanKey does not attempt to technologically sanitize humanity. The protocol addresses a narrower problem: one human should not cheaply become a hundred apparent humans.

Human disagreement remains. Synthetic population is what becomes dramatically harder.

Why That Difference Matters

Consider two platforms.

Platform A allows one human to create fifty accounts.

Platform B restricts one human with high confidence to one persistent identity.

Both platforms contain imperfect people, but they do not have the same social dynamics. On Platform A, one attacker can appear to be fifty people. On Platform B, fifty identities should require something approaching fifty enrolled humans.

That changes reputation, moderation, polls, voting, follower counts, harassment, ban enforcement, community governance, apparent popularity, political organization, and synthetic consensus.

Toward a Social Graph of Humans

Most social networks contain graphs of credentials. HumanKey attempts to create something closer to a graph of people.

If ten conventional accounts disagree with you, you cannot automatically know whether ten people disagree with you. It might be ten. It might be five. It might be one.

If ten valid HumanKey identities disagree with you, the architecture is specifically designed to provide substantially stronger evidence that ten independently enrolled humans are represented.

That does not make them right. It makes them real participants.

Current Validation Status

These results represent the implementation and testing status documented at the time of this white paper. They should change as the system changes.

These results describe implementation status and internal regression testing. They do not constitute an independent penetration test, third-party biometric accuracy certification, cryptographic audit, privacy audit, or proof that the system is free of vulnerabilities. Independent review remains part of the security work required before HumanKey should be treated as a mature production identity protocol.

Security Is Never Finished

No legitimate security engineer should claim that passing a test suite makes a system permanently secure.

Attackers change. Providers change. Dependencies change. Browsers change. Artificial intelligence changes.

HumanKey therefore requires continuing regression testing, adversarial testing, provider monitoring, dependency maintenance, threshold calibration, penetration testing, privacy review, cryptographic review, abuse monitoring, incident response, and threat-model revision.

The goal is not to claim that HumanKey is impossible to defeat. The goal is to make defeating one-human-one-account dramatically more difficult and expensive than simply creating another internet account.

Where This Is Going

Artificial intelligence is going to become better at pretending to be us. That is not science fiction. It is already happening.

Synthetic text will improve. Synthetic photographs will improve. Synthetic video will improve. Autonomous agents will improve. Persona management will improve.

Eventually, asking whether a message sounds human will tell us almost nothing about whether a human actually produced it.

So the question has to change.

That is the problem HumanKey was built to address.

Conclusion

The internet does not have a shortage of accounts. It has a shortage of confidence in what those accounts actually represent.

Machines now generate the majority of measured web traffic. Governments have deployed fake social media personas. Bot farms have impersonated citizens. Disposable accounts enable harassment, fraud, ban evasion, artificial popularity, account farming, and manufactured consensus. Artificial intelligence is making those operations cheaper and more convincing.

HumanKey uses liveness to establish live presence. It uses biometric uniqueness to make duplicate enrollment dramatically harder. It uses mathematical biometric representations so persistent uniqueness does not require turning the platform into a public gallery of enrollment photographs. It uses zero-knowledge membership to separate proof of humanity from public identity. It uses scoped nullifiers to constrain duplicate actions without requiring public legal identity. It uses passkeys so users do not need to continually scan their faces just to log in. It uses biometric recovery to reconnect a person to the same identity when authentication credentials are lost. It uses rate limits to constrain abuse even when the actor is human. It uses server-side state controls and automated regression testing to enforce those boundaries.

The objective is not to make everybody agree. I would not want that internet.

The objective is not to decide what people are allowed to believe. I would not want that internet either.

The objective is much simpler.

Let humans argue with humans.

Let people disagree. Let people change their minds. Let people be unpopular. Let people say things other people hate.

But when 1,000 apparently independent people are speaking, there should be a meaningful technical reason to believe that something approaching 1,000 actual humans are behind those voices.

Not one person with 1,000 email addresses. Not an account farm. Not a government running synthetic citizens. Not an AI system operating a crowd that does not exist.

Actual people.

That is what HumanKey is trying to restore to the internet.

Not agreement. Not conformity. Not control.

Human presence.

Because in an internet increasingly filled with machines, proof that somebody is actually there is becoming one of the most valuable things we have.

One human. One account.

HumanKey.

We Are Not Trying to Sanitize the Internet

Hash Humanity is not being built to make the internet polite.

Real people disagree. They argue. They have unpopular opinions. They say things other people do not like. Sometimes they are offensive. Sometimes they are wrong.

That is part of dealing with actual humans.

We are not interested in building a platform where disagreement automatically becomes harassment or where an unpopular opinion disappears because enough people do not like it.

HumanKey verifies humans. It does not verify opinions.

Hash Humanity should not tell somebody what political position to have, what religion to believe in, what ideas they are allowed to question, or which side of an argument they are supposed to take.

But there is an important distinction between protecting free expression and pretending that absolutely anything goes.

Not all speech and conduct is legal.

Credible threats, exploitation, fraud, unlawful harassment, impersonation, illegal content, and other unlawful activity do not become acceptable simply because the person behind them is human. Hash Humanity uses moderation tools for situations where platform rules or the law actually require action.

Moderation Is Not A Popularity Contest

A report is a request for review. It is not a vote to remove somebody.

If 5,000 people report one person because they hate what that person believes, that does not make the person's opinion a violation. Hash Humanity was built to resist manufactured crowds. It would make very little sense to turn around and let crowds control moderation.

Reports should trigger review, not automatic guilt. Moderation should focus on conduct and actual rule violations, not ideology, popularity, political position, religion, culture, or which side of an argument has the larger crowd.

Not every report should end with punishment. Not every violation should end with deletion. Severity matters. Context matters. Patterns matter. Serious situations can also require immediate action without moving through every intermediate step.

Blocking Is User Control

Not every disagreement needs Hash Humanity standing in the middle of it.

Sometimes the answer is simple. I do not want to interact with this person anymore. Block them.

Blocking gives people direct control over their own experience without requiring the platform to decide who won an argument. Blocking is not the same thing as platform censorship. It is a user deciding who gets access to them.

Content Removal Is Not The Same As Removing A Human

Removing a post, issuing a warning, temporarily restricting an account, suspending access, and permanently removing an account are different actions and should be treated that way.

HumanKey makes permanent account action more serious than it is on an ordinary social network. Hash Humanity is built around one human, one account. A person should not be able to defeat moderation by deleting an account and immediately returning with a fresh identity. At the same time, a moderation mistake should not casually erase a person's ability to participate.

That means moderation, account deletion, recovery, biometric uniqueness, passkeys, and HumanKey identity have to be considered together.

As the moderation system matures, meaningful account restrictions should have a review and appeal path appropriate to the severity of the action. HumanKey abuse is also its own security category. Attempts to create multiple HumanKeys, manipulate recovery, evade identity controls, impersonate another person, or deliberately defeat human verification are attacks on the integrity of the system, not ordinary disagreements over content.

Privacy Is Not Optional

Hash Humanity is firmly against the idea of turning the internet into a police state.

Human verification should not become human surveillance.

HumanKey exists to establish that a real, unique human is participating. It was not created to track people, profile what they believe, monitor their private lives, or create a database that can be bought by advertisers, data brokers, governments, political organizations, or anybody else.

Hash Humanity user data will never be sold. Under any circumstances.

We do not believe a person's identity, behavior, relationships, conversations, or participation should become a product simply because they chose to use a social network.

Hash Humanity does not voluntarily disclose private user information to third parties. When disclosure is legally compelled, Hash Humanity will require valid legal process applicable to the information being requested. Where the law permits, requests that are invalid, unlawful, or overly broad should be challenged. For private user information that legally requires a warrant, Hash Humanity will require a valid warrant.

We will not sell access to user information. We will not voluntarily create surveillance back doors. We will not quietly turn HumanKey into a tool for watching people.

There is an enormous difference between proving that a human exists and building a system designed to watch that human.

HumanKey is meant to prove humanity, not police it.

The Principle

The goal is not to sanitize human conversation.

The goal is to keep the people participating in that conversation human, give those humans meaningful control over who they interact with, and step in when behavior crosses boundaries that actually require us to step in.