Shutting down persona.org in November 2016
mail.mozilla.org
mail.mozilla.org
After writing about four of these, though, I had a small epiphany; this is a ludicrously uphill battle, because Facebook and Google don't just make it easy to use their login because they're nice; the information that they gather from these logins is worth good money to them, and so of course facebook+google login is the most frictionless and butter-easy way to implement login.
Sigh.
Okay, I know this was totally obvious to everyone but me, but it does make me sad, and I can start to see the outlines of an internet that I'm somewhat less excited about than the one we have now.
I'll miss you, persona. Mozilla, keep up the good fight!
I also am working on offering both a FreeDNS service with DNSsec both as an authoritative server for all end-users (services like GoDaddy mark this, as well as SSL certificates, as a "premium service" and that is sheer insanity; I have made it my personal goal to ruin services like this and "SSL watchers" which charge 20$/mo to ensure your cert doesn't expire). Also don't use OpenDNS, not only do they inject ads, but they break DNS by stripping DNSsec which is both unethical and a violation of the spec. I'll have a blog post up on that later this week.
If you have a web-site, don't have shell access but still want to put a cert up, https://www.sslforfree.com/ use these guys. They'll authenticate your ownership the same way Google Analytics does, then you associate the cert with your domain in the same way you would had you bought it from VeriSign.
[0] https://www.surveymonkey.com/r/VLFM7FD - please fill this out if you have either interest in Persona or that DNS service I mentioned (the latter of which is likely to go up this week, the former depends on demand)
- There have been Persona extensions before for at least Firefox. It will probably be important to learn from them, even if I'm sure hardly anyone tried to use them.
- Edge's extension support can't come soon enough.
- The issue I could see with extensions is it is harder to trust the verified email addresses in "fallback" situations. The chicken and egg bootstrap problem here still seems to indicate that you still want some sort of trusted notary. Maybe a simpler fallback provider that is just a state-less "passwordless" (passwordless.net) proxy that would be easy to clone and some way to create an actively maintained whitelist of trustworthy clones?
- While we're looking at "extension-first", maybe find ways to make use of the browser's SSL client certificate infrastructure? Obviously, if you could build a good UX for bootstrapping (email-only) client certificates you could finally help people make good use of such an old, underutilized browser feature.
> There have been Persona extensions before for at least Firefox. It will probably be important to learn from them, even if I'm sure hardly anyone tried to use them.
Do you know some? I only found https://addons.mozilla.org/en-US/firefox/addon/browser-sign-..., which is old (but new to me) and it seems defunct. I'm not sure whether the source code is accessible. https://www.youtube.com/watch?v=um0Ym-Yma8Y looks nice though.
Thanks for the hint to passwordless.net. A simpler fallback-provider might be exactly right, maybe even something for stage 1.5.
The BrowserID protocol actually has a user certificate as endpoint. I'm not sure how and whether that is stored.
YMMV though, maybe I'm not approaching the social login from the right angle, I don't know.
The saving grace here is that what I hold for users is the email address and that gives me a path to switch to another provider so long as I get an email address back.
In many ways this is a blessing, at least I now know where I stand. No doubt my spare time is going to be used up over the next month or two.
But then I've taken on the maintenance and security of a system that I am not familiar with the internal workings of. That seems riskier than finding an alternative.
There are some strong auth/auth open source communities - https://github.com/Jasig that serve millions of users.
i.e. i wish projects like this the best of luck and hope to be using them later :)
The proposed UI was not blocking anything, not even taking space.
Given Persona survives this.
Heck, some of the code still dates back to when Node.js was only on version 0.4.5. :)
I, literally, cannot rebuild my application from a year and a half ago that is standard node + npm. The deps are broken...the code won't build with node-gyp...i mean node-waf...i mean who knows? What a mess and a HUGE regret.
Welcome to the Cloud Future Web 3.0, where every library you use is maintained like some random guy's personal homepage, and his robots.txt prevents you from caching a stable copy.
Besides, there's no universal unwritten rule stating that you have to use the bleeding edge version of every dependency.
Keeping all dependencies up-to-date is mostly in the interest of widely used libraries not one-off applications.
I did find a few libraries that have been completely abandoned...like 2/3 of the libraries I used.
I then spent a few hours downgrading each version to isolate the issue...found a few libraries that were hard-deprecated (which was nice), found some breaking changes in the node version I'm using and then I just gave up.
Having used both, Node's package system is horrific compared to PHP's Composer. Composer's built-in composer.lock system is something NPM sorely needs by default.
There's a third-party tool [2] that is supposed to solve many of the issues, but I haven't tried it.
Of course, if you do this, there's a decent chance that if you try installing it again in 6 months, your shrinkwrapped version of at least one of the dependencies won't be available any more...
[1]: https://docs.npmjs.com/cli/shrinkwrap [2]: https://github.com/uber/npm-shrinkwrap
Biggest wart I've encountered is I've got a package that installs fsevents (OSX-only) as one of its optional dependencies. When I shrinkwrap and attempt to install on a Linux server, that optional dependency is treated as a required one, and it can't install. I have to manually zap it from the JSON. :-/
Persona may have been a bit premature in choosing Node, but we expected to share much of our code between the backend, frontend, and Firefox itself. Node offered a great opportunity to attempt that. Plus, the whole thing started as a side project between two engineers, so why not try out something crazy and new?
annual LTS releases, each with 30 months of security
You do not even know how to interact with people like a proper adult. There are many companies, large or small, using PHP. Many popular blogs run on moveable type, that's Perl 5. Many companies run on Microsoft technology. And some popular websites run partially or wholly on Node.js. So what? Should I make my technology decisions with a « jump on the most brightly coloured bandwagon » approach? Node.js is a toy. A cheap chinese one.
We tried our best to ensure that there was never any lock-in with Persona, which makes a transition away possible, but not painless.
Now that we have a formal announcement, I'm hopeful that folks on the sidelines will take this as a cue to stop pining and start building. :)
EDIT: To curtail the "I'm in SF/BOS/etc." posts: I'm in Minneapolis. Maybe we should set up a Hangout or similar early next week? If you'd like in on that, subscribe to https://lists.mozilla.org/listinfo/dev-identity and I'll post details there.
I wouldn't mind getting a brain dump of how you'd do it differently were you to build it now, as well as my sharing what I'm looking for... perhaps a Persona v2 design could rise from the ashes.
Besides, isn't rising from the ashes what Mozilla does? "And so at last the beast fell and the unbelievers rejoiced. But all was not lost, for from the ash rose a great bird..."
A Persona v2 if you will.
A few of us are chatting about it, look for letsauth on this page for details.
What gets me is that even in this announcement, they place the blame on the community "due to low, declining usage", instead of owning up to the fact that they never implemented BrowserID in Firefox (desktop) as envisioned. With no carrot, why would they expect sites to jump on board?
So why should anyone in their right senses bet on a Mozilla project in a serious way?
They have put themselves in a catch 22 situation. Abandoning projects because "people are not using them" and people will not use them because Mozilla abandons projects.
Interestingly, most of these abandoned projects were promising but I cannot recollect Mozilla ever changing course as a result of feedback given when they launched a project.
This is quite unfortunate.
Bet on any third party service in a serious way and you are taking on risk that you cannot control. That's a fact of life.
But in any case - Does google abandon projects with the same frequency?
http://www.lemonde.fr/pixels/visuel/2015/03/06/google-memori...
That list isn't so simple. Accelerator isn't software/service, refine became open-refine, and wasn't a service. Wave didn't seem to get a great deal of uptake (I think), and is somewhat superseded by google+ in-chat. I'm not sure how checkout differs from wallet. etc.
So in those case, there is a marked difference as compared to, for example, when google discontinued reader.
I also wonder how many of these projects are abandoned in name, but not in copebase? Google+ probably rebrands some of those, with a slightly different mission statement (new feature, rather than standalone product).
That said, I do dislike some of the focus on social-media. The facebook effect, I guess... We probably need more protection from it...
In fact, the opposite needs to happen. For a project to grow, it needs to attract core contributors, not repel them. This is especially true if the project's core contributors don't have an obvious business model to help pay for their time.
Mozilla tries its damnedest to avoid locking people in, and promoting open, standardized solutions.
Persona provided verified email addresses for your users, so there was no intrinsic barrier to migrating off of Persona and to, say, a traditional email + password login scheme. With Firefox OS, building an awesome FxOS experience was synonymous with building a great mobile web experience, because the foundation was in open, standard technologies. Even if FxOS went away, you're left with something great that works in other browsers.
This shit is _important_.
GNU gave us the tool-chain, Linus+co. (and BSD!) gave us the kernel, Mozilla gave us the web client, Apace gave us the web server and so much more. For a few years there I thought that FOSS had delivered the software world I could live in.
But then came the era of the internet and my data and identity in the cloud. And tracking. And surveillance. And social everything. And why? Because of shiny pretty interfaces and convenience and humans being human.
Surely this is our `Stallman and the printer' moment for our generation. I know the FSF and EFF and others do a great job. But we're losing these battles.
I think the hard part about this current iteration is that, say, with GNU C there's the C language standard, with Linux there's UNIX. There's something you can strive to be compatible with. Where is the online identity management standard? There is none, because that's the whole point. Same with social.
These corporations are behemoths. Facebook/Twitter/Google/Microsoft, the list goes on and on. Before it was really just Microsoft on the desktop and a load of ageing UNIX vendors -- we've never seen the like of these new businesses. This is a sector that briefly had the most valuable corporation on the planet. This is an immense task. But it's doable. FOSS has won the server wars, has a viable desktop, has transitioned to mobile. But identity and social, you know, the stuff that makes us human, not so much.
Time to act I reckon.
Browserid was launched right when I was learning about loginsystems, and it was so nice to use it instead of fighting with hashes or certificates. I still think that it is the right idea, persona should not die.
Honestly, I almost want someone to fork Persona and keep it alive. Persona is at least a real service that people know how to integrate that has a solid concept. The yet-to-be-invented-hypothetically-better potential successor doesn't have that.
But perhaps I might fork it, if only to use on my own sites.
https://news.ycombinator.com/item?id=10789556 Discussed here further. Like with OpenID, the problem is vendors remove support for OpenID.
Right now there's a very, VERY good standard made by OASIS (standards body on par with IEEE/ISO/W3C)- SAML, which with a YubiKey[4] and a cell phone app for managing permissions gives you a really nice setup. The flow is basically plug-in your YubiKey off your key-chain, then authenticate once when you log-in at the start of the day, anything that implements SAML will now give you a SSO (similar to AD/LDAP) but it's two tokened with a focus of ease of use for Joe Blow (as simple as a Push notification to your phone (authentication comparment #3) saying "App Foo is asking for permission for you to log in. <Slide left/right for approve/deny> while giving you granular control for the power user. Again, chicken egg adoption problem, but its the most elegant I've seen.
https://wiki.oasis-open.org/security/FrontPage http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-... http://saml.xml.org/wiki/idp-initiated-single-sign-on-post-b... [4] https://www.yubico.com/2015/10/github-yubico-u2f/
SAML2 has a lot of heavy usage in academia or between industry systems. That being said, there were a lot of exceptions and rules that needed to be put into place for the plethora of broken SAML2 implementations. Some needed an attribute in two scopes, others had trouble with certain OIDs, etc. The Shibboleth mailing list is filled with things like, "oh if you're trying to connect to someone using Oracle SSO, add x y and z because their stuff is hopelessly broken."
I mean for the most part, it did just work. I see it as great when you want to build trust relationships, but in the general case, I think OpenID was simpler and better.
I still run my own OpenID. It gets me into ... StackExchange. It no longer works with Slashdot, gitorious, freecode and many other sites that have either stopped supporting it or gone under. Oh wait, it works with OpenStreetMaps too.
Is that SAML2 IdP code open?
Things have..slowly... improved within the SAML2 ecosystem, but if you've found a better alternative (SSO for the average Joe - preferably with 2FA a la YubiKey) let me know.
Having the ability to easily manipulate attributes at a per-SP level makes integrating with semi-broken vendor implementations much more practical. There are modules available to add OpenID and OAuth; I use the OpenID module in production and have been quite happy with it.
critical mass
It's probably a reasonable service but I'd never implement it on my website because I know I'd be telling customers to go off and setup a Bitcard account, which they would have never heard of.
With all the dollars pouring into Internet companies, we are unable to develop open protocols for crucial services, like verifying an email of a user, or having an encrypted connection to a server without the server owner paying x$/year for a certificate.
Frankly barely anyone cared about the net until the dot-com boom made the web "shiny".
Turns out neither the Mozilla Persona main page nor the developer docs linked therefrom mention this timeline. Shouldn't there be a huge banner at the top warning visitors that maybe starting a new project using this tech is a bad idea? Or at least some sort of link to this post?
0. Provide a drop-in replacement for persona.org, making it unnecessary to migrate to another loginsystem.
1. Rework the Persona code, so that it becomes possible and easy to selfhost it, also outside of the new project. All the feature-creep stuff callahad was mentioning should be purged.
2. Work on the browser integration. It would already be great if sites could specify in a meta-tag in the head "login via persona supported" and the browser would show a login UI, even if in the background nothing changes. Even if it would just load the JS and UI currently loaded, but from the plugin instead from the server, this would at least speed things up and be a good starting point.
3. Try to keep the gmail integration, extend it to other mail providers (I'm not sure about the current situation there).
What am I missing? I'm sure there is more, and it would be a big project already.
Talk to me: niran@niran.org
I've had a discussion about this, admitted that credentials and identities are different matters, but were unable to remember or think of any sane solution to this problem. :(
If you know of any — please share!
Decentralization doesn't mean no one's in charge. It means you get to choose who's in charge, and there's zero barrier to replacing someone you put in charge.
This seems sort of like saying, "If you switch to OpenID, you can run your own provider on your own website." Wonderful, but in practice people use some third-party OpenID provider. (A couple people might run a static website with the appropriate link-rel tags, so they keep control of the name but they're still delegating the actual auth work to a third party.)
Is the standard program going to be to grant access to a key + 3-of-5 friends? How do you enroll if you don't yet have 5 friends on the system?
As the ecosystem iterates on identity programs, we'll converge on secure, reliable, decentralized backups.
Like, compared to publishing a public key. Simplicity doesn't seem to be an answer.
What does a blockchain add to this?
PGP key servers can refuse to relay your revocation. Blockchains are censorship-resistant. They also let you define your own authentication, revocation and backup logic.
PGP identities are keys. Blockchain identities are programs.
Specifically, a miner can refuse to encode your transaction just as much as your first PGP server can refuse to accept the sent key. (PGP actually has a strong advantage here, since it's easy to push your revocation to all the servers on your own, immediately, but you yourself are extremely unlikely to mine a block with your own transaction, unless the network is otherwise broken security-wise.) So the primary thing to worry about is a server that refuses to provide information on the revocation, once it has hit the shared database. But that can be solved by just having cryptographic monotonicity, that no transactions can be removed once encoded; you don't need the blockchain's specific power to order transactions and resolve conflicts. And a Merkle tree provides monotonicity. Certificate Transparency works this way.
I agree that the PGP keyserver infrastructure doesn't currently provide this; I'm just asserting that it doesn't take a blockchain to provide it, and there are significant downsides (like waiting for a transaction to commit) to taking that approach.
One thing that a blockchain would provide is the ability to revoke one key in favor of another, and uniquely determine which key supersedes the old. But it's not clear how important that ability is and whether it justifies the tradeoffs of a blockchain approach.
So I'm changing my argument: I think key succession is very important and blockchains do it better. When you revoke a PGP key, you have to rebuild your web of trust from scratch, right? The key is your identity, and continuity is hard. With blockchains, a program is your identity. I can trust your new key immediately if the backup process your program encodes has been fulfilled.
PGP keys can't be used to build identities that are as permanent and resilient as state-issued identities. Blockchains can.
Can you please comment here (or set up a webpage anywhere), explaining the overall ideas and proposals?
If your idea of user-controlled identities is truly about something that users do possess (not just being provided), and you have any plan how to bring it to the world (without for users to need to install any software — that'd utterly fail — or do anything much besides clicking "log in as myself") — then I'm all for it.
___
¹) Although I do believe Persona screwed it badly, as identities weren't controlled by users there, but merely leased to them by third parties - I find the concept of "identity provider" to be very wrong.
Well, IANA does. Then, if it's a ccTLD, your NIR (controlled by your government) does. Then the registrar you've registered domain name with does. They all do lease it to you (although legal agreements sort of say you "own" it, it's not a true ownership), but in practice they can take away your identity at any time they see fit or forced to. Or impersonate you, without your consent or even knowledge. I think we've heard about enough domain name seizures to not assume they're something owned. And an identity that can be seized or revoked is something that's just not right.
I really want an identity system without need to trust any third parties to work. I walk in a store, I say "hi", they say "hi", and we're good. Just like it used to be with usernames and passwords, but without obvious issues passwords have. Notaries are absolutely useful, but they should assert identities ("yep, we know this dud, he's cool"), not provide them.
Users will have to install something because browsers have no key signing mechanism. If you manage keys in a web page, that web page can access your keys. You'll need an extension or an app to manage keys for you.
This approach sounds like a stretch, right? No website is going to use an authentication mechanism that requires a separate install. If that were the initial use case for this, I would agree. The real use for these identities is within decentralized applications. These apps don't run on servers and don't force you to use middlemen when you interact with other people. Decentralized apps don't shut down. They don't care where you live. They connect you with other people on the planet that want to connect with you to trade, communicate, or interact in any way you want. The two of you choose your own rules, not those of the companies or governments that stand between you.
This is not a replacement for Persona, OpenID or "Log in with Google/Facebook/Twitter" buttons, which was what I hoped to see. And I'm not even sure how this is better than my PGP keypair (which is something way more widely recognized than Ethereum).
Is there any skilled and powerful necromancer out there that can revive and reanimate W3C WebID committee?
Yes, they do. See this long list of failed altcoins.[1]
Minor cryptocurrencies can fail in some unexpected ways.[2] The classic 51% attack has happened in practice to several altcoins.[3] There's also a "burst mining" attack, which can happen automatically - a big mining pool's control system determines that it would be profitable to divert the pool to briefly mining some altcoins and get all the blocks for a while. Then the difficulty goes way up, and the big pool goes off to do something else. Now the difficulty is so high that no blocks get mined at all for a considerable period of time and transactions stall.
[1] https://bitcointalk.org/index.php?topic=588413.0 [2] http://www.ofnumbers.com/2014/06/03/thread-of-the-day-list-o... [3] https://maxminer.files.wordpress.com/2013/06/ftc_51attack.pd...
https://okturtles.com/ is the most successful of them so far. I am not a crypto expert (even less of a blockchain expert) but the code looks pretty good, and the ecosystem is pretty mature. It has 1) its own aux. DNS service which is tied to your key (somewhat like Tor routing via onion but with acceptable latency), 2) decentralized IdP via block chains, 3) a browser plugin, 4) a whole lot more (see the Github linked below.
From the article:
Update I’ve written a more-up-to-date technical overview of okTurtles, DNSChain, and Unblock.us. While the security model for DNSChain has improved, they are still misrepresenting the security parameters of their software.
I’m going to leave this up since it debunks what DNSChain was selling. I also think their resistance to outside security concerns is very troubling.
TL;DR
DNSChain erroneous claims to have passed a “peer review” process. However, its most important peers, Namecoin developers, have rejected it. This has been the reaction of every Namecoin developer who has evaluated the project (over four at this point). The project misrepresents its security model, its design is unfixable, it should not be used in any nonlocal capacity.
https://pilif.github.io/2008/05/why-is-nobody-using-ssl-clie...
Then, I did not hear of it again. Now, this. I have a couple of observations.
Branding this as "Mozilla Persona" makes it look like all the other corporate "one-time" login things out there. Apple ID, Microsoft Live, what have you. I don't need one more account controlled by a corporation. Mozilla looks like a corporation to me (maybe it is not, but it looks like one). I do not automatically trust everything with the Mozilla brand on it.
Adding Persona to a website is not that easy, from the developers' standpoint. I looked at it for a while, and couldn't be bothered. From the server side, it's just so simple to authenticate users with passwords (or access tokens derived thereof). It would be wonderful if the browser could just take care of everything, if all users really need is a way to securely authenticate. Currently, it seems to me like password managers are winning this game.
I'm hoping to see something where password managers are extended with protocols to allow more data and access to be shared to services I really use.
Yes one can program own username/password etc login, but it is actually alot of work making a proper one with all the edge cases (, password strenght, email validation, verification, account recovery) and so on and so on. I know because I have done it dozens of time and each time the project has slightly different requirements
Mozilla Persona was dead easy to implement on the other hand! Also alot of people did not like and complained about having to login with Google, Facebook etc yet the same people had no issues trusting Mozilla due to the goodwill they built up with firefox and their fight for privacy
Especially compared with usernames and password, which is basically built in to anything already.
I think that usernames and passwords are "easy" is something of a sunk cost fallacy, both for developers and users, and we tend to forget how much time and effort we "waste" on this year over year. My password manager is up to hundreds of different passwords I use, and I know a lot of users these days whose "password" starts with the now ubiquitous "Forgot Password" button (which is its own headache to setup and get right), as they are okay relying on the relative security of their email address over the fragility of their own memory.
I honestly thought that's what it was so had never considered it when looking at authentication. Whoops.
SSO will remain the dominion of big players with a lot of money to burn.
With time, more and more users are going to wake up to the privacy issues with the current web, and a common login solution that is NOT Google or Facebook is critically important in order to avoid getting tracked online.
Persona should be improved to be a natural fit for Firefox users rather than to be shut down. The demand for common login is there and people pick Facebook and Google today because they dont understand the need for privacy. But sooner or later they will get quite tired of being tracked and want a good alternative. Mozilla should be there for them when they do.
Consider this for a browser-integrated login system:
- Browsers directly provide an API for sites to say they need to say "this site wants an account".
- When the browser sees such a request from an origin that the user doesn't have an account for, it provides browser UI to create an account and log in. Creating an account creates an origin-specific keypair in the browser and hands the site the public key; logging in uses a challenge-response protocol to prove ownership of the private key.
- When the browser sees such a request from a site the user has an account for, it provides browser UI to log in via the challenge-response protocol; that same browser UI can offer options like "keep me logged in".
- Both Firefox and Chrome have cross-system synchronization systems (e.g. Firefox Accounts/Sync), including to mobile browsers. Use those systems to sync the keypair across browsers controlled by the same user. Perhaps offer options to copy individual keypairs via QR code or similar, for the much smaller set of people who have systems of varying trust levels that should each have access to overlapping subsets of accounts.
- The browser can (at the user's option) provide an email address to a site. The site can (at the site's option) provide an option to register a new key for that email address, as the equivalent of a "lost my password" system but for "lost my computer or browser profile".
This implementation seems quite straightforward. About the only problem I know of that it doesn't solve involves throwaway accounts with memorized passwords used only with private browsing, where people don't want to leave a trace. If people care enough about that case, perhaps offer the option (such as when using private browsing) to compute a key from the origin, the user's email address, and an optional password, and throw it away at the end of the session. (For that matter, browsers could generate a completely transient key, for those times when you want to make a throwaway account that you'll never want access to again unless the site has an email-based recovery option.)
While this system provides some useful properties for highly technical users, it seems quite feasible to present it in an extremely simple manner for novice users.
https://www.ietf.org/proceedings/92/slides/slides-92-tokbind...
As far as usability, at least U2F is amazingly frictionless; enrollment is 'put the dongle in and hit the button', login is 'put the dongle in and hit the button.'
Can anything fill Persona's shoes?
It certainly sounds like people are considering alternative providers to login.persona.org if you wanted to keep using Persona/BrowserID, but I'm not sure how well received any of them might be without a good branding stance like Mozilla Persona mostly [1] had.
[1] Arguably it is a failed brand at this point with almost no consumer recognition, but still better than no brand.
I've wondered if a mistake with Persona was not trying to push it faster through W3C, WHATWG, OASIS or similar working group as a browser standard. It seems interesting to me that this was clearly a goal for the project (what with using navigator.id and everything) but it doesn't really look like there was much momentum to push this forward into any of the big "web apps standards tracks".
Particularly with the successes in things like Cordova and React Native/NativeScript helping to standardize "app features" like geolocation in browsers, things seem to be heating up in the web-based "apps" arena and maybe there is room there for pushing something like BrowserID as a useful "apps platform feature"...
[1] https://wiki.mozilla.org/Identity/Firefox_Accounts
[2] https://wiki.mozilla.org/Identity/Persona_Shutdown_Guideline...
Well good luck to the Persona team.