Draft v0.1 A sibling of ACT and S/P/A · for creators, organizers, and anyone who hosts things

Data Security in Community

You've made a website for your project, offering, or organization. This is a guide to keeping it from leaking your community's information.

BLUF

Every outside request your page makes hands each visitor's IP address, plus the fact that they visited you, to another company. Fonts, embeds, analytics, form builders — all of it. A German court already ruled that the fonts alone cross the line. Audit your page, self-host what you can, swap the rest for tools that don't take attendance. This page shows how, and practices what it preaches: view source — the fonts live in this file.

The hundred-euro font

In January 2022 a German court ruled on the smallest possible version of this problem: a website that loaded its typefaces from Google's servers.

Landgericht München I · judgment of 20 January 2022 · case 3 O 17493/20

The court held that a visitor's dynamic IP address is personal data; that embedding Google Fonts remotely transmits that address to Google without consent, every visit; that the website operator had no legitimate interest to stand on — because the fonts could have been self-hosted all along — and awarded the visitor €100 in damages for the loss of control over their data.

The money is trivial. The principle isn't: the requests your page makes are your responsibility, and "that's just how the embed code came" is not a defense. If a court can see it, your visitors' adversaries can too — ad networks don't need a subpoena.

The audit: read your own page

One ritual, fifteen minutes, once. Open your site, open the browser's network tab (or just view source), and list every domain that isn't yours. Each one receives, at minimum: the visitor's IP address, the page they were on, and the time. Common findings on community sites:

  • Remote fonts — Google Fonts, Adobe Fonts.
  • Analytics — Google Analytics, Meta pixel, "just to see traffic."
  • Embeds — YouTube players, Google Maps, Instagram posts, each phoning home before anyone clicks play.
  • Form and calendar widgets — Google Forms, Calendly, Mailchimp signup boxes.
  • CDN scripts — jQuery from a CDN, icon packs, chat bubbles.

Now weigh each one against who visits you. A mutual-aid page, a venue, an organizing space — your visitors may have better reasons than most to not be enumerated.

Self-host your fonts

The easiest fix and the biggest symbol, which is why it goes first. About fifteen minutes:

  • Download the woff2 files. Most Google Fonts faces are under the SIL Open Font License, which permits exactly this; Fontsource and google-webfonts-helper package them ready to use.
  • Put them next to your HTML and declare them with @font-face, with font-display: swap so text never waits on them.
  • Take only the weights and character sets you use — the latin subset of a weight is usually 15–25 KB.
  • Delete the fonts.googleapis.com link tag. That's the whole migration.

This page embeds its three typefaces inside the file itself — view source. Total cost: about 145 KB, or less than one Instagram photo, for zero outside requests.

Swaps that keep the function, drop the surveillance

Checked October 2026 against each tool’s own site and privacy policy. Tools change; recheck a row before you rely on it.

  • Google Analytics"how many people visited"First ask if you need it at all. If you do: a cookie-less, open-source counter you can host yourself (GoatCounter, Umami, Plausible Community Edition) answers "how many" without profiling "who."
  • YouTube embedvideo on your pageA thumbnail image that links out to the video, or PeerTube for video you host (turn off its peer-to-peer sharing; with it on, people watching the same video at the same time can see each other’s IP addresses). A default embed phones home on page load, before anyone presses play. The youtube-nocookie.com “privacy-enhanced” embed only promises the view won’t personalize the visitor’s YouTube or ads; the player still loads from Google when the page opens, so every visitor’s IP still goes there. Fewer cookies, same request.
  • Google Formssignups, RSVPsSometimes the form is just an email address. Otherwise a self-hosted form, or a form tool that doesn't require respondents to be logged-in, tracked users.
  • Google Maps embed"find us"A static image of the map linking to OpenStreetMap, plus the address in text. Nobody's location gets read to render a picture of yours.
  • MailchimpnewsletterButtondown, which has kept open and click tracking off by default since 2021, or self-hosted Listmonk with the {{ TrackView }} tag removed from your templates (its default template includes a tracking pixel). Your readers' reading habits aren't a metric you need.
  • CalendlybookingOffice hours and an email address, or Cal.diy on your own server: the MIT-licensed open-source edition Cal.com released when it went closed source in April 2026.
  • GoDaddy-class registrarwhere your domain livesPorkbun, or any registrar that passes the fine-print test: renewal price published, flat and boring; WHOIS privacy free by default; hardware-key (WebAuthn) two-factor on the account; DNSSEC included, not sold back to you. The tells of a bad one: a $1 first year with a much higher renewal, security features bundled into a paid "protection" plan, an upsell maze at checkout, and price changes announced by private email instead of a public price sheet. This account outranks every other you own — whoever controls the registrar controls your DNS, and whoever controls your DNS receives your mail. Lock it hardest, and keep its recovery email off the domain itself. (Checked September 2026 — registrar features drift; re-run the test before you buy.)
  • Face-scan or fingerprint check-inevents, venues, member spacesA name at the door, a ticket code, or a printed list that gets shredded afterward. A face can't be changed after a breach, and a list of who came is the first thing anyone hostile asks for.
  • Linktreelink-in-bioOne HTML page you own. It's the smallest possible website and the best first exercise in hosting your own things.
  • Discord-only presencethe whole community lives thereKeep Discord if it's where your people are — but keep a public web page too, so joining your community doesn't require an account with anyone.

