A través de TorrentFreak llego a una noticia en la que comentan que la policía alemana ha detenido al responsable de la web de alojamiento de archivos Skyload. Nada nuevo bajo el sol tras los sucesos de Megaupload. Lo más curioso, tratándose de un país que está dentro de la Unión Europea, es que también han detenido al responsable de su ISP. La noticia no aclara demasiado sobre el grado de implicación del ISP en la web de alojamiento de archivos, por lo que no hay que sacar conclusiones adelantadas, pero si no está implicado y se empieza a atacar a los proveedores de alojamiento, se creará una gran inseguridad en este tipo de negocios, tanto desde las empresas que revenden alojamiento como en aquellas que ofrecen desde alojamiento compartido hasta servicios de cloud, pasando por servidores dedicados: Amazon, Arsys, Acens, Strato, 1&1,…
La normativa española (LSSICE, artículo 16) es bastante clara en este aspecto:
Artículo 16. Responsabilidad de los prestadores de servicios de alojamiento o almacenamiento de datos.
1. Los prestadores de un servicio de intermediación consistente en albergar datos proporcionados por el destinatario de este servicio no serán responsables por la información almacenada a petición del destinatario, siempre que:
No tengan conocimiento efectivo de que la actividad o la información almacenada es ilícita o de que lesiona bienes o derechos de un tercero susceptibles de indemnización, o
Si lo tienen, actúen con diligencia para retirar los datos o hacer imposible el acceso a ellos.
Se entenderá que el prestador de servicios tiene el conocimiento efectivo a que se refiere el párrafo a) cuando un órgano competente haya declarado la ilicitud de los datos, ordenado su retirada o que se imposibilite el acceso a los mismos, o se hubiera declarado la existencia de la lesión, y el prestador conociera la correspondiente resolución, sin perjuicio de los procedimientos de detección y retirada de contenidos que los prestadores apliquen en virtud de acuerdos voluntarios y de otros medios de conocimiento efectivo que pudieran establecerse.
Al tratarse de una normativa que viene a incorporar al ordenamiento jurídico español la Directiva 2000/31/CE, del Parlamento Europeo y del Consejo, de 8 de junio, relativa a determinados aspectos de los servicios de la sociedad de la información, también debería de estar incorporada en el sistema jurídico alemán, que es donde ocurrieron los hechos. El artículo 14 de la directiva indica lo siguiente:
Alojamiento de datos
1. Los Estados miembros garantizarán que, cuando se preste un servicio de la sociedad de la información consistente en almacenar datos facilitados por el destinatario del servicio, el prestador de servicios no pueda ser considerado responsable de los datos almacenados a petición del destinatario, a condición de que:
a) el prestador de servicios no tenga conocimiento efectivo de que la actividad a la información es ilícita y, en lo que se refiere a una acción por daños y perjuicios, no tenga conocimiento de hechos o circunstancias por los que la actividad o la información revele su carácter ilícito, o de que,
b) en cuanto tenga conocimiento de estos puntos, el prestador de servicios actúe con prontitud para retirar los datos o hacer que el acceso a ellos sea imposible.
Aquí entramos otra vez en lo que se entiende por conocimiento efectivo, y que en las sentencias en España ha sido interpretado de diferentes formas.
Espero que no se trate de un caso de ataque a los proveedores de alojamiento, ya que este hecho, si se repite, podría crear una inseguridad es este tipo de negocio, con la consiguiente necesidad de un control previo por parte de los servicios de alojamiento que considero casi imposible, con lo que el panorama del alojamiento podría cambiar sustancialmente o sufrir un fuerte receso, y por extensión, los servicios que los utilizan.
Comentaba hace unos días el caso de una compañía que damandaba a varias de las grandes .com en Estados Unidos por el uso de una de sus presuntas patentes, la de la web interactiva. Un jurado ha rechazado la demanda, declarándola inválida.
Otro ejemplo más del sinsentido de las patentes en determinadas tecnologías. Otro caso más de un “troll de las patentes” que trata de obtener dinero con unas patentes absurdas o triviales. En este caso el “fenómeno” es Michael Doyle, dueño de una compañía que ya ganó en su momento una demanda a Microsoft por un importe de 521 millones de dólares. Leyendo este artículo hay un párrafo muy curioso:
The University of California will receive 25 percent of the proceeds from the verdict, while Eolas will obtain the rest, minus legal fees and costs, Lueck said. The university owns the patent for the technology, which it licensed to Eolas in 1994. Eolas has one formal employee, Mike Doyle, who is a former University of California researcher.
Al final llegaron a un acuerdo, por lo que la compañía de Redmond tuvo que pagar una cantidad elevada, no publicada, pero la parte que correspondió a la Universidad de California ascendió a 30.4 millones de dólares.
Claramente se trata de una empresa que se dedica a patentar o adquirir licencias de patentes y a obtener dinero ganando demandas o llegando a acuerdos con las empresas que demanda antes de llegar a celebrar el juicio. Ese año la empresa solo tenía 1 empleado, tal y como comenta cnet en el artículo. En su web se puede ver que todas las noticias están relacionadas con demandas o firmas de acuerdo por licenciamiento de patentes. Además la demanda era por un concepto trivial:
alleging that the Redmond giant infringed on one of its patents when enabling Internet Explorer to use plug-ins and applets in the software.
Es decir, ganaron la demanda por algo tan genérico y trivial como la ejecución de un complemento en un navegador, añadiéndole funcionalidad.
Pues la actual demanda va más allá. En este caso el fenómeno y su empresa demandan a ocho compañías (Yahoo, Amazon, Google,YouTube, GoDaddy, JC Penney, Staples y CDW Corp) alegando que en el año 1993 inventaron y patentaron nada menos que la “web interactiva“. Otras como Apple, Playboy, Perot Systems, Blockbuster, Citigroup, eBay o Frito-Lay también fueron demandadas por lo mismo, pero llegaron a un acuerdo extrajudicial. Lo que buscan es un pago de royalties en cualquier uso de tecnología interactiva en Internet: ver un vídeo, mostrar sugerencias en la búsqueda instantánea, rotar o cambiar el color de una imagen en una web de comercio electrónico,… La cantidad solicitada: 600 millones de dólares, en su mayor parte a Google y a Yahoo.
Incluso Tim Berners-Lee, el padre de la web, ha tenido que declarar ante el jurado, afirmando que “estas patentes podrían suponer una seria amenaza al futuro de la web”.
Si esta demanda prospera nada le impediría a esta empresa realizar demandas en serie, impidiendo o poniendo muy difícil a muchas empresas operar en Internet o, simplemente, disponer de una web corporativa interactiva.
Creo que el tema de las patentes, y especialmente las patentes de software se les ha ido de las manos a los norteamericanos, permitiendo patentar elementos triviales y destinando una gran cantidad de recursos a demandar a la competencia para impedir el uso de sus tecnologías o para obtener dinero por elementos tan genéricos como la “web interactiva”. Un ejemplo de todo este sinsentido es que Apple ya ha gastado 100 millones de dólares en la guerra de patentes contra HTC.
Además, este tipo de resoluciones judiciales favorables a estas empresas (trolls de patentes) obliga a muchas de las demandadas a llegar a acuerdos o a litigar y llegar a tener graves problemas financieros por culpa de este tipo de empresas. Bajo mi punto de vista crea una gran inseguridad jurídica, ya que ante patentes tan genéricas y amplias como esta u otras como la “1-click” de Amazon podrían ser utilizadas para atacar y obligar a cerrar a casi cualquier compañía que realice negocios en Internet.
¿No sería más adecuado para el beneficio de la humanidad que este dinero que se gasta en patentes y demandas se invirtiera en innovación, marketing,… para crear cada vez productos mejores, de los que se beneficiarían sus clientes? ¿No sería preferible que, por ejemplo, Apple invirtiera ese dinero en mejorar cada vez sus productos y no en tratar de impedir que Android pueda competir con ellos en igualdad de condiciones?
A través de este blog llego a una tremenda reflexión de Marshall Kirkpatrick, co-editor del blog de tecnología ReadWriteWeb, es probablemente una de las dos personas en el mundo que cree mas que yo en el uso de RSS.
My take on it is this, and I’ll try to say this without getting too upset about it: the lack of uptake of RSS reading software by consumers and businesses is among the turns of events in recent technology history that’s most disparaging of the state of humanity. That a personalized, centralized repository for updates from dynamic streams of information delivered by free trusted sources of democratic publishing all over the world has had its tech-lunch eaten by mind-rotting casual Flash games on Facebook is as depressing as the way that public education dreams were dashed when the promise of television became its reality. It’s like the psychedelic dreams of Harvard’s Dr. Timothy Leary becoming the wretched, heartbreaking narcotic drama of the TV show The Wire. It’s terrible. It’s reason to pack it all up and go home.
Que, traducido, viene a decir:
Mi opinión es esta, y voy a intentar decirla sin sobresaltarme demasiado: La falta de adopción del software de lectura RSS por parte de los consumidores y de los negocios es uno de los sucesos en la reciente historia tecnológica que peor habla del estado de la humanidad. Que un repositorio personalizado y centralizado de actualizaciones hechas a través de canales dinámicos de información ofrecidos por fuentes gratuitas y confiables de publicación democrática en todo el mundo haya sido ignorado tecnológicamente y reemplazado en la atención popular por jueguecitos que pudren la mente hechos en Flash en Facebook es tan deprimente como la manera en la que los sueños de la educación pública se quebraron cuando la promesa de la televisión se volvió su realidad. [...] Es terrible. Es razón para empaquetar todo y marcharse a casa.
Soy de los que lleva años, ya no sé cuantos, accediendo diariamente a toda la información que leo a través de Google Reader, mediante los feeds que tengo agragado. Antes lo hacía a través de Netvibes.
Aún me cuesta entender, moviéndome en un sector tecnológico, que la gente que me rodea apenas utiliza lectores RSS. Prefieren navegar página a página, con la pérdida de tiempo y la saturación de información que ello supone. Con un lector RSS vas leyendo titulares de una forma rápida y accedes solo a aquellas noticias que te interesan. Cuando acabas, marcas todos como leídos y hasta la próxima revisión.
De vez en cuando logro convencer a alguien de que utilice un lector RSS. Cada vez que logro “evangelizar” a una persona en su uso, creo que mi karma aumenta Si aún no utilizas un lector RSS, ¿a qué estás esperando?
Para acceder a muchos sitios web (Facebook, Amazon, …) utilizamos como nombre de usuario nuestra dirección de correo electrónico. Para el desarrollador web es una forma sencilla de obtener una dirección de correo electrónico, que puede ser utilizada para varias acciones útiles dentro de la web: validar la inscripción en el sitio web, obtener o recuperar la contraseña de acceso, enviar notificaciones,… En otros sitios utilizan un nombre de usuario (Slashdot, Barrapunto, …), decisión que me gusta menos, ya que necesitas pedir más datos al usuario para realizar su registro, con los posibles abandonos en el registro que esto puede acarrear. Incluso bastantes sitios (Menéame, Stack Overflow,…) permiten registrarse y autenficarse con el usuario de Facebook, de Twitter o de Google+, con lo que el tiempo de registro es mucho menor y, por lo tanto, el porcentaje de abandono también es menor. Es un punto clave en el comercio electrónico, ya que muchas tiendas permiten añadir productos al “carrito de compra virtual” sin estar registrados y se solicita el registro al finalizar la compra, momento en el que se produce la mayor parte de los abandonos, perdiendo la venta.
Volvamos al registro que utiliza la dirección de correo electrónico como nombre de usuario. Algo tan sencillo para el usuario final como introducir su dirección de correo electrónico al registrarse o al acceder a la aplicación web plantea varias cuestiones al desarrollador de la aplicación web. Entre ellas está la que trataré de analizar en esta entrada, algo que puede parecer tan trivial y sencillo como qué hacer ante dos direcciones idénticas pero una escrita con minúsculas y otra con mayúsculas, como por ejemplo pepe@example.com y PePe@example.com
Lo primero que se nos puede pasar por la cabeza es convertir todo a minúsculas, de tal forma que tanto la inserción en la base de datos como las comprobaciones al tratar de encontrar usuarios ya existentes en el proceso de registro o al tratar de acceder al sistema el en proceso de autentificación utilicen siempre comprobaciones en minúsculas. Este planteamiento puede ser correcto, o no. Voy a plantear su análisis desde tres puntos de vista: el técnico, el del usuario final y el “estándar de facto” o lo que están haciendo las grandes compañías.
Técnico
Para analizar cómo debe afrontar un desarrollador este problema hay que ver cómo se define una dirección de correo electrónico. Esta está formada de la siguiente forma
user@example.com
La parte local de la dirección de correo electrónico (“user” en el ejemplo) solo puede utilizar los caracteres ASCII indicados en la sección 3.2.3 del RFC 5322 (Internet Message Format), entre los que se encuentran las letras minúsculas y mayúsculas del alfabeto inglés. Aquí ya se hace una primera distinción de mayúsculas y minúsculas. En la sección 2.4 del RFC 2821 (Simple Mail Transfer Protocol) se aclara totalmente:
The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. Mailbox domains are not case sensitive. In particular, for some hosts the user “smith” is different from the user “Smith”. However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.
Lo que viene a decir aquí es que los servidores de correo deben de ser sensible a mayúsculas, pero se recomienda mantener una política interna en la organización que evite estos problemas de colisión.
Además indica que la parte de dominio (lo que va despues de la @, en el ejemplo sería example.com) no es sensible a mayúsculas, tal y como se puede comprobar a lo largo del RFC 1035 (Domain names – Implementation and specification), leyendo los párrafos donde aparacen las palabras “case-insensitive” y como se aclara en el RFC 4343 (Domain Name System (DNS) Case Insensitivity Clarification).
Aclarándonos, lo que va antes de la @ es sensible a mayúsculas (aunque no se recomienda su uso para evitar problemas de interoperatibilidad) y lo que va después no es sensible a mayúsculas.
Aquí llega el primer problema, que es el de las colisiones si normalizo todas las direcciones de correo electrónico a minúsculas antes de insertarlas en la base de datos o antes de hacer las comparaciones (usuario existente en el proceso de registro, proceso de autentificación,…).
Un ejemplo claro es qué pasa si un usuario PePe@example.com se registra en mi sistema web y el servidor de correo electrónico de “example.com” tiene otro usuario cuya dirección de correo electrónico es pepe@example.com. Si este servidor de correo es sensible a mayúsculas la confirmación de la inscripción en el sitio web o la recuperación de la contraseña tendría que ser enviada al usuario PePe@example.com, pero llegaría a otro buzón de entrada, al del usuario pepe@example.com, con el consiguiente problema de seguridad que acarrea. Este tipo de problemas se pueden atacar de varias formas en el sistema web, como podría ser guardar el nombre de usuario en el formato original (PePe@example.com) y hacer que las comprobaciones no sean sensibles a mayúsculas. Pero nos encontraríamos con otro problema, ya que aunque el sistema podría registrar a los dos usuarios (PePe@example.com y pepe@example.com), ¿qué hago en el proceso de autentificación o de recuperación de la contraseña? ¿A quién le envío el token de recuperación de la contraseña?
Otro ejemplo problemático sería ¿qué hacer si tengo un sistema sensible a mayúsculas, el usuario se registra con la dirección PePe@example.com (por equivocación), recibe el correo electrónico de confirmación de la inscripción en la dirección pepe@example.com (sistema de correo no sensible a mayúsculas, que hay unos cuantos, como mostraré posteriormente) y al tratar de acceder posteriormente con el usuario pepe@example.com se le indica que el usuario no existe, ni es posible que recupere su contraseña.
Los casos problemáticos son unos cuantos si nos paramos a analizarlos, con la reducción de usabilidad del sistema, y, consecuentemente, con la frustración por parte del usuario en el uso de la aplicación web, que puede llevar a su abandono.
Usuario
Vistos algunos de los problemas que pueden plantearse cuando tratamos de ceñirnos a los RFC, ahora enfoco el problema desde el punto de vista del usuario final, del que va a registrarse y a utilizar nuestro sistema web. Deberíamos buscar un sistema usable, que no le haga pensar este tipo de cuestiones al usuario ni en el registro, ni en la autentificación ni en el proceso de recuperación de la contraseña. Que le pida una dirección de correo electrónico, una contraseña (por duplicado o no), que le pida (o no) confirmación del registro y…. listo.
Analizado el problema desde este punto de vista, tendríamos que tratar como el mismo usuario y la misma dirección de correo electrónico a PePe@example.com, a pepe@example.com, a PEPE@EXAMPLE.COM y a PEPE@example.com. Lo más cómodo para el desarrollador será realizar una conversión a minúsculas en la dirección de correo electrónico antes de utilizarla para cualquier tipo de procesado o almacenamiento.
El único problema es que si el servidor de correo electrónico de la organización “example.com” es sensible a mayúsculas y en mi sistema trata de registrarse PePe@example.com, el correo de confirmación nunca le llegará a él, sino a la cuenta pepe@example.com, en el caso de que exista.
Los “big players”
En estos momentos los tres principales proveedores de cuentas de correo gratuitas (Gmail, Yahoo y Hotmail), y quizás las más utilizadas por los usuarios en su ámbito personal no son sensibles a mayúsculas. No busqué ningún documento para comprobarlo. Simplemente envié un correo electrónico a mis direcciones en los tres servicios, pero cambiando el nombre de usuario, que en todos los casos está en minúsculas, por otro en el que intercalaba una letra mayúscula y una minúscula. Los correos llegaron de forma casi instantánea.
Conclusiones
Lo primero sería plantearse si es lo correcto utilizar una dirección de correo electrónico como usuario en el portal. Los portales web que utilizan un nombre de usuario único pueden mantener la dirección de correo electrónico original, sensible a mayúsculas, en su base de datos, de tal forma que se utiliza el usuario para el proceso de autentificación y el correo electrónico para la confirmación de la inscripción y para la recuperación de la contraseña. Ya serán los servidores de correo electrónico los que se encarguen de gestionar la problemática con cómo esté escrita la dirección de correo electrónico que el usuario utilizó al registrarse. Los principales portales (Facebook, Twitter,…) no están utilizando este formato ni es la tendencia actual.
Descartado este sistema, si queremos ser estrictos y cumplir a rajatabla los estándares de Internet, sin lugar a dudas hay que desarrollar un sistema sensible a mayúsculas.
Pero viendo cómo operan los grandes proveedores de correo electrónico, analizando qué es lo más usable y adecuado para el usuario final (que será el que dictamine el éxito o fracaso del sistema web) y viendo que ni en el RFC 2821 (el de SMTP) lo recomiendan (exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.) , si yo tuviera que desarrollar un sistema en el que el nombre de usuario fuera una dirección de correo electrónico, no lo haría sensible a mayúsculas. Trabajaría en todos los casos con un sistema en minúsculas, sabiendo de antemano que ni estaría cumpliendo los estándares RFC (pero sí los “de facto”) y que un mínimo número de usuarios puede que tengan problemas en el registro en mi sistema web.
Simon Sinek has a simple but powerful model for inspirational leadership all starting with a golden circle and the question “Why?” His examples include Apple, Martin Luther King, and the Wright brothers …
Vía Hackers News llego a un artículo para principiantes de cómo (y cómo no) instalar Ruby on Rails (RoR) en un entorno Linux. A continación pego el artículo, con una discusión interesante, tanto en HN como en el propio blog:
Si usáis el CVS Git para la gestión de vuestros proyectos creo que os puede ser de ayuda la siguiente “hoja resumen” o “cheatsheet”, creada por Alexander Zeitler y publicada con licencia CC-by-sa 3.o.
Branding legend Marty Neumeier says that good product names have 7 characteristics. They should be distinctive, short, appropriate, easy to spell and pronounce, likable, extendable, and protectable.
Si aún no utilizas un lector RSS, ¿
