XAuth frente a Facebook Connect

Facebook digg

Ayer se presentó XAtuth, una tecnología que algunos han calificado como la baza de la «web abierta» frente a Facebook Connect (R/W, Genbeta) en la lucha por la identidad online del usuario. En realidad lo que XAuth permite es que cualquier web pueda consultar qué «servicios sociales» utiliza el usuario que la está visitando. Así, si en Error500 implementara el Javascript para integrar XAuth, podría detectar de forma automática qué servicios de los que soporta XAuth utiliza cada visitante, algo que ahora no es posible puesto que, por seguridad, el navegador no permite acceso de mi web a cookies de otros.

¿Para qué puede servir esto? Básicamente para poder decidir en tiempo real qué botones para compartir se ofrecen a cada visitante: si es usuario de Twitter, Buzz y Menéame, mejor ofrecerles estos que la ristra de 30 servicios que cada vez es más típica en muchas webs y que, en la mayoría de los casos, sólo aporta ruido visual. ¿Es esto un movimiento frente a Facebook Connect? Yo no diría tanto, XAuth no aporta para nada lo que aporta Facebook Connect: identidad online, los contactos del usuario y acceso a su «newsfeed». ¿Aporta valor? Al margen de que como está implementado ofrezca algunas dudas (consultas a un único punto centralizado, a priori no hay comprobación de que lo que responde el servicio es cierto, de hecho lo que les conviene es responder siempre «sí, es mi usuario»), lo cierto es que beneficia a los servicios con más usuarios. Si una web pregunta a XAuth si el usuario tiene cuenta en Google y si tiene cuenta en «nuevo-servicio-social-que-se-acaba-de-lanzar», la respuesta será casi siempre que lo primero es cierto… y lo segundo no, por lo que mostrará el botón de Google y no el del nuevo. ¿Y después de pintar los botones para compartir, qué? Pues queda OAuth, estándar de identificación del que ya hemos hablado por aquí.

Por cierto, como era de esperar, Facebook no forma parte de XAuth, en el que sí están Google, Microsoft, Meebo (impulsores del mismo), y Disqus

Cuando hay problemas en un estándar abierto en la web

OauthProblema de seguridad en el estándar OAutth, del que hemos hablado mucho – y bien – por aquí. El resultado es que muchos servicios no están atendiendo las peticiones mediantes APIs que utilicen OAuth, como es el caso de Yahoo o Twitter. El resultado es que el resto de webs que se integran con estos servicios han tenido que dejar de funcionar o han tenido que optar por soluciones alternativas a este estándar de identificación abierta, la mayoría basadas en el antipatrón de pedir usuario y contraseña.

Al final tenemos que un estándar web relacionado con la identificación es un elemento crítico y que cuando sucede con uno algo extendido, el impacto es muy alto. Ser abierto aquí sólo implica que el número de afectados es mayor al ser más fácil su adopción, no hay nada que nos asegure que no vaya a haber problemas en otros como el sistema de Facebook. En todo caso, el ecosistema de aplicaciones cliente y proveedores mediante APIs muestra otro flanco en el que es frágil, y no es el único.

Twitter y su sistema de identididad digital basado en oAuth

Identificación con Twitter

Movimiento interesante y necesario de Twitter, articular un sistema de identidad digital que permite a sitios de terceros identificar a los usuarios con la cuenta Twitter pero sin acceder a la contraseña de los mismos. Esto es posible gracias al uso del estándar OAuth, que va camino de convertirse por fin en la referencia como estándar abierto 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. Más información sobre el movimiento en R/W, Hueniverse. Un ejemplo de implementación lo tenemos en FileSocial.

Y, claro, esto nos lleva a volver sobre el tema de la la lucha por la identidad online del usuario, una batalla en la que sin duda el producto de referencia – nos guste más o menos – es Facebook Connect, pero también tenemos OpenId y Google Friend Connect. Hay varios puntos a considerar creo en este movimiento:

  • Twitter necesitaba un sistema de identificación para terceros que no exigiese la entrega del usuario y contraseña a los mismos, todo un problema de seguridad que van a a arreglar con el empleo de OAuth. De entrada se trata de salvaguardar el ecosistema, sin duda uno de los activos más importante para Twitter, en este sentido considero que el movimiento era imprescindible para Twitter.
  • Al contrario que OpenId o Google Friend Connect, integrar el sistema de identificación digital de Twitter tiene una ventaja para los sitios que lo elijan: pueden ganar visibilidad y tráfico gracias a la integración. Ese es el principal activo de Facebook Connect: si lo integro en mi web, las actividades de los usuarios aparecerán en su newsfeed, trayéndome tráfico.
  • La apuesta por un estándar abierto indica a las claras la vocación «amigable para desarrolladores» por parte de la gente de Twitter, en contraposición a la visión de Facebook que apuesta por un API propietaria en lugar de por un estándar abierto.

