About Mozilla Persona

Or why " Mozilla Persona do not solve OpenId Problems"
By chance I'm working on authentication stuff these days. A SCrypt Hasher for django and some Spring Security SSO integrations.
I'm also watching pycon videos and I came across "Beyond Passwords: Secure Authentication with Mozilla Persona" by Dan Callahan.
The presentation is actually very good but to me, an SSO and OpenId enthusiast, clearly reflects missing points of the Persona initiative.

1. Persona has better UX than OpenId (process is simpler and clearer )
2. Easy to implement 

But

1. Using email as credential is a BAD BAD idea: What if I subscribe a service  ( let's say "Mozilla developer center" )  with my professional email and I got suddenly fired by my employer upon unfair conversation at PyCon. I lost control on my profile on that site. OpenId has an elegant solution for that. The meta-tags.
2. It still lacks of personal data exchange: Dan Callahan says that they are working on that, waiting for developer feedback... and shows how, upon first time usage on a site you have "just to fill your name, surname , gender... super boring. This is why the whole "social signin" came out. The problem here is that "Identity services" never took off.
3. OpenId is easy to integrate too... if you have a library for your language / framework of choice ( Rails, Django, Flask, Spring have it) 
4. It is not as distributed as is meant to be: you still need mozilla for js ( why is explained in the video) for the "proxy thing" (mozilla) for email providers that do not support persona. I didn't get how signed credential renewal works ( since it is said that there is an expiration) but with only one persona per site ( different personas are different accounts right?) who does it mitigate third party services outrages ( or shutdowns :-)  )
5. It is actually a lock in: with your email provider and... mozilla in a way.
6. No email provider will ever support it: Google, Microsoft, Facebook ( yes now Facebook is  also an email provider) are active in the Identity management business and will not probably favor an initiative from a competitor in the browser market.
7. [Almost]No browser (except Firefox) will ever support it: see point n.6

The main fact here is that Persona do not solve any of the OpenId problem except better UX ( well... it wasn't a big deal) but still I think my Mom, my average Gym friend etc.. wouldn't understand what Persona is, how it works. They know Facebook and Twitter.. that's the internet for them ( yeah sad thing indeed) and I would not trade this better UX with the actual OpenId  ecosystem. Up to now it is just another sign in button among the others. Anyway good luck Persona!

About selecting CFP ( from a conference geek)

Me in the backstage of djangoday 2012

I had the joy of organizing a couple of conf with my fellows of WebDeBs. After been an attendee in many conferences and a speaker at some of them it has been a very nice and playful experience be in the staff.


This Year I submitted a CFP for the DjangoCon.eu. They had a fancy and democratic way of selecting CFPs:

• Anonymise submissions, to eliminate bias. 
• The first round of voting is yours: we invite Django community to rate anonymised topics on a scientific 3-point scale (“meh”, “yay”, “MUST HAVE”). 
• De-anonymise for the final selection. 

This sounds good. But there is a problem. I know my own submission and have a plenty of friends with a Github account that can pump my paper even if they are not interested in the conf. Although I appreciate the effort of the DjangoCon.eu having a public voting stage in the CFP selection process lead to a bridle situation. In our confs we have a board of staff members selecting the papers. I think that the aim in  public voting is to have the most wanted talks. And this is great. On the other hand it is not granted due to the fact that "friendly" voting could bias the result. This bias, maybe, have little impact in conf that relies on big communities , which is the Django case. I think The very best process would be a closed voting with the early bid ticket buyers and a second round in which are involved staff members and community leaders or experts. This to empower people that is really coming to the conf on topics that matters.

Another point is about how to deal with submitters. Submitting a CFP involve some work and a bit of courage or pride. Even if a talk proposal is discarded the author should be handled kindly, at least, for the interest and the effort in submitting it. Playing dead and then publish the agenda with the "winners" is poor communication and community management.
It happened to me today. I have submitted a talk for FOSDEM 2013 on 17/12/2012.

One pythonic client to bind them all
Description: Unleash the power of python Metaprogramming with some building tricks to maintain a flexible client for third party API (especially web, restful ones). This won't put an end to functional dependency madness, but it will bring some technical sanity.

Today, looking at planet python I discovered that the agenda for the python track was published. It's not a ego problem. The selected talk are "super good" but an email with a simple email to inform a discarded submitter before publishing the agenda would have shown a better understanding about the fact that no one likes to be rejected.

These are my two cents.