update: add "Anonymous sign-in" authentication method - #3246
Open
amrabumady wants to merge 1 commit into
Open
Conversation
Adds a new subsection describing the locally-derived pseudonymous identifier pattern (HKDF over user seed + origin) as a fourth authentication method category, alongside email/password, OAuth, phone, and username/password.
Contributor
|
It is pseudonymous, not anonymous. |
friadev
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds a new subsection under
## Authentication methodsdescribing theanonymous sign-in pattern — where the client locally derives a site-specific
pseudonymous identifier (typically via HKDF over a user-controlled seed +
origin), so the service never receives PII and cross-site correlation is
structurally impossible.
The pattern is currently underrepresented in the Privacy Guides documentation
even though it has direct privacy-relevance: it is the only authentication
method in the page that does not require trusting the service with any
recoverable identifier.
Structure mirrors the existing subsections (Email and password, OAuth, Phone,
Username and password): one-sentence intro, "main advantages" / "but there are
disadvantages" lists, a closing paragraph on appropriate use, and one reference
to an open-source implementation for readers who want to dig further.
I've deliberately kept the implementation reference to a single open-source
project rather than promoting any hosted service. The substantive value of the
section is the pattern explanation; if maintainers feel the GitHub link is too
much, dropping it leaves the section intact.
Happy to revise wording to match house style — I tried to follow the tone of
the surrounding subsections but I'm new to the repo's conventions.