Principles, portable to any project

  • Your page's requests are your visitors' data. Audit them like you'd audit your books.
  • One file where possible. What can be read by view-source can be trusted by view-source.
  • Open source before free-as-in-ads. "Free" analytics are paid for with your visitors.
  • No account, no questions. Participation shouldn't require being enumerated.
  • Publish your own privacy policy, even if it's three sentences. Especially if it's three sentences.
  • Write the policy row before you ship the feature, never after.
  • Pay the commons. The free tools run on donations — Index of /commons has the links.

For the personal-device side of this, see the sibling site S/P/A; for the radio side, ACT.

Keys you hold for other people

If you run the site, the server or the group's accounts, you carry keys that other people's data depends on. Four kinds, and for each one: where it lives, how it's backed up, and how it's revoked.

  • SSH keys. One key per device, never copied between machines, so a lost laptop means revoking one key instead of all of them. Make each with ssh-keygen -t ed25519 and give it a passphrase, or use a hardware key (ssh-keygen -t ed25519-sk, OpenSSH 8.2 or later) so the secret never leaves the token. Don't back the key up; replace it. Instead, keep a second authorized key (another device, or a hardware key in the go-binder) so losing one never locks you out. To revoke, delete its line from ~/.ssh/authorized_keys on every server it reaches, and remove it from your Git host's settings.
  • Repository and API tokens. Use the narrowest token the host offers (on GitHub, a fine-grained token limited to one repository) and give it an expiry date. Tokens live in your password manager or your build system's secret store, never in the repository; put .env in .gitignore before the first commit. Don't back them up; reissue them. Revoke one in the host's token settings the moment it shows up anywhere public. A token that was ever in a public commit is burned, even after you delete the commit.
  • Hosting, registrar and DNS logins. These are the real keys to the site: whoever holds them can replace it. Each gets its own password, a hardware key or authenticator app as the second factor, and recovery codes on paper in the go-binder. On the server itself: keys instead of passwords (PasswordAuthentication no), no direct root login, and a separate account for each person.
  • The self-hosted stack. Keep a one-page inventory: every service, where it runs, its domain, where its data and settings live, who has admin, and when it was last backed up. Back up data and settings with an encrypted tool (restic, Borg or Kopia) on the 3-2-1 pattern, with the backup key stored away from the backups. A backup you haven't restored isn't a backup yet: restore one service to a spare machine twice a year.

When someone steps back, do it the same day, from a written list rather than memory: their SSH keys out of every authorized_keys, their accounts disabled, every shared password they knew rotated, every token they created revoked, and the inventory updated.

When the threat is bigger than your website

This page is about not leaking your visitors to ad networks. If you organize, report, or host people who face targeted threats — a government, a specific person, legal process, a border crossing with sensitive material — that's specialist work, and these are the people who do it:

If someone is a danger to you right now, the people to call are not on this site.

FAQ

Questions from readers, answered at the depth a community site owes them. Have one of your own? Send it in — unanswered questions are the most useful mail this page gets.

What makes a good password?

Length. Not complexity — length. The US standards body for this, NIST, rewrote its guidance (SP 800-63B, revision 4, finalized August 2025) around evidence instead of folklore, and the folklore lost: sites must not demand the r@nd0m-symbol ritual anymore, must accept passwords up to at least 64 characters including spaces, and must not force you to rotate a password on a schedule — only when there's evidence it leaked. The floors: 15 characters minimum for a password used on its own, 8 only when it's one factor of two-factor login, and new passwords should be screened against lists of already-breached ones.

Why length wins: a password's real strength is how many guesses it survives, and each added character multiplies the guess count; each added rule mostly just makes humans pick "P@ssword1!" in predictable ways. Four or five random words — a passphrase — beats eight line-noise characters and can actually be remembered, which is why it's what we set as the master passphrase in every session. Let the words be chosen by chance, not by you: the EFF's dice method (five dice per word, looked up on their long wordlist) is offline, free, and the most honest randomness you can hold in your hand. Human-picked “random” words are the leak.