En todo caso, a día de hoy Facebook sigue haciendo valer su masa de usuarios como gran valedora de su propuesta de sistema de identificación online. A día de hoy todo esto puede parecer una competencia de retorno incierto para los proveedores de identidad, pero creo que es un tema nuclear: centralizar las acciones online de los usuarios tiene un valor potencial incalculable, como también lo tiene estar integrado en servicios de terceros. Hoy te ofrecen un servicio de identificación, mañana un servicio de publicidad personalizada.

Sitio oficial: Sign-in-with-Twitter.

Snowl, Aurora, OAuth, OpenId y el futuro del navegador web

Aurora

El futuro del navegador web es el tema «estrella» de la semana merced a Aurora y Snowl, dos proyectos de la fundación Mozilla. El primero lo encontramos en la factoría de ideas de Mozilla Labs, abierta a propuestas externas para reflexionar alrededor de la nueva generación de navegadores. Desde Adaptative Path presentan Aurora, apenas un boceto, siquiera una «prueba de concepto» de lo que podría ser el navegador del futuro.

Aurora muestra un cambio radical en la experiencia de usuario del navegador web, que podría definir en tres variables: aplicaciones ricas en internet (las RIA), una experiencia social y utilización de la localización del usuario. Sin duda un planteamiento impecable, por mucho que se aleje de una propuesta asumible hoy en día, ¿qué tecnologías vamos a utilizar para las RIA? ¿quien albergará mis contactos? ¿bajo qué estándares se comunicara este futuro navegador con las distintas aplicaciones? ¿y ellas entre sí? ¿cómo y dónde se gestionará la privacidad de mi localización? Son todos temas que hemos ido comentando a lo largo de los últimos dos años y que reflejan en cierto modo hacia donde se encamina nuestra experiencia de la web.

¿Cuál sería el planteamiento ideal? Personalmente apostaría por un runtime para aplicaciones ricas en internet que sea abierto, estándares OpenId u Oauth integrados en el navegador para identificarnos en la web y acceder a los datos que tengamos en nuestras aplicaciones, sitios sociales interoperables con portabilidad de datos real y un navegador que ofrezca una buena experiencia sin perder su rol neutral y basado en estándares abiertos, como debe ser la web.

Por otro lado, esta semana ha visto la luz Snowl, una extensión que apuesta por convertir Firefox en el centro de las comunicaciones en la red con un rol que va más allá del de navegador web. La extensión que podemos instalar es apenas un prototipo, pero muestra el concepto que persigue implementar:unificar la recepción de todo tipo de mensajes, desde correos electrónicos o canales RSS hasta mensajes en twitter o respuestas en foros. Ofrece dos vistas de uso, una más parecida a un gestor de correo y otra similar a un lector RSS en versión «river of news».

De momento Snowl es algo a lo que echar un vistazo y poco más. A serios problemas de implementación hay que unir que conceptualmente es bastante discutible, los sitios tipo Twitter admiten una experiencia interactiva muy diferente que la lectura RSS y construir un interfaz capaz de distinguir la importancia de cada mensaje y se adapte al tratamiento que se puede dar a cada uno… complicado.

En todo caso, uniendo Aurora y Snowl tenemos un escenario interesante por parte de la fundación Mozilla. Una apuesta por la innovación abierta para el futuro del navegador web (justo hoy alianzo publica algunos casos de éxito de esta filosofía), algo muy necesario tras los años oscuros en los que Explorer reinó en solitario y que va a traer esta segunda guerra de los navegadores.

Os dejo con el primer vídeo de Aurora, el resto se puede ver en adaptivepath.

OAuth adoptado por Google

OauthHabíamos hablado por aquí del estándar OAuth. De forma resumida podemos decir que OAuth 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. Hasta ahora, aún siendo el estándar de iure perfecto para los mashups, no era el estándar de facto puesto que cada compañía estaba apostando por una solución propia (Google AuthSub, Yahoo BBAuth, Windows Live DelAuth, AOL OpenAuth y la de la API de Facebook). La noticia de que Google soportará OAuth en sus APIs cambia las cosas.

