most signup forms ask for an email because the form has always asked for one, not because the product needs it. the jobs that address is doing are worth separating, because each of them has another answer.
what the address was doing
- identifying the account, which any unique string can do.
- recovering it when the password is lost.
- proving a human bothered to receive a message, which is a weak abuse control.
- reaching you later with things you did not ask for.
- tying the account to a person, which is the point for some services and a liability for others.
a proxy account needs the first. it can replace the second. the third is done better elsewhere. the fourth costs you something and returns nothing. the fifth is the one worth thinking about before you sign up anywhere.
replacing the identifier
a random number works as an identifier if it is long enough that guessing is pointless and it comes from a real random source rather than a counter or a timestamp. the practical difference from an email is that nobody types it and nobody else holds a copy, so it behaves like a key rather than a name.
which means it should be stored like a key. a number that lives only in a browser tab is one crash away from gone.
# store the account number the way you would store a private key:
# out of shell history, not world readable, and not in only one place.
umask 077
mkdir -p ~/.config/myx
read -rsp 'account number: ' ACCOUNT && echo
printf '%s\n' "$ACCOUNT" > ~/.config/myx/account
unset ACCOUNT
# later, from a job
ACCOUNT="$(cat ~/.config/myx/account)"replacing recovery
email recovery is a trade. the provider can restore your access, and so can anyone who takes your mailbox, which is how a great many account takeovers actually happen. dropping it removes that path and hands you the whole responsibility. the trade makes sense when the thing being protected is a prepaid balance rather than years of irreplaceable data, which is exactly the case for a metered service you top up.
a passkey or a second enrolled device can put recovery back without putting an identity back, since both prove possession rather than naming a person.
replacing abuse control
an email in a signup form stops almost no automation. addresses are free and disposable ones are free too. what actually costs an attacker something:
- a proof of work challenge, which makes each account cost cpu time instead of a mailbox.
- per address rate limits on the signup route itself.
- a prepaid balance, since an account with no money in it can do nothing.
- making abuse cheap to unwind, because a service that can revoke quickly can afford to be permissive at the door.
a self hosted proof of work check has a second property that matters here. it runs in the visitor browser and reports to nobody, so a signup flow that collects nothing also tells no third party that the signup happened.
what it does not buy you
an anonymous account is not anonymous traffic. the site you fetch from still sees an exit address, a tls handshake and a header set, and it can link sessions on those alone. payment can carry an identity of its own: a coin bought with a verified card and sent straight to a top up address brings that history with it.
so treat the account as one layer that removes one specific link, the one between your traffic and a name held by your provider. the other layers are yours to build, and none of them come with the signup form.