El antipatrón de pedir usuario y contraseña del correo desde otros servicios para buscar contactos

Si hay una práctica a erradicar en multitud de "sitios sociales" es la de pedir el usuario y contraseña del correo o de otros servicios para "invitar a tus amigos" o "darte más datos y funcionalidades". Se trata del antipatrón de diseño en programación web más extendido y popular en los últimos tiempos. No es que uno quiera sembrar miedo respecto a Tuenti, Facebook u otras redes solventes - a buen seguro que no van a almacenar contraseñas y darles un uso ilícito - pero sí dejar claro que si como usuarios aceptamos este tipo de mecanismos, estamos cogiendo muchas papeletas para sufrir phishing.

De entrada, las webs que lo implementan tienen buenas razones para hacerlo, si hay algo tedioso es replicar los contactos que uno tiene cada vez que quiere probar un nuevo servicio. Cierto que la gente normal - sólo los bloggers están todo el día registrándose en tonterías - no anda de una red social a otra continuamente, pero como servicio, cuantas menos barreras de entrada establezcas para ser utilizado, mejor. Y no sólo tenemos este caso de uso, empiezan a proliferar los clientes de todo tipo que también solicitan el usuario / contraseña para experiencias del tipo "escribe una vez y refresca el 'status' en una docena de sitios". La buena noticia es que comenzamos a tener estándares y tecnologías que van a permitir la erradicación de este antipatrón a poco que las diferentes webs no se empecinen en pedirle a los usuarios las llaves de casa. Sucintamente, hay varias alternativas:

• Los servicios de correo web más importantes ofrecen APIs. Tenemos la de Yahoo, la de Windows Live y la de Google. ¿qué permiten? Acceso a los datos del usuario pero bajo el proceso de identificación del sistema de correo, sin que la web que utilice estas APIs llegue a tener en ningún momento la contraseña.

• La anterior propuesta significa que la "web cliente" tendría que hacer el mismo trabajo tres veces (o más si contempla otros correos) para una misma funcionalidad. Esa es la razón de ser de los estándares y ahí es donde OAuth tiene sentido. Ya hemos comentado algunas cosas sobre este sistema de identificación abierta que define un mecanismo para que una aplicación web (cliente) pueda acceder a la información de un usuario en otra (proveedor) sin tener que informar a la primera del usuario y contraseña. Al final, los tres sistemas de correo que ofrecen API y que hemos comentado podría perfectamente adoptar OAuth en lugar de sus sistemas propietarios e incompatibles. Quién más está apostando por él es Google que lo utiliza para su Friend Connect.

• Tenemos la la API social de Google basada en XFN y FOAF, que permite acceder a los contactos de un usuarios que sean públicos en la red y siempre que la información esté expresada en el estándar adecuado.

• Hay un proyecto interesante, Portable Contacts, cuyo objetivo es la de añadir una capa de abstracción más sobre un conjunto de estándares (vCard, OpenSocial, OAuth) para hacer más fácil la implementación de la funcionalidad "tráete a tus contactos".

• Por último, está Facebook Connect del que tanto hemos hablado. En este caso la propuesta va más allá de la "portabilidad de datos" (que no lo es) para empezar a hablar de integración con la red social.

En definitiva, nunca ha sido buena idea dar nuestro usuario y contraseña del correo a nadie y el que sigamos viendo implementaciones de este antipatrón cada vez va a tener menos sentido. En absoluto creo que empresas como las arriba mencionadas - Tuenti o Facebook, en la captura pidiéndote usuario y contraseña, también muchas otras - vayan a almacenar nuestras contraseñas de otros servicios, pero perseverar en estos mecanismos ayuda a que los usuarios menos prudentes lo acaben viendo como normal ir dando las llaves de su casa en internet al primero que se lo pida con educación.