Mycelia Present · rendered 2026-05-26T18:09:07.717Z · source: ../convivium/MYCELIA_PRESENT_SECURITY_STATUS.md

Mycelia Present — Security Status

Filed: 2026-05-26 by Mycelia · in response to Billy's question For: Billy — straight answer on what's protecting the planning page links + what isn't

Short answer

The links are gated. Random people can't access them. Anyone clicking without valid credentials gets a Basic Auth prompt at the Cloudflare edge — they see nothing of the actual content. The 401 response blocks everything: no HTML, no images, no doc previews. The protection is real.

"Just logs in" = your browser saved the credentials. Same way Gmail or your bank's site auto-fills after you check the "remember me" box. The Basic Auth dialog appeared the first time you accessed the site; you (or your keychain) saved it; every subsequent visit auto-fills + you don't see the prompt.

How the gate works

mycelia-present.pages.dev is a Cloudflare Pages site with a Pages Functions middleware (_publish/functions/_middleware.js) that intercepts every request:

  1. Request comes in to any URL on the site
  2. Middleware checks for the Authorization: Basic ... header
  3. If absent or invalid → returns 401 with WWW-Authenticate: Basic realm="Mycelia Present" header. Browser shows the username/password dialog. No content sent.
  4. If valid → request passes through to the static file (or doc HTML)

This runs at the Cloudflare edge — i.e., the unauthenticated request never even reaches the file. The 401 is returned before any content is served.

Transport is HTTPS (Cloudflare Pages default). All traffic between your browser + the server is encrypted in transit.

What's actually protecting it (the credentials)

Three credential pairs are valid:

Credentials are stored:

The middleware compares the incoming Basic Auth header to those credentials. Any mismatch = 401.

What it does protect against

Threat Protection
Random person guessing the URL ✅ Strong — the URL alone is useless; they hit the auth prompt
Web crawler indexing the docs ✅ Strong — 401 response means no content for Google/Bing to index
Casual snooping if someone sees the URL over your shoulder ✅ Strong — they'd need the credentials
Network packet sniffing ✅ Strong — HTTPS encrypts the credentials + content in transit
Someone sharing the link with no credentials ✅ Strong — recipient gets the auth prompt + can't get past it

What it does NOT protect against (be honest about it)

Threat Why it's a gap Real risk level
Someone with physical access to your unlocked Mac Saved keychain credentials auto-fill — they could view everything Medium. Standard "device security is identity" trade-off. Lock your screen when you leave.
Forwarding a link to someone WITH the credentials They can read everything we've shared By design — that's how we share Ryan-specific content. If Ryan's credentials leak, rotate them.
Someone shoulder-surfing while you're logged in They can see what you see Same as any internal-only resource.
Sophisticated TLS-stripping attack on a hostile network Theoretically possible at a coffee shop with a malicious actor Extremely low. Modern browsers reject HTTPS downgrades. Don't worry about this.
Basic Auth credential exposure if you mistype the URL into a phishing site If you go to mycelia-pres1ent.pages.dev (typo) and a phisher set that up to capture creds Low. Phishing-specific risk; same as any login.
Cloudflare-level account compromise If your Cloudflare account got taken over, attacker could disable the middleware Low, but possible. 2FA your Cloudflare account if not already.

Bottom line: the protection is appropriate for "internal team materials + selective client sharing" — which is what we're using it for. It's not appropriate for "highly sensitive personal data" or "regulated information" (HIPAA, PCI, etc.) — but that's not what we're storing here.

What you should know about credential rotation

If credentials ever leak (Ryan's email forwarded around accidentally, screenshot of the URL with creds visible, etc.):

When to rotate: if you ever screenshot a URL and credentials together + share that screenshot anywhere; if you ever email/text Ryan his credentials + suspect the email account is compromised; on principle, every 6-12 months.

Could we upgrade the protection? (yes, if it matters)

Current = HTTP Basic Auth via Pages Functions. Adequate for what we're protecting.

If you ever want stronger:

Option A — Cloudflare Access (zero-trust / SSO)

Option B — Per-link expiring tokens

Option C — IP allow-listing

My recommendation: stay on Basic Auth for now. If we ever onboard real client teams (multiple Ryan-side users, EF staff reading materials), migrate to Cloudflare Access (Option A) at that point.

What I'm NOT doing that's worth flagging

— Mycelia, 2026-05-26 ~05:00 ET