Summary

  • Mozilla's BrowserID became Persona, a login system based on verified email addresses. The website kept a direct account relationship without asking its visitor to create a site-specific password.
  • Mozilla ended support for persona.org on 30 November 2016 and shut its hosted service at the end of that year. Its migration guide told relying websites to replace the verifier, JavaScript shim, fallback identity provider and bridges; one suggested path was to authenticate an existing user through Persona once more, then give that account a local password.

Picture a returning reader clicking a site's familiar sign-in button. The site's database still contains her email address. That string says which account she wants, not whether the person at the keyboard owns it. During Persona's life, a separate authentication flow supplied the proof. Mozilla's retirement turned that distinction into the website operator's job.

In December 2011, Mozilla described BrowserID as both a user-centred identity protocol and an authentication service. It said nearly 1,000 sites relied on it at that time, a contemporary Mozilla estimate. The project was renamed Persona. Its September 2012 beta announcement sold a clear bargain to websites: visitors could sign in without creating another password, while the site still received their email address and kept its direct relationship with them. The email was chosen as a portable account handle. The promise also depended on a working way to verify it.

Mozilla's 2013 technical account lays out that operating path. Persona looked at the domain of the email address. A provider with native Persona support could authenticate its own user. Otherwise Mozilla's fallback service handled the request: an identity bridge could use an existing provider login, or Mozilla could send a confirmation email. The article concerned a resolved security flaw in a bridge, but its architecture description is the useful record here. It shows why an open protocol could still leave many real logins dependent on Mozilla-operated services.

The organisation's commitment changed in stages. A March 2014 Mozilla meeting record said Persona was moving to community ownership. Mozilla would keep supporting operations but stop funding new feature work. The later migration guide says it continued operational and security support through 2014 and renewed that commitment for 2015. Low, declining usage and the cost of running an authentication service at the required security and availability level drove the exit decision. Support ended on 30 November 2016; persona.org shut down at the end of 2016.

The guide names the pieces that would stop: the persona.org website, its JavaScript shim, the fallback identity provider, identity bridges and hosted verifier. It also says Mozilla would keep the domain rather than transfer it, to protect sites that had failed to migrate, and destroy user data held on its service. Open-source code remained available. A website still using Mozilla's hosted verifier could not treat that code repository as a live login endpoint.

The sharpest paragraph in the guide concerns existing accounts. Mozilla had intentionally exposed email addresses to relying websites instead of opaque identifiers, so another system that verified the same address could help preserve the link to an account. For a site choosing local passwords, it suggested asking a user to authenticate through Persona one last time, confirming the email address while the old proof path still worked, and then setting a site-specific password. It also listed passwordless email links and delegated authentication as alternatives.

Self-hosting the Persona stack was possible in principle, but Mozilla warned most sites against taking over a large, complex codebase without future Mozilla security updates.

That final Persona login was a migration window, not a ceremonial farewell. After the hosted proof path closed, the account record still contained an email address; the website needed a new way to establish that a returning visitor controlled it. Mozilla did not publish a count of completed migrations or stranded accounts. The operator choice was concrete nonetheless: build the replacement while the old verifier could still speak, or devise a different account-recovery process after it fell silent.

Original records