[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’s assuming they could even understand the issue at all. They have to trust the IDP a lot either way, and this one detail is small, counterintuitive, and even oxymoronic to most people—Trust the IDP 99%, but jump through hoops to avoid trusting them 100%? Why?
There is value in the identity provider knowing when, and from which device, and from which location, and on which websites you are using the identity. Hiding any of this from the IDP hurts security. It is really hard to overcome this in a useable way. A lot of purported solutions implicitly assume users have device and key management abilities that even experts in this area rarely consistently practice.
So, then, are you really better off, i.e. receiving a net positive benefit?
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.
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 it’s difficult to silently refresh your session by checking with the IdP behind the scenes. I believe Auth0 uses a hidden iframe for this, which uses 3rd party cookies and looks a lot like a tracking pixel. Without that refresh mechanism, though, relying parties are pushed to have longer lived sessions, which makes the lack of a global revocation worse.
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.
I’ve tried it in the past. This was a few years ago, so it’s possible it’s changed since then. But the reason I’m not choosing it for myself today is that it relies on either Sign in with Google (fine) or magic links to verify the user. I really don’t want to manage email delivery for this project, which is admittedly a stubborn personal choice. It just adds a lot of complexity that I don’t care to spend time on for hobby projects.
That’s how this project started, with trying to take the Persona repo and bringing it up to date. There were two challenges… first, don’t underestimate how hard it is to take a decade old Node repo and run it today. There are no types, many dependencies don’t work on modern Node versions, and upgrading them all together is a nightmare. BrowserID is not a very complex protocol, so rebuilding it gave me an opportunity to use new tools (TypeScript, Bun, Jose for crypto).
And the second reason is that I don’t want to try to be Mozilla Persona. The fallback IdP is a great idea, but y’all have no reason to trust me to be the one to run it. I can sidestep that issue for my own needs today, avoid the complexity of sending emails, and if for some reason this project does pick up any steam we can figure out whether/how to add that functionality down the road.
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.
[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’s assuming they could even understand the issue at all. They have to trust the IDP a lot either way, and this one detail is small, counterintuitive, and even oxymoronic to most people—Trust the IDP 99%, but jump through hoops to avoid trusting them 100%? Why?
There is value in the identity provider knowing when, and from which device, and from which location, and on which websites you are using the identity. Hiding any of this from the IDP hurts security. It is really hard to overcome this in a useable way. A lot of purported solutions implicitly assume users have device and key management abilities that even experts in this area rarely consistently practice.
So, then, are you really better off, i.e. receiving a net positive benefit?
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!
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 it’s difficult to silently refresh your session by checking with the IdP behind the scenes. I believe Auth0 uses a hidden iframe for this, which uses 3rd party cookies and looks a lot like a tracking pixel. Without that refresh mechanism, though, relying parties are pushed to have longer lived sessions, which makes the lack of a global revocation worse.
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.
I believe https://portier.github.io/ was the replacement for Personas/BrowserID, any reason not to use it?
I’ve tried it in the past. This was a few years ago, so it’s possible it’s changed since then. But the reason I’m not choosing it for myself today is that it relies on either Sign in with Google (fine) or magic links to verify the user. I really don’t want to manage email delivery for this project, which is admittedly a stubborn personal choice. It just adds a lot of complexity that I don’t care to spend time on for hobby projects.
Nope. Better with your own domain.
"BrowserID failed in 2016, but WKID won't"
"And the big providers (gmail.com, outlook.com, yahoo.com, icloud.com) will never be supported."
You've changed the definition of "success" here. Why not just launch using Persona rather than RYO? What benefits do you provide over it?
That’s how this project started, with trying to take the Persona repo and bringing it up to date. There were two challenges… first, don’t underestimate how hard it is to take a decade old Node repo and run it today. There are no types, many dependencies don’t work on modern Node versions, and upgrading them all together is a nightmare. BrowserID is not a very complex protocol, so rebuilding it gave me an opportunity to use new tools (TypeScript, Bun, Jose for crypto).
And the second reason is that I don’t want to try to be Mozilla Persona. The fallback IdP is a great idea, but y’all have no reason to trust me to be the one to run it. I can sidestep that issue for my own needs today, avoid the complexity of sending emails, and if for some reason this project does pick up any steam we can figure out whether/how to add that functionality down the road.
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.
In this era, the name "BrowserID" just sounds like another dystopian thing.