Ghostmaxxing Brand Voice

Version: 0.9.9
Status: current internal standard
Language standard: clear international English; UK and US spelling may coexist
Last updated: September 2026

Purpose

Ghostmaxxing is a public research lab for testing, explaining and questioning face recognition. It combines browser-based AR camouflage, adversarial makeup experiments, local comparison tests, a curated reference archive, a Fediverse presence and a reporting node.

The project comes from hacking understood politically: an attitude of subversion, inquiry and freedom, not a product category. It contests the normalisation of face recognition in public life. Use hacking when it helps explain the project's position. Do not present Ghostmaxxing as a hacker tool, because that narrows the audience and makes the work sound like a technical subculture rather than a public investigation.

Ghostmaxxing is designed by technologists working in the public interest. Its public voice should show an understanding of code, research, public space, culture and political risk at the same time.

Ghostmaxxing is not an invisibility product. It is a public-facing research lab, a visual test bench and a route into an investigative archive.

Theory of change

Ghostmaxxing is designed to work as a research loop, not as a collection of unrelated pages. The loop below is the target operating model. Public copy must distinguish capabilities that are already available from integrations that are still being completed.

1. Local experiments produce Ghostyles and test records. People use the browser lab to make and test visual interventions under stated conditions.
2. The Fediverse becomes the federated data backend. Ghostyles, public test records, limitations, references and project updates are represented and exchanged through ActivityPub rather than being confined to one website or application.
3. The Fediverse distributes the work. Different communities, applications and instances can follow, question, reproduce and retest the research.
4. The lab reads from the same network. Relevant updates arriving through the Fediverse become new inputs for the lab after validation and moderation. The network is both an output and an input of the research process.
5. Public visibility creates routes to private reporting. The distributed work can reach people who know how face recognition systems are built, bought, operated or experienced.
6. Anonymous reports update the investigation. Evidence from deployments, contracts, operators, affected people and technical insiders informs the archive, the threat model and the next round of tests.
7. The lab tests again. New evidence changes the research questions and may produce new Ghostyles, revised limits or a clear finding that an earlier result no longer transfers.

In compact form:

Local tests -> Ghostyles and records -> Fediverse backend -> lab updates and public distribution -> anonymous reporting -> verified evidence -> better tests

The loop does not promise that public visibility alone changes institutional power. It creates shared, testable knowledge and a path by which evidence can alter the research.

Confidential reports are never published directly to the Fediverse. Only verified, minimised and appropriately redacted findings may return to the public data layer after editorial and security review.

Until the bidirectional ActivityPub integration is operational, describe it as the project architecture or intended data flow. Do not imply that the lab already consumes federated updates automatically if it does not.

Requirement for the About page

The About page must explain this theory of change explicitly. It should not describe the lab, Fediverse backend, archive and reporting node as separate features. It should show the bidirectional relationship between the lab and the Fediverse, then show how public research can generate private reports and how verified evidence changes later tests.

The About page should also name the people the reporting node is intended to reach:

• people who build or maintain the technology;
• people who know where a specific deployment fails;
• people who have seen contracts, tenders or internal evaluations;
• people who operate a system day to day;
• people who approved or funded a deployment;
• people who noticed face recognition in public space;
• people who were stopped, flagged or misidentified by it.

Do not ask any of these people to disclose sensitive material casually. The reporting page must provide its own security guidance before asking for information.

Communication goals

Public copy should help people:

1. understand what Ghostmaxxing tests and what it does not claim;
2. try a local experiment without mistaking it for protection;
3. understand a Ghostyle as a testable and shareable intervention;
4. understand the Fediverse as the project's data backend, public distribution network and source of validated lab updates;
5. inspect the technical and cultural lineage in the reference archive;
6. report deployments, evidence or first-hand knowledge through the appropriate channel;
7. recognise that face recognition is contingent, political and open to investigation.

Core voice

Use a tone that is:

• activist first, culturally staged second and editorial third;
• technically precise;
• curious and experimental;
• direct without becoming sloganistic;
• public-facing without simplifying the work into false claims;
• visually imaginative;
• grounded in evidence;
• open to contributors and retesting;
• critical of biometric inevitability;
• respectful of people whose faces, bodies and data are affected;
• candid about uncertainty, failure and limits.

The public voice can be summarised as:

Activist cultural lab + investigative archive + technically grounded workshop

Think of:

• a public poster that rewards close reading;
• an exhibition label that respects technical detail;
• a workshop table where methods are visible;
• a browser-based adversarial lab that explains its limits;
• a software project that knows it exists in political reality.

