Archive for Febrero 2008
Nueva fecha para la SDK del iPhone: el 6 de Marzo
Al menos eso es lo que se deduce de una invitación que varios periodistas (Apple to talk iPhone software plans on March 6, Apple event confirmed for March 6th for the “iPhone software roadmap”) han recibido para un evento que Apple celebrará en esa fecha, y en el que presentará sus planes para el software del iPhone, incluyendo la SDK y “algunas nuevas y excitantes caracterísitcas empresariales”.
Impacientes estamos.
Debate en la red sobre el futuro de las aplicaciones móviles
Una entrada publicada por Michael Mace, un consultor especializado en tecnología móvil, ha provocado un intenso debate sobre el futuro de las aplicaciones nativas para móviles. La entrada se titula Mobile applications, RIP, y comienza con un resumen que traduzco a continuación:
El negocio de hacer aplicaciones nativas para dispositivos móviles está muriendo, aplastado por un mercado fragmentado y prácticas de negocio restrictivas. Los problemas son tan graves que la web móvil, pese a sus muchas deficiencias técnicas, es ahora una forma mejor de proporcionar nueva funcionalidad a los móviles. Creo que esto conducirá a un rápido auge del desarrollo de la web móvil, reemplazando en gran parte al negocio de las aplicaciones móviles. Esto tiene enormes implicaciones para los operadores móviles, los fabricantes de dispositivos, los desarrolladores y los usuarios.
Mace vivió el auge y caída de Palm desde dentro, y percibe que se ha llegado a un punto en el que la falta de modelo de negocio de las aplicaciones nativas moverá gran parte de las aplicaciones a la web, técnicamente inferior pero con un modelo de negocio superior.
El artículo ha provocado respuestas de varios bloggers del mundo del desarrollo móvil. Mike Rowehl de Mowser está básicamente de acuerdo (Native Mobile Apps vs Mobile Web Apps) en esa tendencia hacia la web, aunque precisa que lo mismo ocurre con los ordenadores personales y las aplicaciones de escritorio. Simon Judge opina (Mobile Apps vs Web) que el modelo de negocio tradicional está efectivamente muerto, pero hay sitio para modelos alternativos como las aplicaciones nativas con publicidad integrada. Menos convencido se muestra Rafe Blandford, de allaboutsymbian.com, que considera (The future of mobile development?) que lo importante es que en el futuro los usuarios accederán a las aplicaciones de una manera uniforme, sin ser plenamente conscientes de si están accediendo a algo nativo o algo web. El que más se opone a la decadencia de las aplicaciones nativas es David Beers, otro veterano de Palm, para el cual (Have mobile apps had their moment?) a este tipo de aplicaciones les espera una época de esplendor, provocado, entre otras cosas, por los servicios basados en localización (LBS) y la creciente percepción por parte de los usuarios de que los dispositivos móviles son realmente una plataforma para ejecutar aplicaciones.
El debate todavía continúa, constituyendo un interesante ejemplo de conversación a través de blogs, tanto a través de los comentarios como con enlaces entre entradas que se contestan entre sí.
Mi opinión sobre el asunto: el iPhone y Android van a ser dos factores determinantes. Si alguna plataforma con un modelo de programación razonablemente abierto gana una importante cuota de mercado arrastrará a la competencia hacia el mismo modelo. El iPhone está teniendo un gran éxito comercial, pero falta ver cómo de abierta es su SDK; Android plantea una plataforma muy abierta, pero está por ver que consiga una cuota de mercado significativa. Pero si Android tiene la mitad de éxito que el iPhone, y Apple libera una SDK la mitad de abierta que la de Android, a las aplicaciones nativas para móviles les espera una época dorada.
Cómo mostrar imágenes de mapas en el móvil
En realidad esta entrada no se centra en cómo mostrar las imágenes, sino en cómo obtenerlas. Imaginemos que queremos programar una aplicación para móviles que se encargue de mostrar información geolocalizada. Existen abundantes APIs web que nos permiten mostrar todo tipo de información sobre un mapa, como las de Google, Yahoo o Microsoft, por citar sólo las tres más conocidas. El problema es que a estos servicios se accede usando JavaScript o Flash, ya que están pensados para visualizar la información en un navegador. Si no podemos renderizar esta información en nuestra aplicación, por ejemplo por falta de soporte javascript en el dispositivo, necesitamos buscar una alternativa que nos permita mostrar una imagen estática con la misma información.
Ingeniería inversa
Una práctica que se utiliza desde hace ya tiempo consiste en acudir a las mismas fuentes que el código Ajax o Flash, ya que al fin y al cabo los mapas que nos muestran los mash-ups habituales están compuestos por imágenes estáticas que se encuentran en algún sitio. Si por ejemplo abrimos la dirección http://code.google.com/apis/maps/documentation/examples/map-simple.html, que es el mapa de ejemplo de la documentación de Google, con Firefox y el plugin Firebug instalado o una herramienta similar, comprobamos que el mapa está compuesto de imágenes adyacentes, como si fuese un enlosado, cuyas direcciones tiene esta forma: http://mt2.google.com/mt?n=404&v=ap.69&hl=es&x=1315&y=3175&zoom=4&s=.
Los parámetros x e y nos muestran la posición de cada imagen en el enlosado, el zoom es autodescriptivo,… Con un poco de ingenio y paciencia es posible establecer una relación entre latitud y longitud y esos parámetros, o bien buscar en Internet a quien ya lo haya hecho.
Existen dos pegas a este procedimiento: la primera, que probablemente va contra los términos de uso de la API, así que si lo usamos en nuestras aplicaciones es posible que recibamos un aviso de Google, Yahoo! o Microsoft invitándonos a abandonar esta práctica. La segunda pega es la habitual al utilizar un procedimiento no documentado: en cualquier momento la especificación puede cambiar sin mantener ningún tipo de compatibilidad, inutilizando nuestro código.
Google Static Maps API
Una alternativa más segura es la nueva API de Google: la Static Maps API. Esta API es básicamente una URL que acepta varios parámetros, de la forma http://maps.google.com/staticmap?center=40.714728,-73.998672&zoom=14&size=512×512&maptype=mobile\ &markers=40.702147,-74.015794,blues%7C40.711614,-74.012318,greeng%7C40.718217,-73.998284,redc\ &key=MAPS_API_KEY.
Estos parámetros están bien documentados y permiten mostrar mapas indicando la posición, el zoom, la presencia de marcadores,…con la seguridad de que nadie nos va a cambiar los parámetros el mes que viene. La pega: las limitaciones en el número de peticiones a realizar. Cada usuario, y por lo que entiendo en la documentación el usuario es el dueño de la API key, puede hacer 1000 peticiones al día. Como nuestra API key irá en nuestra aplicación, todos nuestros usuarios contarán como el mismo para Google, con lo que esta API no es una solución práctica.
Yahoo! Map Image API
Yahoo! también tiene desde hace algún tiempo una API similar a la de Google: la Map Image API. Al igual que la anterior funciona componiendo una URL con parámetros: http://local.yahooapis.com/MapsService/V1/mapImage?appid=YahooDemo&street=701+First+Avenue&city=Sunnyvale&state=CA (en este caso lleva parámetros de búsqueda, pero también acepta latitud y longitud). Esta llamada no devuelve directamente una imagen, sino un xml que contiene, esta vez sí, la URL de la imagen solicitada:
<?xml version="1.0" encoding="UTF-8"?>
<Result xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
http://img.maps.yahoo.com/mapimage?MAPDATA=eJz6K.d6wXVM6myr2yRPfx6.kl.uMGgD3Tu4JtDQzr_33pFEsTT
SaosZ9OCtsiDrsLv9t65fzjz0CJm6JO2v_ZIHLflY9gto.xWMK9ovlRJVmrBLO4FoSsh3Ipsr
</Result>
La ventaja de la API de Yahoo! es que permite realizar 50000 peticiones por día y por IP, lo que la convierte en la alternativa más interesante de todas.
Habemus claves de BlackBerry
La gente de RIM me ha enviado unas claves nuevas y, esta vez sí, he conseguido registrarlas. No me han dado más detalles sobre el asunto, pero imagino que hubo algún problema por su parte en la activación de las claves anteriores. Tras el registro he podido probar el proceso de firma desde el JDE y ha funcionado bien: el entorno indica para cada uno de los tres tipos de claves (RBB, RCR y RRT, para APIs de aplicación, criptográficas y de run-time respectivamente) si la firma es requerida u opcional, y automáticamente calcula un hash del código, lo envía a RIM y lo devuelve firmado.
Aún no he tenido tiempo de probar la aplicación firmada en un dispositivo físico, pero ya queda menos para hacer pública una primera versión del plugin para BlackBerry.
OffTopic. Como parte de los cambios que estoy haciendo en esta bitácora, he añadido un widget de Ipoki. En realidad es el iFrame que aparece bajo el mapa de cada usuario en la web de Ipoki, añadido a mano a este tema de WordPress. Creo que queda bien.
Seguridad y libertad en la telefonía móvil
Varios medios de comunicación se han hecho eco (News.com, Reuters UK, MobileCrunch) de unas declaraciones del jefe de investigación de F-Secure, Mikko Hypponen, durante el pasado Mobile World Congress de Barcelona. En ellas alertaba del peligro que una plataforma abierta como Android puede suponer para la seguridad de los dispositivos móviles. Traduzco:
Si Android se convierte en una plataforma totalmente abierta… y cuando una plataforma así se vuelve más común, los riesgos son más grandes que con las actuales plataformas reina como Symbian.
En el mismo evento McAfee presentó un estudio realizado a dos mil usuarios de telefonía móvil, según el cual tres de cada cuatro usuarios estaban preocupados por la seguridad de los nuevos servicios móviles, y uno de cada siete había sufrido un virus para móviles o conocía a alguien que lo había hecho. Su vicepresidente, Victor Kouznetsov, declaró:
Los miedos de los consumidores crecen a la vez que se incrementan las funcionalidades móviles.
No he podido evitar pensar en el paralelismo existente entre este discurso y el tipo de mensaje, cada vez más habitual en Europa y Estados Unidos, que algunos políticos utilizan para hablar de terrorismo y delincuencia. Dicho mensaje se resume más o menos así: las sociedades libres están cada vez más amenazadas por peligros externos, y es responsabilidad de los líderes de dichas estas sociedades hacer todo lo que sea necesario para protegerlas. Consecuencia: el abandono de la libertad como valor irrenunciable de la sociedad en favor de la seguridad. Libertad y seguridad son valores que se oponen, al menos en este ámbito, y al menos mientras confiemos en que los que restringen nuestra libertad lo hacen por nuestra seguridad. Y por lo que parece no hay límite a la cantidad de libertad que estamos dispuestos a cambiar por (supuesta) seguridad.
Esta oposición libertad-seguridad puede que exista en la sociedad civil, pero no hay ningún motivo para pensar que exista en el mundo tecnológico. En este las opciones libres se han caracterizado hasta ahora por ser tanto o más seguras que las opciones restrictivas. Si los problemas de seguridad existentes en Linux son inferiores a aquellos existentes en Windows, ¿qué lleva a F-Secure y a McAfee a pensar que Android será más vulnerable a virus y troyanos que Symbian?
Para ser honesto, el paralelismo Linux vs. Windows con Android vs. Symbian no es total. La diferencia entre Android y Symbian no es que el código fuente de uno sea abierto y el otro no, o que uno sea gratis y otro de pago. La diferencia fundamental es que Android será una plataforma sobre la que programar y desarrollar servicios libremente, que espera tener una comunidad de desarrolladores que aporte aplicaciones de calidad de forma similar a lo que ocurre en el mundo GNU/Linux. Symbian, por otro lado, pone impedimentos a que las aplicaciones de la comunidad libre (e incluso de programadores profesionales pero con recursos limitados) se extiendan entre sus dispositivos, utilizando un sistema de firma de aplicaciones caro y complicado. El razonamiento detrás de esta estrategia es: si es difícil que cualquiera desarrolle una aplicación para Symbian, entonces es difícil que alguien introduzca un virus o un troyano en los dispositivos Symbian.
Se me ocurren algunas objeciones a este planteamiento. La percepción del teléfono móvil como aparato que sirve básicamente para hablar por teléfono probablemente tenga los días contados. Algunas aplicaciones se han ido añadiendo de forma natural, como el envío de mensajes y la capacidad para sacar fotos, de forma que consideramos los SMS como algo propio del teléfono móvil y hablamos de la cámara del móvil como un añadido natural a este dispositivo. Sin embargo el futuro parece pasar más bien por un dispositivo portátil que vaya incorporando cada vez más funciones; algunas, como el GPS, parecen estar haciéndose ya un hueco en los dispositivos de gama alta; otras, como la televisión, ya son perfectamente comunes en Japón, mercado que nos lleva algunos años de adelanto. Con estas expectativas, una plataforma capaz de atraer todo tipo de servicios innovadores, permitiendo que sea la demanda de los usuarios la que decida qué servicios triunfan, presenta más posibilidades de supervivencia a largo plazo que otra que limite la capacidad de innovación.
Apple ha intentado hacer del iPhone un dispositivo cerrado y ha sido víctima del éxito de su producto: inmediatamente han aparecido parches para abrir el sistema, parches que pese a suponer cierto riesgo de inutilizar el aparato han tenido un uso masivo. Esta situación de dispositivo “cerrado pero no” es la que más fácil se lo pone a potenciales creadores de malware. En cuanto a Nokia, la situación no es mucho mejor: las posibilidades de la plataforma S60 quedan ocultas tras las complicaciones del proceso de firma de aplicaciones, pese a que programadores como Samir han mostrado que los usuarios están dispuestos ha emplear tiempo y esfuerzo a cambio de un poco de innovación en sus móviles.
¿Triunfará la plataforma Android? Eso nadie lo sabe aún. El mercado de la telefonía móvil es muy dinámico y complejo, y ni todo el respaldo de Google puede garantizar el éxito de algo que va a necesitar el apoyo de los fabricantes de dispositivos, las operadoras de telefonía, los desarrolladores de software y, por supuesto, los usuarios. Sin embargo, una cosa sí tengo clara: ser una plataforma abierta jugará en su favor.
Más sobre BlackBerry
Hoy he recibido un correo de RIM informándome de que me mandarán unas nuevas claves para que pruebe con ellas, y pidiéndome disculpas por las molestias. Sigue sin parecerme muy serio, porque aún no tengo las claves, ni me han dado más explicaciones.
Pero es que además hoy se ha caído el servicio BlackBerry en Estados Unidos, por segunda vez en la semana y de forma bastante estrepitosa (hablan de un apagón del 80%), en lo que parece ser la confirmación de que la calidad del servicio de RIM ha tocado fondo.
Visto lo visto, hasta he tenido suerte de que me respondan.
Intentando firmar una aplicación BlackBerry (no todo va a ser Symbian)
Como parte del proceso de desarrollo del plugin de Ipoki para BlackBerry, solicité a RIM unas claves para firmar la aplicación, que utiliza algunas clases marcadas como Signed en la documentación. Estas clases obligan a que la aplicación esté firmada antes de ser instalada en un dispositivo. Para solicitar las claves existen dos posibilidades: rellenar este formulario, o descargar esta versión del formulario en pdf, imprimirla, firmarla y enviarla por fax. La existencia de esta última opción es el primer indicio de que RIM todavía no ha entrado en el siglo XXI.
Conseguir la claves cuesta 20 dólares, una cifra bastante económica que en la página que describe el proceso de solicitud justifican por los costes administrativos. En realidad se hace fundamentalmente para tener los datos del titular de la tarjeta de crédito. En esta misma página se nos dice qué ocurrirá tras el envío de la solicitud (traducción propia):
Nota: Típicamente, las claves son enviadas por email en un plazo de 48 horas tras el envío de los formularios necesarios, pero ocasionalmente el proceso puede llevar hasta 10 días laborables. Si no ha recibido sus claves en el plazo de 10 días laborables desde el envío del formulario de registro, por favor póngase en contacto con el soporte de BlackBerry en el número 1-877-255-2377.
Sinceramente, sólo se me ocurre un motivo por el cual puedan tardar diez días en enviarte por correo tres archivos de menos de un KByte que obviamente un ordenador genera de forma inmediata: quieren comprobar mis datos con el FBI. ¿Y el motivo por el cual mi único opción de ponerme en contacto con soporte es un número de teléfono norteamericano (eso sí, gratuito para llamadas desde USA o Canadá)? Será para que el FBI pueda rastrear mi llamada…
Mi experiencia con el proceso transcurrió así: cubro mis datos, doy mi tarjeta y envío el formulario aceptando unas condiciones que por supuesto no he leído. La página me informa de que mi solicitud ha sido procesada, pero a mi correo no llega ninguna confirmación, ningún ticket de seguimiento, nada que me confirme que han tomado nota y que mis 20 dólares van a servir de algo. Tras cuatro días preguntándome si habría escrito bien mi dirección de correo electrónico recibo las claves, en tres correos distintos pero con el mismo texto explicando la instalación de las mismas. La instalación es simple:
To register the attachment, please follow the instructions below:
1) Double-click on the attachment.
2) If a dialog box appears that states that a private key cannot be found, complete steps 3 through 6 before you continue. Otherwise, proceed to step 7.
3) Click “Yes” to create a new key pair file.
4) Type a password for your private key, and type it again to confirm.
5) Click “Ok”
6) Move your mouse to generate date for a new private key.
7) In the “Registration PIN” field, type the PIN number that you supplied on the signature key request form.
8 ) In the Private Key password field, type a password of at least 8 characters. This is your private key password, which protects your private key. Please remember this password as you will be prompted for it each time signing is attempted.
9) Click “Register”.
10) Click “Exit”.Note: All 3 keys (RBB, RCR, RRT) received should be installed on the same PC. The same password must be specified for all keys on the same PC.
Así que hago doble click a una de las claves, le doy a Yes y… no pasa nada. Pruebo varias veces con cada una de las claves y me cercioro de que efectivamente no funciona. Tras un poco de Google llego a la conclusión de que es culpa de la versión de Java. Teóricamente el JDE 4.1 funciona con Java5 y no con Java6. Esto no es cierto, yo sólo tengo Java6 instalado y el JDE me va perfectamente. Sin embargo, hago la prueba para ver si la firma falla por eso. Instalo Java5 y desinstalo Java6 y….¡Tachán! La clave me pide una contraseña para su instalación. Problema resuelto.
Ahora sólo tengo que introducir la clave de privada y la clave de registro y…
“Registration request failed because client ID xxxxxxxxxx is not set up to be registered (that is, the ID was not in the authorisation database)”
De este no me salva ni Google. Primero porque no hay ninguna referencia a un error con ese texto, y segundo porque tiene toda la pinta de ser algún error en el proceso de registro, no en mi ordenador. Lo único que me queda es ponerme en contacto con el soporte de BlackBerry para contarles lo que me ha ocurrido. Por suerte el correo con las claves incluía también una dirección de correo electrónico de soporte.
De momento no he tenido noticias de RIM; tampoco es que esperase que tuviesen un servicio 24×7 para esto. Por lo que he visto hasta ahora el servicio de firma de aplicaciones de RIM no es todo lo satisfactorio de se podría esperar. Y aún falta la firma real, en la cual se envía un hash del código que RIM debe devolver firmado. Veremos cómo acaba todo.
OpenID: inicio de sesión único en Internet
Una de las consecuencias del boom de esta cosa llamada Web2.0, en la que las aplicaciones web se cuentan por cientos o miles, es la necesidad de mantener un usuario con su contraseña para cada uno de esos sitios. Tenemos que elegir entre memorizar varias contraseñas y recordar dónde se usa cada una, o bien, como suele ser más común, utilizar el mismo usuario y contraseña (quizás un par de ellas) para todos los sitios que frecuentamos. Esta última opción es bastante peligrosa, pues basta con que alguien con malas intenciones nos capture una contraseña (y a veces no por nuestra culpa) para que todas nuestras cuentas queden expuestas.
Una solución habitual a este problema son los sistemas Single Sign-On (Inicio de sesión único), que permiten que nos identifiquemos ante un solo sistema, el cual se encargará de acreditar nuestra identidad a los demás sistemas a los que queramos acceder. Los Single Sign-On son frecuentes en entornos corporativos, donde no tiene sentido que los usuario se autentiquen ante cada aplicación si ya se han autenticado inicialmente en el sistema (al iniciar sesión en la red corporativa, por ejemplo). En internet, sin embargo, el inicio de sesión único sólo está presente para los servicios de una misma empresa (puedo acceder con mi usuario de Google a todos los servicios de Google, con mi usuario de Yahoo! a todos los servicios de Yahoo!, etc.). Para que yo pudiese acceder a los servicios de Yahoo! con mi cuenta de Google, ambos sistemas tendrían que establecer algún tipo de protocolo para poder transmitir información de identificación de usuarios, y además comprometerse a confiar en ella.
Algo así es lo que pretende OpenID. Desarrollado por Brad Fitzpatrick, el creador del popular sistema de blogging LiveJournal, OpenID aspira a convertirse en un estándar de internet que permita a los usuarios utilizar una única cuenta para acceder a los servicios que utilice.
¿Cómo funciona?
El funcionamiento básico es el siguiente: el usuario crea una cuenta con un proveedor de identidades de OpenID por el procedimiento habitual, con un usuario y una contraseña. A cambio, el proveedor de OpenID da al usuario un identificador, que típicamente es una URL, del estilo http://usuario.dominioop.com. Por ejemplo, yo tengo una cuenta en el proveedor myopenid.com que se llama http://javiercancela.myopenid.com/. Se puede consultar una lista de proveedores aquí: Public OpenID Providers.
Con este identificador el usuario se dirige al sitio al que quiera acceder con su OpenID (voy a elegir para el ejemplo Plaxo, una lista de posibles sitios se puede consultar aquí: Directorio de sitios OpenID) En la pantalla de inicio de sesión se muestra un recuadro para iniciar sesión con OpenID, que tendrá además este icono: 
:
Al introducir el identificador (http://javiercancela.myopenid.com) el usuario será redirigido al sitio de su proveedor (en mi caso myopenid.com), donde iniciará sesión con su usuario y contraseña (salvo que alguna cookie mantenga la sesión iniciada). Su proveedor le preguntará si quiere confirmar su identidad al servicio al que intenta acceder (en mi caso, Plaxo):
Una vez completado el proceso el usuario se habrá identificado ante el servicio en cuestión sin necesidad de proporcionarle un usuario y una contraseña. Este servicio tendrá acceso además a la información del perfil que haya proporcionado a su proveedor. Así, Plaxo puede saber mi dirección de correo electrónico o mi fecha de cumpleaños, si he proporcionado esta información a myOpenID.com.
OpenID en nuestra web
OpenId es un estándar abierto, así que no es necesario pedir permiso a nadie para convertirse en un proveedor de OpenID. Existen varias herramientas para ello, y aunque la información sobre cómo utilizarlas no es (aún) abundante, dejo aquí un par de enlaces que he encontrado (eso sí, en inglés):
En caso de que simplemente queramos que nuestros usuarios puedan usar sus identificadores OpenID para acceder a nuestro sitio, este tutorial que he visto en Plaxo lo explica todo bastante bien (también en inglés):
Situación actual
OpenID se ha apuntado varios éxitos últimamente, primero con la incorporación de Yahoo! y sus millones de usuarios al proyecto (Yahoo To Become an OpenID Provider, Giving 248 Million Users Web-Wide Identities), y posteriormente con la incorporación de Microsoft, Google, Yahoo!, IBM y VeriSign al OpenID Foundation Board, el organismo que promociona y supervisa las tecnología y la comunidad OpenID. Sin embargo, más que una apuesta decidida por un estándar abierto de autenticación en internet, estas incoporaciones parecen más bien tomas de posición en una iniciativa con mucho potencial pero todavía con muchas dudas.
Recordando lo que explicábamos anteriormente, existen dos roles que un sitio de internet puede adoptar respecto a OpenID: proveedor de identidad, y cliente de un proveedor. Lógicamente, lo que interesa a los usuarios es que haya el mayor número de clientes; una vez que han elegido su proveedor favorito (su cuenta de Yahoo!, WordPress, myOpenID…) sólo necesitan que sus sitios habituales les permitan utilizar el identificador de este proveedor. Sin embargo, lo que realmente interesa a las empresas de internet es posicionarse como proveedores. Yahoo!, al permitir que sus cuentas se usen como identificadores OpenID, ha conseguido acceso a un montón de información sobre los hábitos de navegación de sus usuarios. Como además Yahoo! no permite que se usen cuentas OpenID para acceder a sus propios servicios su incorporación al proyecto es todo ganancia. Google hace algo similar en Blogger: las direcciones de BlogSpot se pueden usar como OpenId (si se habilitan para ello), pero las demás cuentas OpenID sólo se pueden usar para comentar en Blogger (algo que probablemente fue la motivación original del sistema, que como dijimos creó el fundador de LiveJournal). Microsoft tiene su propio sistema de autenticación: Windows CardSpace. Sin embargo, más que una alternativa a OpenID CardSpace es un sistema complementario: permite al usuario autenticarse ante alguien (que puede ser un proveedor OpenID) con un sistema de tarjetas de identidad digitales.
Conclusiones
Un sistema de Single Sign-On distribuido como este presenta dos problemas principales: por un lado la privacidad de nuestros datos, ya que nuestro proveedor de autenticación tendrá acceso a todos los sitios que visitemos usando su identificador; por otro lado la seguridad: el sistema de redirección utilizado nos hace vulnerables a sitios que, fingiendo aceptar nuestro OpenID, nos redirijan a una falsificación de la página de autenticación de nuestro proveedor para hacerse con nuestra contraseña, y por tanto con nuestro identificador OpenID.
OpenID es una iniciativa todavía en construcción (en beta, podríamos decir), pero con opciones de convertirse en un estándar de internet si recibe el apoyo necesario. Ya veremos si lo consigue.
Nueva versión de la SDK de Android
Ya está disponible la nueva versión de la SDK de Android. Entre los cambios destacados, una nueva clase para traducir direcciones a coordenadas y viceversa, y un nuevo paquete para la animación de los fondos de las aplicaciones. Además de mejoras diversas y arreglo de bugs.
La descarga está disponible aquí, una lista con los cambios aquí, y las instrucciones para la actualización aquí.
¿Para qué modelo de BlackBerry desarrollar?
A la hora de desarrollar software para dispositivos BlackBerry, y para que nuestro producto sea compatible con la mayor cantidad posible de modelos, es útil tener en cuenta dos cosas:
- Con el JDE desarrollamos para una versión concreta del BlackBerry Handheld Software, el “sistema operativo” del dispositivo. Teóricamente existe compatibilidad hacia atrás, de forma que con el JDE 4.1 obtendremos una aplicación capaz de ejecutarse en dispositivos con versiones 4.1, 4.2 o 4.3 del BlackBerry Handheld Software. Así, conviene siempre utilizar la versión menor que permita desarrollar la aplicación que queremos.
- Los dispositivos BlackBerry son actualizables: para cada familia de BlackBerrys se liberan versiones actualizadas del sistema, generalmente por parte de las propias operadoras. Una lista actualizada con el último sistema disponible para cada dispositivo se puede encontrar en los foros de BlackBerryFORUMS.
Actualizar el software de la BlackBerry no es demasiado complejo, y para la mayoría de las BlackBerry recientes existe una actualización para la versión 4.2 del software. Para saber qué versión tiene un dispositivo basta con ir a Options->About.
