14 ms·
Persona is distributed. Today.
- teawithcarl 14y agoOutstanding work, Mozilla. Parallel to when they broke the I-E monopoly, Mozilla is truly impressive lately. Best way to support the new creativity surge by Mozilla - re-adopt Firefox as your MAIN browser. With each search worth $1 (approximately), every time you search using Firfox, Mozilla receives $1. (payment by Google, for using their search engine) Mozilla currently receives $300 million/year via search. Increasing search $ income ... rewards Mozilla as the most open platform and amongst the most innovative organizations on Earth.
- badida 14y agoThanks! Another good way to help Mozilla make the Web better for all is to implement Persona on web sites you build. It's easy and respects your users. Here's how you can do it in an hour or less: https://developer.mozilla.org/en-US/docs/persona https://developer.mozilla.org/en-US/docs/persona
- coldpie 14y agoStudying, understanding, and maybe implementing this looks like a fun weekend project. Thanks!
- namespace 14y agoEmail has been the identity backbone for a long time. Persona supports multiple emails. This makes maintaining multiple identities even easier. A great alternative to identity trackers.
- jjcm 14y agoGreat work Mozilla team, very eager to see this catch on in the coming years. Would be great if startups could get on board with it so the larger giants will be swayed to follow suit.
- themgt 14y agoI tried to boot the example app eyedee.me and it's unable to find this tarball from the package.json: https://github.com/benadida/node-client-sessions/tarball/92fff32 https://github.com/benadida/node-client-sessions/tarball/92f...
- pudquick 14y agoEdit the package.json to point "client-sessions" to: https://github.com/mozilla/node-client-sessions/tarball/92fff32 https://github.com/mozilla/node-client-sessions/tarball/92ff...
- badida 14y agoSorry, that's my bad. It's fixed now if you pull the latest eyedee.me.
- themgt 14y agoThanks! I ran into one other issue (PR: https://github.com/mozilla/eyedee.me/pull/27 https://github.com/mozilla/eyedee.me/pull/27) but was otherwise able to get it booted in our Heroku-esque environment: http://eyedee-me.a.pogoapp.com/ http://eyedee-me.a.pogoapp.com/
- rattray 14y agoCan anybody explain exactly what is meant by "distributed" here?
- dazmax 14y agoNot locked to a central service provider.
- mehrzad 14y agoPretty sure it means: It doesn't have to go through Mozilla's servers; anyone can set up their own instance and work with the other ones.
- monkeynotes 14y agoNo single authority is needed to vouch for a given identity, instead numerous authorities can validate an identity. That's my understanding. Distributed identity seems to be notoriously tricky to fully understand for both end-users and developers. I still don't really get OpenID.
- enaeseth 14y agoOnline login services are generally many-to-one. For example, many sites accept Facebook login, but for a user to log in that way, there is only one identity provider they can use: Facebook. If you don't have a Facebook account, or don't want the site in question to have any access to it, you can't use Facebook login. When the article says "distributed", it means Persona is many-to-many. Any domain can implement the protocol, so when a site accepts Persona login, you can choose from many identity providers – including your own, if you're industrious and want to set one up for your domain. Most people are using Mozilla's service today, but the idea is that email providers like gmail will implement it themselves in the future.
- pindi 14y agoIt's used in the sense of "decentralized": no one company controls the Persona system as a whole. Authentication is performed against the domain of the email address the user gives, falling back to authenticating with Mozilla's central server if and only if the domain doesn't support Persona yet.
- tiziano88 14y agovery cool, looking forward to a more widespread adoption!
- eliasmacpherson 14y agohttp://www.getpersonas.com/en-US/ http://www.getpersonas.com/en-US/ I have been confused by the distinction between these two for the longest time, and I'm hardly alone. Any plans to rename one or the other?
- mcpherrinm 14y agoThe plan was to deprecate personas as a name for background themes. https://addons.mozilla.org/en-US/firefox/themes/ https://addons.mozilla.org/en-US/firefox/themes/ doesn't use the word "persona" anywhere I can see any more. I don't know why getpersonas.com hasn't been axe-murdered yet. (Edit: info on migration is here, https://blog.mozilla.org/addons/2013/02/28/getpersonas-com-migration-update/ https://blog.mozilla.org/addons/2013/02/28/getpersonas-com-m... and is ongoing)
- JoshTriplett 14y agohttps://blog.mozilla.org/addons/2012/03/01/personas-are-joining-the-themes-family/ https://blog.mozilla.org/addons/2012/03/01/personas-are-join...
- callahad 14y agoThe themes have been renamed to themes... getpersonas.com is legacy domain that's been unfortunately sticky. It should be resolved in a few weeks: https://blog.mozilla.org/addons/2013/02/28/getpersonas-com-migration-update/ https://blog.mozilla.org/addons/2013/02/28/getpersonas-com-m...
- mburns 14y agohttps://blog.mozilla.org/addons/2012/03/01/personas-are-joining-the-themes-family/ https://blog.mozilla.org/addons/2012/03/01/personas-are-join... Personas are now just called Themes (background themes, specifically).
- deleted 14y ago[deleted]
- csense 14y agoHow is this different from OpenID? EDIT: Seriously, this question was downvoted within two minutes? Why? EDIT again: The best I've been able to come up with by reading the comments and docs is that they attempt to solve the same problem, but OpenID is based on the backend of the website you're logging into issuing a request to the auth server over HTTP, while Persona has the auth server issue a very-short-duration cert for a public key generated by the client.
- deleted 14y ago[deleted]
- wmf 14y agoFirefox supports Persona and they're not going to support OpenID.
- vitno 14y agoCan you elaborate on that? OpenID was designed to be browser-independent. Persona is essentially a distributed openID with some extra browser integration. Sure Mozilla doesn't support openID, but I'm unsure what you would want them to do...
- wmf 14y agoWithout browser support, you have to type your ID into every site. (I'm ignoring Nascar login because that's not distributed.) With browser support you just click to login and maybe click again to confirm.
- cpeterso 14y agoHere is a Firefox add-ons to add the missing "browser support": https://addons.mozilla.org/en-US/firefox/addon/openid-for-firefox https://addons.mozilla.org/en-US/firefox/addon/openid-for-fi... (I have not actually tested this add-on myself.)
- badida 14y ago
- JoshTriplett 14y agoCurrently wondering the most sensible approach to make a single-user website support this protocol, so that I can make my email address (the only valid email address at my domain) support Persona natively. I don't really want to have to set up a username/password system with a single user. I'd almost prefer to manually hand my identity's private key to each browser I want to use. I wonder how much work it would take to write a Firefox extension that does this and uses Sync to snychronize the key between browsers?
- hosay123 14y agoIt seems all required is publishing a `/.well-known` URL that delegates to another provider, although it's not obvious if such a provider exists yet. Pretty cool it's this straightforward, though.
- JoshTriplett 14y agoI don't want to delegate to another provider, though; I'd like to take advantage of the decentralized approach, and authenticate my own email address.
- tadfisher 14y agoWhat is your preferred server environment? This would be a fun project to whip up quickly.
- JoshTriplett 14y agoStatic files. :) Hence the idea of just pre-generating the key pair and sharing the key with my browsers via Firefox Sync. The provisioning and signin pages could point to static pages that just say "If you're seeing this, you're trying to authenticate as me and you aren't me; go away."
- tadfisher 14y agoOK, so I can see this working with a browser extension. Throw a pregenerated cert into localStorage and sync across browsers. Where I'm still fuzzy is if the site performs local verification, or login.persona.org does it, it might contact your server to grab its pubkey over SSL, requiring you to host something on your email domain.
- cromwellian 14y agoI haven't look at the specs deeply, but it would be nice to have a system that did not need any kind of server at all, but the browser itself could be the Persona identity provider. The actual local data needed to pull it off could be replicated (encrypted) to cloud storage so it would work across all your devices and browsers, but the actual profile data itself would never be readable by the servers. I started looking at the feasibility of building something like Persona into a 'serverless' social network a while ago using Broadcast Encryption techniques to define social sharing groups with revocation (de-friending) and Identity Based Encryption, but it seems like the state of the art IBE always requires a trusted server somewhere. But someone with more expertise in cryptography than me can maybe make it work. My original essay that prompted it (http://timepedia.blogspot.com/2008/05/decentralizing-web.html http://timepedia.blogspot.com/2008/05/decentralizing-web.htm...) based on the sad state of affairs these days where everything is non-federated.
- deleted 14y ago[deleted]
- jackbravo 14y agothere is webid: http://webid.info/ http://webid.info/ which is like ssh keys for the web.
- graue 14y agoIsn't this the ultimate goal of Persona - native browser support?
- mook 14y agoThat would end up requiring your identity to be a key of some sort, though, since ultimately the thing you're logging into needs to check _something_. Email-like things are useful because somebody has to control the domain; if you don't have that, it's harder to establish something. Of course, you can say things like "Hi, I'm random prime number 534473", but that's much less memorable...
- drdaeman 14y ago
- Ixiaus 14y agoI'm building this into the authentication scheme for my company's new application. It's remarkably easy to get started with. The team did a great job of making it solid and simple.
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- martinced 14y agoIt sounds great both for users and for devs which, I'm sure, is going to help it take off. However I've got one question: was this conceived from the start with security in mind and is it simple enough as to not be plagued with the countless security issues which product that are too complex inevitably run into? I'm thinking, for example, of the various recent OAuth SNAFUs.
- callahad 14y ago> was this conceived from the start with security in mind Absolutely. Point 4 in the Mozilla Manifesto: "Individuals' security on the Internet is fundamental and cannot be treated as optional." (http://www.mozilla.org/about/manifesto.en.html#principles http://www.mozilla.org/about/manifesto.en.html#principles) > is it simple enough as to not be plagued with the countless security issues which product that are too complex inevitably run into? We hope so. Persona's design and implementation have gone through several internal and external audits, and thus far it appears sound. Keeping everything as simple as possible is a core goal.
- stcredzero 14y agoOne nitpick about the current implementation: It was hard for me to know if I already had a Persona ID. I'm still not sure. I ended up "resetting" my Persona password to log into Trovebox. I have no idea if this actually created my Persona ID by doing so, or if I had one before. A developer like me might realize that this is idempotent and just go ahead, but your ordinary joe user might be put off.
- yjyft846jh 14y agoI don't understand how this is an advantage over just using email address as username with a password, like many sites do already. Can someone please explain the benefit? [Edit: message to user Anonymous09, who replied to me below - you appear to have been hellbanned since the past three weeks. Thought you ought to know.]
- whatshisface 14y agoIf I knew your email, I could make an account on a website in your name without you knowing.
- yjyft846jh 14y agoI don't see how that would cause a problem. If the website ever sent an email to me, I would know about it and just be able to do password recovery and delete the account. If the website never sends an email, it's of no inconvenience to me. In that case is this not just functionally equivalent to sending a validation email upon account creation, as many sites do already?
- gcr 14y agoWhy? If you know his email, then the website's confirmation link will still go to his inbox. If you know his email and password, then Persona wouldn't help anyway.
- Anonymous09 14y agoFrom what I understand, the idea is that you sign in with any Persona provider. For example, let's say gmail, hotmail, yahoo, ycombinator, microsoft, all have user e-mail addresses and they set themselves up as a provider (anyone can do this). This means, I go and create ABCforum.com and it has a login with Persona button. My users can now login using their gmail, hotmail, yahoo, ycombinator, microsoft, etc e-mail addresses. So the difference. 1 (Without Persona). You create an account on ABCforum.com with my-name@gmail.com as your username, and make up a random password. This is another account you always have to remember, and the password can be viewed by the developer behind ABCforum.com since it's stored in their database (which could also be hacked in the future). You get a verification e-mail sent to you, so ABCforum.com can confirm you own that e-mail. 2 (With Persona). You click login with Persona, and enter your gmail e-mail and password, which Google verifies belongs to you. There's no creating an account. The provider (in this case Google Gmail) is confirming your e-mail and password, and not the site you're signing into (ABCforum.com).
- lubujackson 14y agoI still have a funny feeling about the robustness of Persona. For instance - let's say one of my emails gets hacked, my crappy Yahoo email. Does that give them access to my other Persona accounts? Would I (or anyone else) be able to know if the account is compromised? Normally you change your password and that's the end of it, but I'm not sure what happens with Persona. What if my kid brother uses my computer - wouldn't he have access to any site that allows Persona logins? How do you lock it down?
- StavrosK 14y ago> Does that give them access to my other Persona accounts? No, it gives them access to whatever site you registered with your Yahoo! account. (EDIT: If you use the temporary bridge they implement, they could get access to your other accounts if they got access to the bridge. This won't happen if your email provider supports Persona natively). > Would I (or anyone else) be able to know if the account is compromised? Yahoo! probably would, and could tell you. > Normally you change your password and that's the end of it, but I'm not sure what happens with Persona. You change your password and that's the end of it. > What if my kid brother uses my computer - wouldn't he have access to any site that allows Persona logins? How do you lock it down? Just log out of your email provider. Really, Persona is just a way to make your email provider your authenticator. It's "Facebook Connect" for your email provider. Security-wise, if your email gets hacked, what happens is what would happen anyway, since almost every site can request a password reset by emailing you. The attacker has access to that anyway. Persona removes the hassle of remembering one password per account by letting the site ask your email provider if they know you.
- lubujackson 14y agoAh, thanks for those answers.
- StavrosK 14y agoYou are very welcome!
- 14y ago
- inopinatus 14y agoI've just read through the Persona protocol specification document at https://github.com/mozilla/id-specs/blob/prod/browserid/index.md https://github.com/mozilla/id-specs/blob/prod/browserid/inde... and was quite disappointed to find RFC5785 in use, in which HTTP is abused as an infrastructure discovery protocol. This gives a lie to the identity being an "email address". It isn't. Ok, it's structured as a LHS@RHS form but the domain in the RHS isn't an email domain, it's an overloaded website with some problematic assumptions ladled in. This creates a significant barrier to adoption. Many entities just won't bother: not only does it ask an apex A record to serve actual content (usually a mistake) but it requires the primary web host of a registerable domain, usually a trademark or brand identity, to carry technical material, definitely a clash of concerns. (Why? In many companies of reasonable size, the website is managed by a completely different group of people - often a marketing team - to the internal identity service. Then, even if one team convinces to the other to install the browserid file, there is a possibility of it being deleted it by mistake during the next site refresh.) I had hoped to find an intermediate step where a DNS SRV lookup was used to first locate the host delivering the browserid file. This follows the federated structure of email rather more closely and allows the identity service to be independent of the corporate brochureware. Even better - if the SRV lookup could be signed with DNSSEC, the transfer itself can be protected with DANE. The whole thing becomes manageable as a simple, separate unit of technology. It is thus rather more likely to gain the support of system administrators.
- wmf 14y agoCan JavaScript look up a SRV record?
- IgorPartola 14y agoOnly with the help of a server.
- inopinatus 14y agoJavascript can (ISTR there is a pure JS DNS library for node) but perhaps not in the browser without specific browser support. You can say the same about trustworthy crypto, incidentally. SRV is definitely the ideal record. In this case I can see why a pure HTTP approach was chosen (it avoids browser dependancies) and it irks me that developers of web-based tools tend to develop inside the HTTP bubble rather than using the broad and highly capable infrastructure of the Internet, because this kind of constraining outcome is the result. SRV would be an excellent choice for HTTP/2.0 as well, rescuing us all from apex quasi-CNAME hacks and the like. However in my initial remark you can substitute in the use of "a well-known subdomain"[1] for "SRV record" and still achieve a better separation of concerns than simply using the RHS of the identity string. [1] c.f. DKIM's slightly hackish but effective use of an intermediate underscore to denote infrastructure DNS entries. Won't work for A records though IIRC.
- snowwrestler 14y ago> Of course, in the long term, Persona is meant to be distributed: alice@example.com should be verified and certified by the administrators of example.com. If example.com wants to use 2-digit passwords, they can. If they want to use retinal scans powered by your webcam, they can. It’s up to them. With each domain able to customize its authentication protocol with its users, the Web becomes more secure. How would a 2-digit password make the web more secure? Let's say I allow users to authenticate into my website with Persona, and I accept alice@example.com--whose 2 digit password is brute-forced the next day. Now whoever got into Alice's account has elevated permissions in my web app too. Great. If I had just stuck with my own authentication scheme at least I could have enforced some minimum complexity.
- marcioaguiar 14y agoHe was just making a point that authentication protocol is a domain choice (from 2-digit passwords to retinal scan). It's up to the users to trust the domain he is going to use as identity. Just like many people trust Facebook Connect.
- DannyBee 14y agoBut facebook at least has standards (or is believed to, i have no knowledge). Why should, for example, google, ever trust, say, fred's discount web hosting, enough to let them login to gmail? Not in the sense of "these guys could compromise gmail" (which is a worry in certain elevated privileges contexts), but more in the sense that "people are still going to say 'my gmail got hacked'" if their gmail gets hacked because they made bad choices. They do now! Google will still get blamed, and their only real option is to decide not to accept certain identity providers (IE blacklist or whitelist). Long term, how are we not going to end up with just a mishmash of who accepts what? I've read a bunch of docs on persona, and it doesn't seem to address this past stating how wonderful user choice is, and how making this more distributed will make the web more secure (which seems, well, wrong)
- shardling 14y agoFor most people, they already use an email account to authenticate. Pretty much every single login I have, someone with access to my primary email account could co-opt with the snap of their fingers. If your email provider is vulnerable, you're already fucked, except for those accounts which use two-factor auth. And persona isn't intended for your bank/etc.
- epa 14y agoIt's hard not to respect Mozilla in 2013. I know i've personally moved away from Chrome back to FireFox. Mozilla seems like a young Google in a way.
- dombili 14y agoAgreed. I feel like Firefox has become the old Chrome (fast, reliable) and Chrome has become the old Firefox (slow, unreliable, ugly[1]) lately. [1] Chrome still looks quite decent as of right now but the new UI changes on its beta build makes no sense at all and looks flat out ugly (http://googlesystem.blogspot.com/2013/03/chromes-integration-with-google-search.html http://googlesystem.blogspot.com/2013/03/chromes-integration...).
- MatthewPhillips 14y agoSame here, switched to Aurora permanently and haven't had any issues. Like that it looks native to the OS you are using. And had forgotten how much better the awesomebar is.
- epa 14y agoThanks for sharing, did not realize ver20 was in testing.
- zobzu 14y agoNote: both 2 digits passwords and webcam based retina scans are terribly weak. Always upsets me when sarcasm like this is used, and the author is horribly wrong;-)
- e12e 14y agoPersona is nice, because it is simple. It is still important to note that it is an alternative mostly to: "Trust that a user being able to read an email address is proof authenticating said user" -- in other words sites using it have no expectation that the user need any form of authentication before being issued a persona (Similar to eg: shared mail accounts -- where having access to the email does not identify you as a single person/user -- rather as a group of users -- which is subtly different). Additionally without any form of single sign out/invalidation of private keys/session certificates other than expiration (please correct me if I've missed something wrt sign-out/invalidation) -- persona is in some ways less secure than "trust the mailbox": Even if you change your password/secret key -- any (stolen) signed session certificate (aka token/ticket in most other systems) will remain valid as far as the authorizing site is concerned. This is similar to a stolen cookie -- except the site cannot decide how long the certificate is valid -- the identity provider does. So if somedomain.net signs certificates valid for a year, the only thing you can do as a site allowing persona logins, is mark said domain as "not trustworthy enough" -- and disallow logins. This is "fine" as long as Persona isn't used for anything "serious" -- however with social engineering attacks, anything that to the end users appears to be proof of identity can be used to escalate privileges ("He sent me a hipsterchat-message on kewlchat.net -- so I reset the RDP-password like he requested"). I do think moving identity management "closer" to the user is good -- let the ISP, the various organizations the user is identified with vet and administer the user database -- but for the general use case -- we also need some form of trust between the sites, and the iDPs. Shibboleth[1] is one approach to this -- but it is more complicated that Persona, and has more overhead. Personally I'd like to see a solution based around x509 certs and organizations like https://cacert.org https://cacert.org -- but for that to work we need browsers to get better at handling cerificates. That is -- we need a user friendly way to manage identities based around x509 -- and we need browsers and servers to expect to validate both server and client certificates. Unfortunately such validation will entail a lot of problems with expired certs etc... it's not a trivial problem to solve in practice. [1] http://shibboleth.net/ http://shibboleth.net/
- daemon13 14y agoFYI, latest stable Firefox says this: You have asked Firefox to connect securely to cacert.org, but we can't confirm that your connection is secure. Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
- jcroll 14y agoMozilla building stuff you don't need today
- jchrisa 14y agoI hacked together a PhoneGap plugin so you can easily use Persona to log into your mobile apps https://github.com/couchbaselabs/cordova-browserid https://github.com/couchbaselabs/cordova-browserid I think this is an easier protocol for devs than OpenId or Facebook Connect.
- frabcus 14y agoHow is this different from WebFinger? And a more detailed question - what is Mozilla's political strategy for getting adoption? I hope they succeed!
- supervillain 14y agoIs Persona reviving the old Microsoft Passport? Microsoft first implemented this in early 2000s, I remember Microsoft Passport marketing the single sign-on feature, it did not catch up. http://www.nytimes.com/2001/09/20/technology/20SOFT.html http://www.nytimes.com/2001/09/20/technology/20SOFT.html
- AndrewDucker 14y agoExcept that Passport meant using a single authority (Microsoft), whereas Persona is entirely federated (once individual domains opt-in).
- ekurutepe 14y agoAm I the only one to read this as 'Persona is disturbed'?
- oscargrouch 14y agoWeb technology (http and relatives) was not meant to do this. Can do it? of course, but will do it badly.. Its time to wake up, and see that we need new kinds of technology to keep up evolving Its like glue wings in a old car and say that it is a plain and can fly.. The idea is good, and we need it badly, but the technology infrastructure its based on is weak for this scenario