Avoid sounding like:

• a startup promising disruption;
• a cybersecurity product promising safety;
• an academic paper written only for specialists;
• an activist slogan with no technical detail;
• a beauty tutorial with no threat model;
• a hacker toy with no ethics;
• a policy campaign asking only for agreement.

Editorial principles

1. Test, do not trust

A face match is a system output, not a truth. Make the pipeline inspectable and the claim testable.

Prefer:

• Make biometric assumptions inspectable.
• Test the read under stated conditions.
• A face match is a system output, not a truth.

Avoid:

• Facial recognition is always broken.
• This defeats surveillance.
• This makes you anonymous.

2. State the conditions

Any claim about performance must state what materially shaped the result. Depending on the test, this may include the model, task, camera, light, pose, distance, image quality, threshold, environment and sample.

Prefer:

In this local test, the pattern lowered detection confidence on one open model at close range under even light.

Avoid generalising from a browser test, one model, one face or one environment to deployed systems.

3. Publish uncertainty

An open question is a valid research result. Say when transfer to another model or a real deployment is unknown. Do not hide uncertainty below the fold or turn it into vague legal language.

4. Treat the archive as evidence

References are part of the public argument. Each entry should help a reader distinguish what was demonstrated, under which conditions, what remains testable and what the limits are.

5. Connect technical tests to civic evidence

The lab tests techniques. The Fediverse stores and carries public research objects in both directions. The reporting node gathers private evidence about deployments and institutions. Copy should make these relationships visible wherever they are relevant.

6. Do not promise safety

Never imply that a Ghostyle makes someone safe from surveillance. Do not use uncertainty as a theatrical device. State limits plainly and near the relevant claim.

Claims ladder

Grade consequential claims before publication.

The word defeated may appear only when it describes a documented, past-tense result involving a specific system under stated conditions. Never use it as a present-tense promise to the reader.

Standard descriptions

One-line description

Ghostmaxxing is a public lab for testing face-recognition camouflage and documenting the technical, cultural and political history of anti-biometric appearance design.

Short description

Ghostmaxxing lets people experiment with face-recognition camouflage in the browser. It combines webcam-based face detection, modular AR interventions called Ghostyles, local comparison tests and a curated archive of adversarial makeup, CV Dazzle, face obfuscation and physical-world attacks against computer vision.

Longer description

Ghostmaxxing is a public Web AR lab for developing and testing anti-biometric camouflage. Developers, researchers, digital rights groups, artists and curious people can apply modular visual interventions to a face, compare recognition behaviour before and after an intervention and trace the technical and cultural lineage of the field through a curated reference archive.

Many physical countermeasures have already been proposed, including printed glasses, stickers, prosthetics, hats, textiles and makeup. Few claims have been retested as models, sensors and deployment conditions changed. Ghostmaxxing treats each result as local, conditional and temporary until further testing shows otherwise.

The project connects testing, federated data and anonymous reporting. Ghostyles make experiments shareable. The Fediverse is designed to become both the backend for public research objects and a source of updates that the lab can validate and use. The GlobaLeaks reporting node invites private evidence from people who build, buy, operate, observe or experience face recognition systems. Verified evidence can change the archive, the threat model and the next round of tests.

Key messages

The face is a technical interface

Face recognition systems parse faces through landmarks, descriptors, regions, contrast, light, occlusion and learned representations.

Suggested phrasing:

• The face is read as data, geometry, texture and probability.
• A Ghostyle is a visual intervention on the machine-readable face.
• Makeup becomes a test surface.
• AR becomes a diagnostic layer.

Avoid:

• Your face becomes invisible.
• This hides your identity.
• Makeup hacks the system, full stop.

Ghostyles are shared research objects

A Ghostyle is not a promise and not merely a cosmetic filter. It packages an intervention so that people can apply it, inspect it, test it and describe the conditions under which it produced a result.

Suggested phrasing:

• Build a Ghostyle. State the conditions. Share what happened.
• A Ghostyle turns a look into a testable intervention.
• Retest the pattern against another model or environment.

The genealogy matters

Ghostmaxxing belongs to a longer technical and cultural lineage that includes CV Dazzle, HyperFace, adversarial glasses, adversarial makeup, physical-world optical attacks, near-infrared attacks and public-space performances.

Suggested phrasing:

• This field is older, deeper and better documented than most people think.
• The archive traces what was demonstrated, what interrupted it and what changed next.
• Each reference asks what can be retested now.

Avoid:

