(Internal) Ghostmaxxing Brand Voice

Purpose

Ghostmaxxing is a public research lab for testing, explaining, and questioning facial recognition systems through browser-based AR camouflage, adversarial makeup experiments, and curated technical references.

The project should sound like a tool made by people who understand code, research, public space, and political risk — without overselling protection or turning critique into spectacle.

Ghostmaxxing is not a magic invisibility product. Ghostmaxxing is a public lab, a visual test bench, and an investigative archive gateway.

Core voice

Use a tone that is:

  • technically precise
  • curious and experimental
  • public-facing but not simplified to the point of being wrong
  • careful with security claims
  • visually imaginative
  • grounded in evidence
  • open to contributors
  • skeptical of biometric inevitability
  • respectful of people whose faces, bodies, and data are affected

The public voice is: activist cultural lab + investigative archive + technically grounded workshop.

Think:

  • an activist, exhibition-like interface
  • a workshop table
  • a browser-based adversarial lab that explains its limits
  • an exhibition label that still respects technical detail
  • a software project that knows it lives in political reality

Avoid sounding like:

  • a startup promising disruption
  • a cybersecurity product promising safety
  • an academic paper that excludes non-specialists
  • an activist poster with no technical detail
  • a beauty tutorial with no threat model
  • a hacker toy with no ethics

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 directly in the browser. It combines webcam-based face detection, modular AR “Ghostyles”, local comparison tests, and a curated reference archive on adversarial makeup, CV Dazzle, face obfuscation, and physical-world attacks against computer vision systems.

Longer description

Ghostmaxxing is a public Web AR lab for developing and testing anti-biometric camouflage. It lets developers, researchers, digital rights groups, artists, and curious people apply modular visual overlays to a face, compare recognition behavior before and after the intervention, and understand where this field comes from through a curated technical and cultural references archive.

It does not guarantee anonymity. It does not defeat all facial recognition systems. It helps make biometric claims testable, visible, and discussable.

Key messages

1. Test, do not trust

Facial recognition systems should not be accepted as neutral, inevitable, or universally reliable. Ghostmaxxing makes parts of the recognition pipeline visible enough to test and question.

Suggested phrasing:

  • Test the machine before believing the claim.
  • Recognition is not certainty.
  • A face match is a system output, not a truth.
  • Make biometric assumptions inspectable.

Avoid:

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

2. The face is a technical interface

Ghostmaxxing treats the face as something computer vision systems parse 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.

3. The references matter

The project is part of a longer genealogy: CV Dazzle, HyperFace, adversarial glasses, adversarial makeup, physical-world optical attacks, NIR attacks, public-space performances, and face-obfuscation research.

Suggested phrasing:

  • This field is older, deeper, and more documented than most people think.
  • The references archive maps the technical and cultural lineage of Ghostmaxxing.
  • Each reference asks: what was demonstrated, under what conditions, and what can Ghostmaxxing retest?

Avoid:

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

4. The whistleblowing/leaking service is central

Ghostmaxxing is a demo but also an attractor of attention for people working in that industry, in the search for allies within.

Suggested phrasing:

  • Seen facial recognition in public space? Document it and Report it.
  • The lab tests techniques; the reporting node gathers evidence.
  • Technical experiments and civic reporting belong together.
  • Help map where biometric systems are actually used.

Avoid:

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

5. No false safety

This is one of the most important principles.

Suggested phrasing:

  • Ghostmaxxing is a research and education tool, not personal protection advice.
  • A failed match in the browser is not a guarantee in the street.
  • Results depend on model, camera, light, pose, distance, and context.
  • Treat every successful evasion as local, conditional, and temporary.

Avoid:

  • Protect yourself with Ghostmaxxing.
  • Become unrecognizable.
  • Beat facial recognition.
  • Guaranteed anti-surveillance makeup.

Vocabulary

Preferred terms

Use:

  • 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
  • reporting node
  • civic intelligence
  • adversarial

Use carefully

These can be used, but with context:

  • evasion
  • spoofing
  • attack
  • resistance
  • surveillance
  • anonymization
  • camouflage

When using these, specify limits. For example:

Good: “a local test of face-matching evasion in a browser pipeline”

Risky: “face recognition evasion”

Avoid or heavily qualify

