Why do services ask who you are?
An email address is often the first thing a service asks for. It becomes your login, your way back in when you forget a password, and the link between your contact details and the records held under your account.
That link has consequences. If account details and associated activity leak together, the email address can connect that activity to a reachable person. If recovery runs through the inbox, access to the inbox may provide a way into the account. If the password was reused, a breach somewhere else can put this account at risk too.
Look at what the service actually has to do, though: find your settings, recognize you when you come back, know who is allowed to change things, and know what has been paid for. An email address is one way to organize those jobs. None of those functions inherently requires one.
The paper explores how to keep those capabilities while removing personal registration from the access model. The practical question is how a service can reliably recognize an authorized participant without first asking for their name or email address.
Where DNS comes in
When a device is enrolled, it receives an encrypted-DNS configuration carrying its own credential. For DNS requests made through that configuration, the resolver checks the credential, finds the policy, member and device it belongs to, and confirms that the device is still allowed to use the service.
That check can do more than select filtering settings. A related application can establish which enrolled participant is requesting access through that authenticated DNS use. In ClearDNS, the dashboard learns which member and policy are involved this way, applies its own security checks, and permits actions according to the member's role.
Access set up this way can be maintained, withdrawn or recovered as people and devices come and go. These functions operate without a registration email or an email-based password reset.
It runs today
ClearDNS is built this way. Each policy has one set of filtering settings shared by its members and devices. Members are enrolled separately, each enrolled device has its own credential, and OWNER, ADMIN and MEMBER roles determine who can manage the policy and which activity each member can see. Billing is reserved for the OWNER. Recovery uses owner-held recovery material and the applicable security checks to restore access to an existing policy.
Because it is a running service, the idea can be checked. Does each device get the right policy? Do roles really limit what the dashboard allows? Does removing an enrolled device withdraw its access? Does recovery bring back the same policy?
The paper provides test procedures and reports selected observations from the service: enrollment, role enforcement, rejected credentials, device removal, session replacement, MFA login, recovery and changes to logging. The conditions of those tests are described alongside the results.
The service still handles technical identifiers, network information and service records, and purchases involve a payment relationship. What changes is that a name, registration email or account password is not required as the basis of access.
Read it. Test it. Challenge it.
The paper follows the design from enrollment through login, permissions, continued access and recovery. It also explains the privacy boundaries and security assumptions on which the system depends.
We welcome independent technical assessments, including critical findings and results that differ from ours. Publish yours wherever you choose, describe the conditions you tested and note the date. You can also send findings to contact@cleardns.io.
The Transparency Center documents how the service works and what data it handles.