The quiet connection to cryptography: your password doesn't unlock anything directly — software runs it through a key-derivation function to produce the actual cryptographic key that decrypts your vault or your disk. A passphrase is a key you can hold in your head, and entropy — honest randomness — is the entire game, there just as here. Guessability is the only thing the mathematics respects.

Source: NIST SP 800-63B-4 (2025); see the sibling site's glossary for passphrase mechanics.

Why security, privacy, and autonomy — says who?

Each corner of the trifecta has a literature behind it. Security as process rather than product is Bruce Schneier's long argument — there is no purchase that ends the problem, only practices that manage it. Privacy got its modern sharpening from Helen Nissenbaum's "contextual integrity": privacy isn't secrecy, it's information flowing according to the norms of the context it was shared in — which is exactly why a health detail told to a pharmacist feels violated when it reaches an advertiser. Shoshana Zuboff's The Age of Surveillance Capitalism names the economic engine that violates it at scale. Autonomy is the oldest thread: Ivan Illich's "convivial tools" — tools that extend the person using them rather than making the person serve the tool — could be this site's mission statement, and Murray Bookchin's municipalism makes the same argument for infrastructure held close to the people who depend on it. Cory Doctorow's "enshittification" is the modern autopsy of what happens without that corner: platforms decay precisely because their users can't leave.

Is there a better trifecta? The engineers' classic is confidentiality–integrity–availability, which is excellent for systems and silent about people. Others propose safety–dignity–agency. We keep ours because the three genuinely pull against each other — the frictions above are the proof — and a values framework you can't feel the cost of isn't one. But the question stays open on purpose; frameworks are tools too, and convivial ones can be put down.

Can I legally use that clip / image / song in my work?

Often yes — and the reason creators believe otherwise is one of the quiet enclosures this site exists to push against. US copyright law includes fair use: using copyrighted material without permission for commentary, criticism, teaching, remix, and transformation. The scholars who did the most to turn that from a lawyer's gamble into a working practice are at American University — Patricia Aufderheide of the School of Communication (founder of the Center for Media & Social Impact), with law colleague Peter Jaszi. Their insight, built out in Reclaiming Fair Use, was that communities of practice can write down their own norms: the resulting Codes of Best Practices in Fair Use — for documentary film, online video, teaching, poetry, libraries — gave creators, insurers, and platforms a shared standard, and they changed what actually gets made.

The working shape of it: fair use favors uses that are transformative — you're saying something about the material, or something new with it, rather than substituting for it — and proportionate: you took what the new purpose needed. It is a right you exercise, not a permission you await, and rights unexercised atrophy. Start with CMSI's codes for your medium; they're free, which is fitting.

This is orientation, not legal advice — the codes themselves are the real reference.

This is all free — what's the catch? (The question nobody asks)

We picked this one ourselves, because it's the question under every other question on this page. English has one word for two kinds of free: free as in cost (someone else is paying, and if you can't see who, it's often an advertiser paying for you) and free as in freedom — you can inspect it, change it, leave with your data, run it yourself. The free-software movement spent forty years learning that the second kind is what matters and the first kind is how you get trapped. Every swap on this page is really a move from gratis-with-strings to libre: the "free" analytics cost your visitors; the free-as-in-freedom counter costs you nothing but honesty.

The frontier of this idea right now is AI. The most capable models are gratis or cheap today the way rides and delivery once were — introductory pricing on a dependency — while the ability to run a model yourself, inspect it, and keep it when the pricing turns is the libre version of the same fight. A model on your own machine answering from an offline copy of Wikipedia is this century's community library. That's not hypothetical for us; it's the roadmap.

And the honest completion of the thought: libre is not costless. Somebody maintains it. That's what Index of /commons is for — the free tools are paid for by someone, and it should sometimes be us.

Notes for later parking lot

Things this page owes but hasn't paid yet. Kept visible on purpose; a draft that hides its debts is a worse draft.

  • A non-Apple track. Most worked examples here and on the sibling site assume iPhone / Mac / Gmail. Windows, Linux, and Android deserve their own tap-by-tap versions — being written now from a real rehearsal.
  • Password manager setup details worth a line each: leave the hint field blank (a hint that helps you helps the guesser); the manager's own 2FA recovery code goes on paper, never in the vault it unlocks; check the key-derivation setting (Bitwarden: Argon2id).
  • Recheck dates: the swaps list was checked October 2026, the registrar row September 2026. Run both again before a big push.