Reviving BrowserID in 2026 • Hacker News Board

Re: Reviving BrowserID in 2026

#11

Post by wakamoleguy » Sun, Apr 26, 2026, 12:31 PM UTC

briansmith wrote: post #3

[I was at Mozilla during the development of BrowserID but I didn’t work directly on it. I was a huge fan of the effort.] Besides non-obvious UI issues, there were fundamental issues. One in particular that was very hard to overcome: Very few people would choose to hide which websites they are logging into from the identity provider. People don’t care whether their IDP can see when/where they are authenticating. That’…

That’s real, yeah. I also remember a couple concerns around that privacy as well. One being that if your IdP controls your email, they could probably figure out what sites your communicating with anyways. And perhaps a timing issue with when relying parties fetch the public key to verify assertions?

For bespoke projects, a lot of the privacy concerns go away once I’m using my own authentication in the first place (I control the full stack). So then the value would come more from federation (which is hard to bootstrap) or developer experience. I do still think BrowserID has something going for it there, potentially.

I do wonder if I’ll miss the centralized session management, though. I’m building this IdP to be modular, so I could try a different protocol on top of the user management core down the road.

Thanks for sharing!

Re: Reviving BrowserID in 2026

#12

Post by stavros » Sun, Apr 26, 2026, 2:06 PM UTC

wakamoleguy wrote: post #8

stavros wrote: post #7

Earlier quoted context omitted.

Sorry, I'm confused. What are the hoops? Wouldn't this be solved by Persona just telling the IdP the URL of the site to auth to?

The biggest one I’ve come across is the ability to manage and revoke sessions from a centralized location. With BrowserID, you can’t just sign out of your IdP and expect all relying parties’ sessions to invalidate. Instead, BrowserID asserts that you controlled the email at a point in time, and then it’s up to the site to decide how to manage the session afterwards. 3rd party cookie blocking makes this worse, since i…

Ah, yes, but that's a problem all IdPs have, no? You have to check in with the IdP every so often. I don't think this is insurmountable, Persona could have just added a mechanism to do that.

Re: Reviving BrowserID in 2026

#13

Post by sgoto » Sun, Apr 26, 2026, 3:37 PM UTC

You should take a look at https://github.com/WICG/email-verification-protocol and https://github.com/w3c-fedid/FedCM ... they also share a lot of the historical lessons learned with Mozilla's BrowserID.

Re: Reviving BrowserID in 2026

#14

Post by wakamoleguy » Sun, Apr 26, 2026, 4:14 PM UTC

sgoto wrote: post #13

You should take a look at https://github.com/WICG/email-verification-protocol and https://github.com/w3c-fedid/FedCM ... they also share a lot of the historical lessons learned with Mozilla's BrowserID.

Thanks! I have been learning about FedCM recently, but I need to read more. My understanding is that it requires the relying party to allowlist which IdPs it trusts, is that correct? That always seemed like it would make it gravitate towards social sign-ins, and harder for self-hosted email domains to participate.

I haven't come across the Email Verification Protocol yet, will take a look! At a glance, the flow seems almost identical to BrowserID. I'm curious how the UX looks.