Avoid:

  • invisibility
  • anonymity guarantee
  • protection
  • foolproof
  • defeat
  • bypass all systems
  • anti-surveillance shield
  • safe in public
  • untrackable
  • undetectable

Naming conventions

Project name

Preferred:

  • Ghòstati
  • Ghostmaxxing, when accents are difficult in filenames, URLs, code, or English-only contexts

Do not over-explain the name every time. Use the accented form in editorial copy and the ASCII-safe form in code contexts.

Ghostyles

A Ghostyle is a modular visual intervention applied to the face.

Write:

  • Ghostyle
  • Ghostyles
  • Ghostyle plugin

Avoid:

  • filter, unless speaking to a broad public and immediately clarifying it is not just a cosmetic filter
  • effect, unless describing rendering
  • makeup hack, unless in informal social copy

Tone by page type

Homepage

Tone: direct, visual, inviting, not too dense.

Goal: make people understand what the project is and where to go next.

Good homepage copy:

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

CTA hierarchy:

  1. Open the lab
  2. Explore references
  3. Build a Ghostyle
  4. Report public-space face recognition

README

Tone: technical, precise, contributor-friendly.

Goal: help developers understand architecture, run the project, write plugins, run tests, and understand safety limits.

README should include:

  • what it does
  • what it does not do
  • architecture
  • local privacy notes
  • install/run commands
  • Ghostyle API
  • tests
  • references page
  • reporting node
  • contribution guidelines

References page

Tone: curated evidence lab.

Goal: explain the history, techniques, claims, limitations, and Ghostmaxxing relevance of each reference.

Each reference should answer:

  1. What is it?
  2. What did it demonstrate?
  3. What technique did it use?
  4. What are its limits?
  5. Can Ghostmaxxing retest or approximate it?
  6. Where can people read more?

Use concise but substantial cards. Avoid bibliography-only presentation.

Report / whistleblowing page

Tone: careful, calm, protective.

Goal: invite useful reports without encouraging unsafe disclosure.

Use:

  • “Seen facial recognition in public space?”
  • “Tell us what you know, only if it is safe for you.”
  • “Do not include unnecessary personal data.”
  • “Use the reporting channel that matches your language and risk context.”

Avoid:

  • urgent pressure
  • heroic language
  • requests for risky evidence
  • vague claims about secure handling unless verified

Social posts

Tone: sharp, visual, understandable, never overclaiming.

Good pattern:

  1. one striking claim
  2. one technical clarification
  3. one action

Example:

“Facial recognition is not magic. It is a pipeline: detection, landmarks, descriptors, matching. Ghòstati lets you test how visual interventions change that pipeline in the browser. Try it, build a Ghostyle, or report public-space deployments.”

Workshop copy

Tone: participatory, practical, safety-aware.

Use:

  • “Bring a laptop and curiosity.”
  • “No biometric data is uploaded by the browser lab.”
  • “We will test local recognition behavior, not promise anonymity.”
  • “Failures are useful results.”

Claims policy

Every public claim should fit one of these categories:

Safe claim

“Ghostmaxxing lets users test browser-based face detection and matching behavior with visual overlays.”

Conditional claim

“Some Ghostyles may reduce detection or matching in specific local test conditions.”

Research claim

“Prior work has shown that physical-world interventions such as makeup, glasses, light, patches, or textiles can affect specific computer vision systems under documented conditions.”

Unsafe claim

“Ghostmaxxing protects you from facial recognition.”

Do not publish unsafe claims.

How to describe limitations

Always make limitations explicit when discussing results.

Useful limitation patterns:

  • “in this browser pipeline”
  • “under these lighting conditions”
  • “against this model”
  • “with this camera”
  • “in a local comparison test”
  • “not a guarantee against deployed systems”
  • “not tested against newer commercial systems”
  • “not evidence of real-world anonymity”

Example:

“Using this Ghostyle, the browser demo failed to match the saved face under the test conditions. This is a local result, not a general protection claim.”

Visual language

The visual style should feel like:

  • dark public lab
  • neon annotations
  • festival signage
  • accessible technical archive
  • biometric system under inspection
  • face as interface
  • evidence, not spectacle