• These projects prove facial recognition is useless.
• Old techniques still work everywhere.
• A paper result equals real-world protection.

The Fediverse is research infrastructure

The Fediverse is not a promotional channel added after the research. In the target architecture, it is the federated backend for public Ghostyles, test records, limitations, references and updates. The lab also reads relevant updates from the network, validates them and uses them as inputs for later research.

Suggested phrasing:

• Follow the research in the Fediverse.
• Share a result with its conditions attached.
• Help a test reach someone who can reproduce or challenge it.
• Publish once, let different ActivityPub applications read and respond.
• Let the lab receive new public research inputs from the same network.

Do not imply that every federated object is trusted automatically. Federation transports and distributes data. Validation, moderation and evidentiary judgement remain Ghostmaxxing responsibilities.

Reporting closes the loop

The public work is also a signal to people with evidence about real systems. The reporting node uses GlobaLeaks to protect source anonymity and connect technical experiments to civic and institutional knowledge.

Suggested phrasing:

• Seen face recognition in public space? Document what you can safely verify.
• The lab tests techniques. The reporting node gathers evidence.
• Technical experiments and civic reporting belong in the same investigation.
• Know how a deployment works or where it fails? Use our anonymous GlobaLeaks reporting channel.
• For stronger connection anonymity, use Tor Browser and the designated Onion Service.

Never write:

• Report anything suspicious.
• Send us private personal data.
• Upload faces or sensitive material casually.

Reporting anonymity and access

Ghostmaxxing may state that its designated GlobaLeaks channel protects source anonymity. The reporting page must explain both access routes:

1. the standard HTTPS address, suitable for ordinary access;
2. the Onion Service v3 address, opened with Tor Browser, for stronger connection anonymity and resistance to selective interception or blocking.

The Tor option must be visible before a person starts a submission. Link to the official Tor Browser download and usage guidance, and display the current Onion Service address from maintained configuration rather than duplicating it across static copy.

Do not extend the anonymity claim beyond the designated reporting system. A source may still reveal identifying information through the content, files, metadata or circumstances of a report. Safety guidance must explain data minimisation and the risks of submitting documents or media.

Reference: https://docs.globaleaks.org/en/stable/technical/security/application-security.html

Vocabulary

Preferred terms

• face recognition
• facial recognition
• face detection
• face matching
• biometric surveillance
• anti-biometric camouflage
• adversarial makeup
• appearance-based intervention
• physical-world attack
• computer vision
• Ghostyle
• reference archive
• testability
• limitations
• local experiment
• browser-based lab
• public research
• public-facing research lab
• reporting node
• civic intelligence
• retest
• adversarial

Use with context

The following terms can be accurate, but should be tied to a specific task, model or result:

• evasion
• spoofing
• attack
• resistance
• surveillance
• anonymisation
• camouflage
• hacking
• defeated

Prefer "a local test of face-matching evasion in a browser pipeline" to "face recognition evasion".

Avoid or heavily qualify

• invisibility
• anonymity guarantee outside the designated GlobaLeaks reporting channel
• protection
• foolproof
• defeat, when used as a general or present-tense claim
• bypass all systems
• anti-surveillance shield
• safe in public
• untrackable
• undetectable

Naming conventions

Project name

Ghostmaxxing is the project identity. Use it for the lab, site, archive, reporting node, workshops and the wider project. Keep the same name in public copy, code, URLs and filenames.

Ghostyle

Ghostyle is a term introduced as part of Ghostmaxxing.

A Ghostyle is a modular visual intervention applied to the face through the Ghostmaxxing lab. It is also the unit in which an intervention can be saved, described, tested and shared.

Write:

• Ghostyle
• Ghostyles
• Ghostyle plugin, when referring to the technical format

At first mention for a general audience, use a short definition such as "a modular AR intervention called a Ghostyle".

Avoid:

• filter, unless immediately clarifying that a Ghostyle is a testable intervention rather than only a cosmetic effect;
• effect, unless describing rendering behaviour;
• makeup hack, except in deliberately informal social copy.

Define Ghostyle through its current role in Ghostmaxxing.

Tone by page

Homepage

Tone: direct, visual, activist and concise.
Job: establish the project, the central action and the research loop without front-loading every qualification.
Lead with: a strong, testable proposition.
Avoid: dense institutional background, multiple competing CTAs and protection claims.

Recommended core copy:

Test face-recognition camouflage in the browser. Build Ghostyles, compare detection and matching behaviour, and explore the research behind anti-biometric appearance design.

About