GMail¿Para que nos sirve esto a los usuarios? Digamos que OAuth viene a arreglar el problema de que otros servicios nos pidan el usuario y contraseña del correo. Algo que por muy habitual que sea, en realidad es una locura ofrecerles, y para lo que este estándar ofrece una alternativa segura: terceros pueden permitirnos identificarnos en las cuentas de Google y traernos datos de sus servicios (GMail, Calendar, youtube…) sin saber en ningún momento nuestra contraseña. En este sentido, aquí si que hablamos de verdadera portabilidad de datos de los usuarios que tienen el control de a qué datos permiten el acceso y desde donde. Claro que esto podía hacerse ya con los estándares propios de cada servicio que hemos indicado arriba, pero el tener uno como OAuth ayuda a que una vez programada una solución desde nuestro servicio cliente, se puede utilizar para cualquier proveedor. Siguiendo con el ejemplo, si Yahoo adoptase OAuth, los terceros que ya se integran con las cuentas de Google podrían hacerlo con Yahoo sin trabajo adicional.

Ojo porque también google empuja así hacia el uso de sus cuentas desde servicios de terceros, como en el ejemplo de Zoho y como empuja desde Google App Engine. En todo caso, en la adopción de estándares abiertos, Google sigue sacando nota.

También lo comenta Webmaster Libre.

MySpace, oauth y la no «portabilidad» de datos

Twitter Myspace

Mucho se está hablando del anuncio por parte de MySpace de unirse a dataportability y su acuerdo con Yahoo, eBay y Twitter en la primera acción concreta en ese sentido, que han llamado «Data Availability». Esta «Data Availability» no significa realmente que el usuario pueda coger sus datos y el contenido generado y llevárselo a otro servicio de forma sencilla, sino que los perfiles públicos, fotos, vídeos y redes de contactos en MySpace estarán disponibles en el resto de servicios que han firmado el acuerdo. Así, como se muestra en la imagen, desde Twitter se podría acceder a la cuenta MySpace y automáticamente incoporporar blogs y demás información que allí tengamos. La primicia la dieron en TechCrunch.

El protocolo por el que desde Twitter, Yahoo y eBay podremos acceder a los datos de nuestro usuario en MySpace es Oauth, del que hemos hablado mucho por aquí y que permite hacerlo sin dar nunca nuestra contraseña en MySpace al sitio desde donde queramos acceder a los datos. Esto, aseguran desde MySpace (Ben Metcalfe) es sólo el comienzo y no se plantea como algo sólo para Twitter, Yahoo y eBay, sino abierto a cualquiera en el futuro.

¿De que va esto realmente?

Pues de momento no va realmente de «portabilidad de datos» , de hecho desde la organización de dataportability se responde indicando que «la iniciativa de MySpace evolucione hacia una implementación más acorde con las mejores prácticas de DataPortability». Lo que se está planteando sobre la mesa es que MySpace sea el sitio que almacene los datos del usuario para toda la web. No se trata – al menos como está planteado ahora – de que poder llevárselos a otro sitio a modo de exportación, sino de que MySpace juegue el rol de identificador del usuario en la web y de contenedor de su red de contactos para cualquier otro servicio. Su propuesta es que, si almacenamos nuestros datos con MySpace, estarán disponibles en un montón de sitios más que se van a integrar con ellos.

Algunos análisis de la «jugada» en ZdNet, universos paralelos. Nota de prensa en alleyinsider.

Yahoo Fire Eagle, plataforma para la geolocalización del usuario

portada de Fire Eagle

Aunque sigo esperando la invitación, no quería dejar de comentar Yahoo Fire Eagle, propuesta de plataforma para la geolocalización del usuario, de momento en beta cerrada. La idea de Yahoo Fire Eagle no es la de un producto para el usuario final, sino la de un sistema que permite a otros servicios externalizar la tarea de geoposicionar al usuario y acceder a esos datos a través de un API. Se trata de un nuevo paso hacia el siempre localizados con un enfoque interesante, el de permitir centrarse en las funcionalidades extras, dejando la tarea de la localización a Yahoo.

¿Cómo funcionaría entonces esto? En principio Yahoo Fire Eagle permitiría localización activa (envío un SMS con donde estoy, relleno un formulario en una aplicación cliente) y localización pasiva (instalo una aplicación que toma datos del GPS del móvil y le permito enviar datos, también sería posible utilizar triangulación GSM como hace la nueva versión de Google Maps). En ese segundo caso, se envía un correo al usuario periódicamente para indicarle que está siendo localizado y en todo momento tiene la opción de borrar toda la información de Yahoo Fire Eagle. Cómo abordar la localización pasiva y hacerla compatible con el derecho (y la sensación) de privacidad va a ser una de las asignaturas más importantes para los servicios basados en la posición del usuario.

El siguiente paso sería autorizar a otras aplicaciones y servicios para acceder a estos datos. Por ejemplo, el usuario podría permitir a Flickr tenerlos para añadir la posición geográfica en la que fue tomada una foto. Para ello se utilizará Oauth, el estándar para comunicaciones entre aplicaciones web en la que hay acceso a datos de usuario.

