Trust & safety

Zero-auth is not no-auth

Last updated: 2026-09-14

flypod lets anyone publish a page without an account. The reasonable next question is whether that makes it a free phishing host. This page is the answer, written before anyone had to ask it in a hurry, and it describes what actually runs — including the parts that do not work.

Why there is no account wall

A login is a human interface: a browser, a redirect, a consent screen, a pair of eyes. Put one in the deploy path and the deploy path stops being automatable. Take it out and a person on a fresh machine, a shell script, a CI job and a coding agent can all complete the same deploy in one call with nothing provisioned in advance.

That is the whole product. It is not a stance about accounts — accounts exist, and signing in removes the expiry — it is that the first deploy has to be completable by something that cannot read an email.

What zero-auth is not

It is not anonymity, and it is not an absence of rules. Removing the account wall removes a blocking step, not accountability. Concretely, all of the following are true of a deploy made by someone who has never told us anything about themselves:

• Its contents were screened before it was stored, and are screened again on every update.
• Anyone who finds it can report it, without an account, at flypod.dev/abuse.
• It can be disabled immediately, by us, without notice and without waiting for whoever deployed it.
• It is deleted 14 days after it was created unless somebody signs in and claims it.
• It is rate-limited, per IP address, at both deploy and report time.

What is actually screened

The scan starts from one fact about a static host: flypod runs no server code, so a password typed into a page here cannot be stored here. It has to leave, to some absolute off-site address. That makes the distinction we care about narrow and checkable.

• A credential surface wired to an off-site collector is refused outright with a 403. A page that asks for a password and is built to ship it somewhere else is a working kit, whatever it looks like.
• A credential surface with no collector — a sign-in mockup, a design demo, a tutorial — is not refused. It publishes normally and gets 24 hours instead of 14 days. If it is what it looks like, a day is plenty; if it was a kit waiting for its payload, it expires before it is useful.
• Outbound links are checked against Google Safe Browsing for malware, social engineering and unwanted software.

That middle tier is the part worth understanding. Most systems like this have one decision — allow or refuse — which forces a choice between blocking real work and letting kits through. A short lifetime is a third answer: it makes being wrong cheap for the person who is wrong. A designer who loses a mockup after a day has lost a day. A kit that expires before its campaign starts has lost everything.

Every version is screened, not just the first. The oldest trick in phishing is to publish something harmless, collect the URL, and then replace the contents. Holding the token for a site proves you own it; it does not prove the bytes you are pushing now are the bytes that were scanned.

What we will not publish

We are not going to list the individual signals the scanner uses, because that list is a bypass guide. Anyone who wants to know whether a specific page passes can deploy it and find out, which is the same information without the map.

What gets through anyway

A careful attacker. This is not a hedge, it is the actual limit: nothing about a static file is inherently detectable as fraud, and a scanner aggressive enough to try would break legitimate sign-in demos, security research, and a large amount of ordinary web content. Screening is a filter, not a guarantee.

So the design does not rest on screening. It rests on making abuse short-lived, reportable, and cheap to remove — and on making sure that when something does get through, the damage has somewhere to go that is not the rest of the service.

Where the damage is allowed to land

Reputation systems can act on an entire registrable domain rather than a single page. A host that serves user uploads on its own brand domain is therefore one bad upload away from browser warnings on its documentation and its own sign-in email landing in spam folders.

flypod serves every site on flypod.page — claimed or not — while flypod.dev keeps the site you are reading, the docs, the API, account pages and email. They are separate registrable domains. A flag earned by a deploy cannot reach the domain everything else depends on.

Note that this does not depend on whether a site has an owner. Claiming a site is an email round-trip, which is not a trust signal worth betting a brand on, so claimed sites stay on flypod.page too. What claiming changes is the expiry, not the address.

What happens when you report something

Reports are read by a person — flypod is run by an individual, not a trust-and-safety department. Confirmed phishing, malware and impersonation get the site disabled; that takes effect immediately for every visitor, who then receives an HTTP 451 instead of the content. Disabling is reversible, so a mistaken takedown is not permanent data loss.

The intent is to look at every report the day it arrives. That is a commitment to effort, not a contractual response time — flypod is free and has no service-level agreement, and publishing a number we could not honour would be worth less to you than this sentence.

What is not done

A trust page that only lists strengths is an advertisement. These are open:

• Registration with reputation providers is not complete. Reporting flypod to Safe Browsing, SmartScreen and similar is currently how a report reaches them, rather than through a relationship we have already established.
• Authentication email still sends from the brand domain. It should send from a domain of its own, so that a deliverability problem in one place cannot affect sign-in.
• The scanner has known blind spots, documented next to the code that has them. Brand impersonation built from images rather than markup is the clearest one.

If you find something this page gets wrong, tell us. A trust page that is out of date is worse than not having one.