Tone: clear, connective and politically explicit.
Job: explain why the project exists, who it is for and how the theory of change works.
Lead with: the project as a public investigation, then show the bidirectional loop between Ghostyles, the Fediverse backend, anonymous reporting and new tests.
Avoid: a feature inventory, a conventional organisation biography or a claim that awareness alone produces change.

Lab and tool pages

Tone: operational, calm and exact.
Job: help a person run a local experiment and understand what the interface can and cannot measure.
Lead with: the next action, local processing and the current state of the test.
Avoid: manifesto copy during a task, ambiguous controls and claims that a local result transfers to deployed systems.

Ghostyle documentation

Tone: practical, inspectable and collaborative.
Job: define the intervention, its components, provenance, test conditions and limits.
Lead with: what the Ghostyle changes and how to reproduce the test.
Avoid: presenting a Ghostyle as a finished protection product or stripping results from their conditions.

References

Tone: editorial, investigative and evidence-led.
Job: help readers understand lineage, demonstrations, limits and opportunities for retesting.
Lead with: what the source is and what it actually demonstrated.
Avoid: abstract bibliographic language, authority by citation count and implying that a paper result is universal.

Each reference entry should answer:

1. What is this?
2. What did it demonstrate?
3. Under which conditions?
4. Why does it matter?
5. What are its limitations?
6. What can Ghostmaxxing retest?
7. Where is the primary source?

Genealogy

Tone: theatrical at entry, precise in every dossier.
Job: show successive technical eras, documented interruptions and the live present without turning history into a victory narrative.
Lead with: the lineage and how to read the lens states.
Avoid: treating dates as deployment dates when they mark public demonstrations, or implying that one intervention defeated face recognition as a whole.

Reporting node

Tone: calm, serious, specific and non-coercive.
Job: help a person decide whether, what and how to report.
Lead with: source anonymity, scope, safety guidance, data minimisation and the choice between HTTPS and the Onion Service through Tor Browser.
Avoid: urgency theatre, heroic whistleblower language, vague requests for suspicious material and anonymity claims outside the protection actually provided by GlobaLeaks and Tor.

Workshops

Tone: welcoming, concrete and method-led.
Job: explain what participants will do, what they need and what they will leave with.
Lead with: activities, learning outcomes, accessibility and consent.
Avoid: making technical confidence a prerequisite or presenting participants as test subjects.

Fediverse page and social posts

Tone: conversational, observant and concise, while retaining the claims discipline of the site.
Job: explain the implemented Fediverse functions, the target federated data backend and how the lab will receive validated updates from other ActivityPub actors.
Lead with: the objects and updates currently available through the network, then identify planned bidirectional functions clearly. Explain how people and compatible applications can follow, respond or contribute.
Avoid: presenting the Fediverse as a social-media mirror, promotional filler, engagement bait, context-free screenshots and any suggestion that incoming data bypasses moderation.

Technical documentation

Tone: explicit, reproducible and low-ambiguity.
Job: help contributors understand data flow, files, states, limits and contribution rules.
Lead with: prerequisites, observable behaviour and exact terminology.
Avoid: unexplained internal shorthand and persuasive brand language where an implementation rule is needed.

Calls to action

CTA language should reflect increasing commitment and risk.

The reporting action is last because it asks the most of the reader, not because it matters least. Never place it where a casual or accidental action could be mistaken for informed contact.

Style and mechanics

• Write clear international English. UK and US spellings may coexist and should not be normalised merely for consistency.
• Preserve the spelling used in code identifiers, source titles, quotations and official names.
• Use the serial comma only where it prevents ambiguity.
• Prefer short declarative sentences around actions, risks and limits.
• Use contractions sparingly in conversational surfaces such as the Fediverse.
• Use sentence case for headings unless a component has another established rule.
• Do not use emoji in the core site voice.
• Do not use em dashes. Use a full stop, colon, comma or parentheses instead.
• Do not use rhetorical questions when a direct statement is clearer.
• Define specialist terms at first use on public pages.
• Put limitations beside the claim they limit.

Publication checklist

Before publishing, ask:

• Is Ghostmaxxing the only current identity named?
• Is Ghostyle defined on first use for a general audience?
• Does every consequential claim have the right grade?
• Are the test conditions and limits close to the result?
• Does the copy avoid implying safety, invisibility or universal transfer?
• Does the page make its role in the research loop clear?
• Is the reporting request proportionate and accompanied by safety guidance?
• Does the tone match the page type?
• Is the English consistent and free of em dashes?
• Can a non-specialist understand the action without losing technical accuracy?