El potencial de servicios basados en localización es muy amplio. Desde actualización automática en servicios tipo Facebook o Twitter, hasta integración en redes sociales para localizar a amigos, pasando por su uso en búsquedas desde el móvil. Lo que puede aportar Yahoo Fire Eagle es el facilitar una plataforma en la que delegar la captura, almacenamiento y gestión de este tipo de información. Para explicarlo mejor, un esquema de como funcionaría:

Yahoo Fire Eagle

Sitio oficial: Fire Eagle. Un análisis interesante en Venture Beat

API de contactos de Google

Facebook importando contactos

Tenemos nueva API de contactos de Google, la anuncian en blog oficial y básicamente permite a aplicaciones de terceros acceder a la lista de contactos de un usuario del universo Google (GMail, Reader, Talk). No se trata de la anunciada API social de Google basada en XFN y FOAF, sino de extraer información de la red social generada intrínsecamente a través del correo, Talk y Calendar.

¿Qué permite hacer esta nueva API? Pues para el usuario final significa poder importar sus contactos en el universo Google a otros servicios (los que implementen la API, claro) sin necesidad de darle su usuario y contraseña de GMail, lo cual no dejaba de ser una locura si lo pensamos bien: en esos casos se está dando acceso al correo, a documentos, a lecturas, a servicio de estadísticas, a Checkout… como se pide en sitios como Facebook. También hay opciones para la administración de contactos desde esos otros servicios, añadir, actualizar datos, borrar un contacto…

Aclaración: si se te pedirá el user/pass, pero la aplicación cliente no tendrá acceso a los mismos. Funciona con Authsub, que es muy similar al concepto de Oauth que hemos comentado por aquí.

En principio un movimiento interesante en torno al movimiento dataportability, aunque a bote pronto a uno le surgen un par de dudas. Sigo pensando la lista de contactos generados en un contexto y sus datos personales no son precisamente los datos que se deberían poder llevar de un sitio a otro sin el permiso de los mismos y que la red social basada en GMail no sirve, que nos hayamos intercambiado un correo no significa que seamos «contactos». En todo caso, creo que es una API que puede dar mucho juego y que sería interesante analizar junto a la de Windows Live Contacts API (sitio oficial.

Oauth, identificación abierta

OauthPara valorar en su justa medida OpenSocial, creo que hace falta echar un vistazo a Oauth, un estándar abierto cuyo último borrador fue lanzada hace apenas un mes. Oauth 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.

Imaginemos que queremos programar una aplicación tipo «página de inicio para el usuario», en la que este pueda añadir sus fotos de Flickr. Para ello utilizaremos el API de Flickr, le pediremos el nombre de usuario y contraseña al usuario y armaremos dicha página. En este tipo de situaciones es en el que Oauth tiene sentido, comunicaciones entre aplicaciones web en la que hay acceso a datos de usuario. La idea es que la aplicación cliente (en este ejemplo nuestra página de inicio) no tenga acceso al nombre de usuario y contraseña del usuario. Dicho de otro modo, Oauth es una metodología para identificación mediante APIs genérica y de implementación gratuita. Si estas cansado de servicios que te piden el usuario de Gmail o Hotmail para proveerte de tal o cual funcionalidad, ya puedes ir viendo por donde puede estar la utilidad de un protocolo como Oauth.

Por supuesto ya hay un montón de estándares cerrados que hacen esto, por ejemplo Google AuthSub o las APIs de Flickr y Facebook, pero la idea tras Oauth es unificar en un estándar abierto de forma que este tipo de comunicaciones entre aplicaciones web (bueno, el cliente puede ser web o de escritorio) no se articulen mediante protocolos propietarios.

Inmediatamente uno piensa en OpenId, pero Oauth no sustituye este estándar para identificación de usuarios, sino que lo complementa. De hecho, los usuarios nunca «ven» nada relacionado con Oauth, situado en el nivel de comunicación entre aplicaciones. De hecho, gran parte de la gracia de Oauth es que el usuario controle a qué datos acceden terceras aplicaciones. Siguiendo con el ejemplo de Flickr, se podría establecer qué tipo de fotos sí y cuáles no desde el servicio proveedor y los clientes no podría obtener nada más.

Como dato curioso, detrás de Oauth están Pownce, Twitter, SixApart, Jaiku, Flickr, Ma.gnolia y Google entre otros, aunque este último parece que no lo soporta en OpenSocial de entrada. Entiendo que el motivo es que no hay una versión final del estándar todavía.

Más información en su sitio oficial, que tiene blog. En español hay referencias en eConectados y La cofa.