Thank you for the thoughtful post. I enjoyed reading the W3C document,
which closely mirrors my own thoughts on the pluses and minuses of this
I don't think capability URLs are a good authentication mechanism for MDN.
I wrote a very long post explaining why, but I think I can summarize it
without boring everyone.
Capability URLs are a good match for task-specific authentication, like
password resets, and metered, shared access, like an API URL for a team.
They are not a good match for reputation-based authentication system.
MDN authentication has two purposes:
1) Collaboratively edit MDN content
2) Access MDN administrative functions
Collaborative editing requires trust. We watch new edits closely, to
determine if a user is abusive or just misguided, and quickly remove
access. As a user proves themselves, they are watched less closely, and
are given more editing permissions. Capability URLs make it too easy for
bad actors to establish new accounts, and increase the spam mitigation
effort on MDN, distracting from adding features and content. "Easy account
setup" is not a feature for MDN.
Because they auth mechanism is a URL, it appears in browser history, as the
referrer for the next page, in user emails, in IRC chat logs, in server
logs, and in the database. This increases the number of places that an
attacker can acquire a capability URL. Since they are easier to steal, they
can more easily turn a good account into a bad one, which can be harder to
detect and stop.
There is a suite of other pieces needed to secure a capability URL scheme.
This includes a cryptographically strong random number generator, detection
of multiple requests from the same IP address, detection of a distributed
attack from a botnet, extra security around access to the database and
server logs, a "URL reset" mechanism, an email account that is trusted by
email providers for delivering the URLs, a strong "unsubscribe" policy that
is accepted by the providers, challenge questions, 2-factor auth support,
and others. These are similar to the pieces in a secure username+password
setup, which is why that is not being considered either.
In a lot of ways, Persona is the "version 5.x" of a capability URL scheme.
All the authentication happens in one place, so you can concentrate your
resources to make that one place secure, and detect and block the abuse.
An email is sent to confirm an account as needed or to reset a password,
but the browser is leveraged to remember the login. The user logs into one
site they trust, and then the other sites (like MDN) just trust
. Optionally, email providers can sign up for advanced
login capabilities, like substituting Google login, with 2 factor auth and
And, Persona didn't catch on, and is now cancelled. Authentication is hard.
So, what do we get with GitHub login?
1) We delegate all the security stuff to GitHub. They mess with SSL
certificates, abuse detection, IP blocking, etc. etc. They need it for
their business to be successful. And GitHub is a business, so they can
justify paying good people to get it right.
2) They offer stronger login than just username and password. I have 2
factor authentication enabled on GitHub, and I recommend everyone else does
3) When a user signs up with GitHub, we get to see their history on the
site. This is a huge benefit on the code side. For example, this user
just added some translations to the MDN UI in Frisian:
I don't know Frisian. Did he just add obscenities to the site? Do I need
to plug them into Google Translate and figure it out? Well, I feel a
little more confident, because he has a long history of translating other
When a user with a GitHub history shows up for a first edit on MDN, I can
see that she's probably making a good change with good intentions. Does
this person even know CSS? Well, if her GitHub account includes a demos of
some CSS animation experiments, they may know a thing or two.
Finally, as we formalize some of the content structures, such as browser
compatibility and demos, we're increasingly leaning on GitHub for storage
and collaboration. This effort will only increase in the future, so it's a
natural fit to have a strong link between activity on GitHub and activity
I think capability URLs are an interesting idea, and useful for several web
authentication scenarios. However, as a site matures, it needs to switch to
stronger authentication, and I think it would be a step backwards for MDN
profiles. If we add an alternate, user facing login method, we're more
likely to pick another delegated authentication provider, and probably from
Thanks for your feedback, and I hope you continue contributing after adding
GitHub auth to your MDN profile.
> dev-mdn mailing list