Good motifs:

  • timelines
  • scanlines
  • bounding boxes
  • landmark points
  • masks
  • cards as specimens
  • metadata strips
  • terminal-like labels
  • large CTA buttons
  • subtle glitch, not unreadable glitch

Avoid:

  • horror aesthetics
  • military/tactical aesthetics
  • corporate cybersecurity visuals
  • anonymous hacker clichés
  • surveillance fetish imagery
  • beauty branding without critique

Accessibility

The project can be visually expressive, but must remain readable.

Rules:

  • strong contrast
  • legible font sizes
  • mobile-first layout
  • visible focus states
  • buttons that work without hover
  • no essential information only in color
  • no excessive animation
  • reduced-motion support where possible
  • alt text for preview images
  • clear labels for filters and toggles

Microcopy examples

Buttons

Use:

  • Open the lab
  • Explore references
  • Build a Ghostyle
  • Read the docs
  • View source
  • Report a deployment
  • Switch to genealogy mode
  • Show newest first
  • Filter references
  • Clear filters

Avoid:

  • Become invisible
  • Beat surveillance
  • Protect me
  • Hack my face

Badges

Use:

  • Directly testable
  • Partially testable
  • Contextual reference
  • Physical-world
  • Browser lab
  • Face detection
  • Face recognition
  • Visible light
  • Near-infrared
  • Makeup
  • Glasses
  • Textile
  • Patch
  • Survey

Warning labels

Use:

  • Local test only
  • Not a safety guarantee
  • Conditions matter
  • Model-specific result
  • External deployment unknown

Editorial structure for reference cards

Recommended card order:

  1. Year, type, closeness
  2. Title
  3. Authors
  4. Short description
  5. What it demonstrated
  6. Technique / intervention
  7. Target system
  8. Ghostmaxxing testability
  9. Limitations
  10. Links

Recommended labels:

  • Demonstrated
  • Why it matters for Ghostmaxxing
  • Ghostmaxxing testability
  • Limits
  • Technique
  • Target
  • Read more

Writing examples

Good README sentence

“Ghostmaxxing runs a local browser pipeline for webcam-based face detection, modular AR overlays, and baseline-vs-modified face matching tests.”

Good limitation sentence

“A browser result can show that a visual intervention affected one local pipeline; it cannot prove protection against deployed facial recognition systems.”

Good reference sentence

“Adv-Makeup is relevant to Ghostmaxxing because it treats makeup as a physical-world adversarial surface around the face, but its reported effectiveness remains tied to the models and experimental setup used in the paper.”

Good report CTA

“Seen facial recognition in a public space? Use the reporting node to share what you know, only if it is safe for you to do so.”

Editorial checklist

Before publishing a new page or section, check:

  • Does it say what Ghostmaxxing does technically?
  • Does it avoid protection guarantees?
  • Does it explain limits?
  • Does it link to the lab, repo, docs, references, and reporting node where relevant?
  • Does it help a developer take action?
  • Does it help a non-specialist understand the stakes?
  • Does it avoid collecting or encouraging unnecessary biometric data?
  • Does it use consistent names: Ghostmaxxing, Ghòstati, Ghostyle?
  • Does it preserve the activist cultural lab + investigative archive tone?
  • Does it make the reporting node visible when discussing real-world deployments?

Short boilerplate

Use this when space is limited:

“Ghostmaxxing is a browser-based lab for testing face-recognition camouflage. It lets people build and compare AR Ghostyles, explore the research history of anti-biometric appearance design, and report real-world deployments of facial recognition.”

Safety boilerplate

Use this near demos, workshops, and test results:

“Ghostmaxxing is a research and education tool. Results are local to the tested browser, model, camera, lighting, and conditions. It does not guarantee anonymity or protection against deployed facial recognition systems.”

References boilerplate

Use this for the references page:

“Ghostmaxxing references archive maps artistic, academic, and activist work around face obfuscation, adversarial makeup, physical-world attacks, and anti-surveillance aesthetics. Each entry documents what was demonstrated, what its limits are, and whether Ghostmaxxing can directly or partially retest the idea.”

Reporting boilerplate

Use this near the reporting node:

“Technical tests are only one part of the work. If you know of facial recognition being used in public space, the reporting node helps collect evidence about where it is deployed, by whom, with which technology, and under what safeguards or abuses.”