Etiqueta: tecnología

Cómo administrar decenas (o cientos) de passwords y no morir en el intento

Hace unos días, en un grupo de guasap de excompañeros del secundario, uno de ellos (también informático) me pidió recomendación sobre qué password manager usar. Siguió un pequeño ida y vuelta sobre las cosas que uso donde la mayoría, con un bajo nivel de nerdez en sangre, se quedó afuera y, ante el pedido de que traduzca al castellano lo que estaba diciendo, decidí intentar hacerlo y ver si lo comparto con un público más amplio (como ser los 8 lectores de este blog).

Básicamente, un password manager es un programa que te permite administrar todas las claves que usás en distintos lugares y tenerlas guardadas todas juntas en un solo lugar protegido, obviamente, por una (única) clave (one key to rule them all). La (única) clave que protege a las demás, debe ser muy buena.

Digamos que un password manager es equivalente a cambiar los post-it que la mayoría de la gente pega al lado de la computadora para tener las claves a mano, por una libretita con todas las claves juntas metida adentro de una caja fuerte que siempre tenés a mano que se abre con una llave que llevás siempre en el bolsillo.

Ojo, no voy a hacer un análisis de las diferentes opciones que hay en el mercado sino decir cuáles son las que yo uso y cómo protejo mis claves.

Espóiler Alert

TL;DR: Yo uso, hoy en día, una combinación de tres o cuatro productos/servicios distintos para mantener mis claves:

NIUSFLASH (no uso más LastPass)

Al poco tiempo de escribir esta nota, LastPass decidió dar de baja el débito automático de mi cuenta y, al vencer la suscripción, me avisa que en 30 días termina mi «prueba gratis» y que si quería me podía suscribir por el TRIPLE de lo que estaba pagando anualmente (de 12 a 36 dólares estadounidenses anuales).

Me quejé a soporte (de LogMeIn, la empresa que compró LastPass) y me contestaron que el precio fue modificado para «reflejar nuestra inversión contínua en nuestra solución de gestión de claves líder en la industria».

Cuando el departamento de márketing se adueña del soporte, en general es un buen indicador de que conviene abandonar el servicio.

Por suerte, cuando escribía esto me había cruzado con Bitwarden que, por un lado, es de código abierto (es decir, podría hasta instalarlo en un servidor mío y modificarlo si quisiera), y por el otro, el servicio básico gratuito que ofrecen tiene todo lo que yo utilizaba de LastPass, sumado a la posibilidad de compartir algunas claves con otra (única) persona.

Con las instrucciones para migrar de LastPass a Bitwarden del sitio de este último pude pasar todo lo que tenía, dí de baja LastPass y no lo extraño en lo más mínimo.

Sitios y servicios web

… y aplicaciones móviles (que son versiones para móviles de lo mismo)

En principio hay que tener en cuenta que NO HAY QUE USAR LA MISMA CONTRASEÑA EN DISTINTOS SITIOS.

Hace muchos años, yo tenía un algoritmo (mental) para generar contraseñas distintas en cada sitio, pero eso servía cuando los mismos no te pedían que la cambies con alguna frecuencia (cosa que no es una buena práctica y, por suerte, muchos la han abandonado) y cuando no pasaba que cada sitio tenía su particular visión de qué caracteres debe contener una contraseña segura: algunos lugares te piden que uses números y letras; otros que, además haya al menos una mayúscula y una minúscula; otros, que pongas al menos un caracter «especial» (aunque no se ponen de acuerdo en qué caracteres especiales son válidos o no), etc.

Este tipo de requisitos y el deterioro mental, junto con la proliferación descontrolada de servicios en línea, me hicieron, hace como 10 años, complementar mi listadito encriptado de claves (más sobre esto más adelante) con un administrador de claves en línea.

En ese momento mi requerimiento era algo que me permita mantener en forma centralizada y segura mis claves para servicios en línea y que funcionara en Windows y Linux. En aquella época sólo encontré dos productos que me parecían razonables: 1password y LastPass. Como el primero sólo tenía un free trial de un mes o algo así y la versión básica del último era gratis, opté por LastPass.

¿Por qué no guardar las claves en el navegador? en aquel entonces, los navegadores no te permitían sincronizar configuraciones (y claves guardadas) entre distintas instancias y yo usaba tres o cuatro computadoras distintas, amén de que nunca me parecieron suficientemente confiables las medidas de seguridad que tenían (aún poniéndoles una «master password» ). Por otra parte, siempre usé más de un navegador, con lo cual, también tenía que mantener la sincronización entre distintos navegadores aunque estuviera en la misma máquina.

¿Cómo se usa LastPass?

LastPass es un servicio que mantiene tus claves guardadas en un sitio centralizado al que podés acceder desde la web. Ellos lo llaman la «bóveda LastPass» .

Para registrarte, usá una cuenta de mail personal (no del laburo: los laburos, y sus direcciones de mail, van y vienen). Yo en particular uso una cuenta de gmail. Lo otro que tenés que poner es, obviamente, una password. Esta password tiene que ser muy buena ya que es la password que protege todas tus passwords. Más aún no te la podés olvidar, porque no existe un mecanismo para recuperarla (y eso es bueno). Lo que te da LastPass es la posibilidad de guardar un ayudamemoria que le podés pedir si no te acordás la password. Ojo que cualquiera puede ver este ayudamemoria así que poner «la fecha de cumpleaños de la abuela Carlota» no sirve. Tiene que ser algo que te sirva a vos y solamente a vos para acordarte de qué fue lo que pusiste como password (por ejemplo, si usás como clave las 4 últimas palabras al revés -de atrás para adelante- de la tercera estrofa del himno nacional, podrías poner algo como «HN tercera 4 vesre» como ayudamemoria).

Una vez que te registraste en LastPass, lo que tenés que hacer es instalar el plugin en cada navegador que uses. Esto sirve para incorporar la funcionalidad de LastPass a tu navegador. Hay plugins para Firefox, Chrome/Chromium, Explorer, Edge, Safari y Opera, para Windows, Mac y Linux. También hay aplicaciones móviles para IOS y Android, que se bajan de los respectivos stores.

Cada vez que instalás el plugin en un navegador, te va a pedir que pongas la dirección de mail con la que te registraste y la clave. Lo mismo en el móvil. En el celular (al menos en Android) te va a pedir permiso para poder rellenar los campos usuario/clave no sólo en el navegador, sino también en las aplicaciones. Normalmente, las apps están relacionadas con el nombre de la página web del mismo servicio para un navegador, de modo que si guardo mi clave en la página de féisbuc en el plugin del navegador de la compu, cuando abra la app de féisbuc en el móvil, si no tengo la sesión abierta, me va a ofrecer poner el usuario/clave que guardé en LastPass desde el navegador.

El menú contextual (el del botón derecho) de LastPass, te da la posibilidad de generarte una clave «buena» cada vez que lo necesites (por ejemplo, cuando te registrás en una página nueva). Tenés la opción de elegir si querés que tenga mayúsculas, minúsculas, dígitos y caracteres especiales. No importa que no sea fácil de recordar porque igual te la va a guardar LastPass.

LastPass tiene otras funcionalidades que yo nunca usé, pero que pueden ser interesantes: autollenado de formularios, notas, etc. Hay más información en el sitio de LastPass.

¿Qué es lo que me gusta de LastPass?

Las claves y toda tu información se guardan en los servidores de LastPass encriptados con la clave que vos elegiste. El proceso de encriptado se realiza en tu dispositivo (en tu navegador o en tu móvil). Tu clave maestra nunca viaja por la red (ni se guarda en los servidores de LastPass), es por eso que no existe un mecanismo para recuperar la clave. Si hubiese un mecanismo para recuperar la clave maestra eso quiere decir que esa clave debería estar guardada en servidores de LastPass (con alguna protección bajo control de LastPass). Si un atacante lograra ingresar al servidor y desbaratar el mecanismo, tendría acceso al mecanismo de recuperación de claves.

Acá hay algo más de información acerca de cómo funciona.


Lo otro que me gusta es que la empresa ha sido abierta respecto de los incidentes de seguridad que ha tenido. Es decir, al menos dos o tres veces detectaron intrusiones o comportamiento anómalo en sus servidores y, después de resolver el problema, se comunicaron con sus usuarios explicando qué pasó y qué recomendaban hacer (en un caso extremo, si mal no recuerdo llegaron a deshabilitar el uso automático del servicio, forzándote a solicitar la rehabilitación reconfirmando tu dirección de mail registrada y luego obligándote a cambiar la clave maestra).

Información sobre incidentes publicada por la misma empresa

Datos de tarjetas de crédito, cuentas bancarias, sitios bancarios y de pagos, billeteras de criptomonedas

En realidad, KeePass es el primer password manager que usé. Básicamente es una pequeña base de datos con distintos campos (clave/usuario/notas/etc) que se mantiene en un único archivo y ese archivo se encripta con una única password que obviamente tiene que ser muy buena ya que es la password que protege todas tus passwords (esto me suena haberlo leído más arriba).

KeePass fue mi primera «libretita de passwords anotadas» para no olvidarlas.

La diferencia principal con LastPass es que esto es un archivito que está en tu computadora, no en un servicio que dependa de alguien más. Por un lado, creo que cuando empecé a usarlo (hace más de 15 años) no había ningún servicio del estilo de LastPass y, por otro lado, yo sólo tenía ahí anotadas unas pocas claves. Lo usaba más para tener anotados los números de las tarjetas de crédito, datos de cuentas bancarias, claves para recuperación billeteras de bitcoin u otras criptomonedas, etc (de hecho, sigo teniendo esa información en KeePass).

Hace tiempo que sincronizo mi único archivo KeePass usando un servicio parecido a DropBox (o Google Drive o One Drive) pero que opero yo mismo. A los fines prácticos, si tenés cualquiera de estos servicios, lo podés usar para tener tu archivo KeePass sincronizado entre distintas computadoras y tu celular.

Si bien KeePass2 funciona en Linux (usando Mono que es una implementación abierta del framework .NET), hace un tiempo utilizo KeePassXC que es una reescritura (también abierta) multiplataforma que corre nativamente en Linux, Mac y Windows.

En mi teléfono, antes usaba KeePassDroid y ahora estoy usando la versión offline del KeePass2Android que me gusta más.

En la página de downloads de KeePass hay links a todas estas versiones y otras (para iPhone, Blackberry, etc).

Segundo factor de autenticación (2fA)

Es una buena práctica de seguridad combinar múltiples factores de autenticación distintos para validar a un usuario de un servicio.

Un factor de autenticación es algo que si vos sos quien decís ser, se lo podés demostrar a quien te lo requiere para tener acceso a un recurso (un sistema, un edificio, un país, etc).

Los factores de autenticación más usados son:

  • Algo que sabés (por ejemplo, una clave secreta o el nombre de tu primera maestra de primaria)
  • Algo que tenés (como ser tu teléfono, una tarjeta magnética, un dispositivo USB, etc)
  • Algo que sos (una característica física tuya -biométrica- como tu huella digital, el iris de tu ojo, tu forma característica de tipear en el teclado)
  • Un lugar donde estás (un punto geográfico identificado por el GPS, o conectado desde determinada red)

El primer factor de autenticación más usado es, obviamente, una clave secreta (algo que sabés), nuestra vieja, conocida y odiada password.


El segundo factor de autenticación (2fa) más usado es, generalmente, algo que tenés. Últimamente es común que los bancos te den un pequeño dispositivo (token) con un botón y un display que muestra unos números que van cambiando periódicamente (cada 20, 30 o 60 segundos). El banco es posible que te solicite ese número para transferir dinero a otra cuenta. La empresa es posible que te pida ese número para ingresar a los sistemas corporativos (o quizás, para pasar a un sector del edificio). Existen versiones más complejas que te piden un PIN para ver el display y algunos que se conectan vía USB y permiten enviar el código automáticamente sin tipearlo.

Con la popularización de los teléfonos móviles, ahora es muy común utilizarlos como segundo factor de autenticación. Algunos sitios de pagos en línea pueden enviarte un mensaje vía SMS cuando intentás ingresar o hacer un pago.

Ahora que la mayoría de los móviles son «inteligentes» (ponele), se pueden utilizar aplicaciones para validar que el que intenta ingresar a un sitio o servicio es el poseedor del teléfono. Por ejemplo, si intentás ingresar en un servicio de Google en una computadora que no es la tuya con la cuenta que tenés registrada en tu teléfono Android y la clave correcta, te va a llegar una notificación al móvil preguntándote si vos estás intentando ingresar. Si le contentás que sí (en el teléfono) te va a dejar entrar automáticamente en la computadora.

Ahora bien, como hay muchos servicios que no son operados por el fabricante del sistema operativo de tu teléfono, hay aplicaciones que utilizan un estándar llamado TOTP que genera números únicos a partir de una clave secreta inicial (generada automáticamente) combinada con la hora actual. Estas aplicaciones a veces se llaman «soft token» y son cada vez más comunes en los bancos (en general se incluyen en la aplicación propia del banco que se utiliza en el teléfono).

Pero lo más común son las aplicaciones TOTP genéricas, que funcionan con cualquier servicio que permite la sincronización abierta de los parámetros TOTP, usualmente a través de un código QR. La más conocida es Google Authenticator (también para iPhone), pero hay muchas otras: FreeOTP, Microsoft Authenticator, etc.

El problema con estas aplicaciones es el mismo que tenés con cualquier factor de autenticación del tipo «algo que tenés». ¿Qué pasa si te lo roban o lo perdés? Más allá de que puedas tener el uso bloqueado (es decir, que podrías confiar en que no lo usen porque el teléfono se auto-bloquea/borra o el token requiere de un PIN), si lo perdés no lo podés usar. En general todos los sitios tienen algún mecanismo para entrar sin ese factor en particular y regenerarlo, por ejemplo, usando mensajes SMS (para lo cual tenés que, al menos, recuperar la línea telefónica), o con un correo electrónico o algún otro factor de autenticación. Pero después de haber perdido el teléfono (o de haber borrado la aplicación del mismo), tenés que regenerar todos los 2fa de cada uno de los sitios.

Después de usar Google Authenticator, descubrí una aplicación de 2fa hermosa que se llama Authy.

Lo que diferencia a Authy de los demás 2fa es que tiene dos facilidades (relacionadas) que te hacen la vida más fácil: backup en la nube y uso en múltiples dispositivos.

El backup en la nube funciona en forma análoga a lo que hace LastPass: encripta la información de los parámetros y datos secretos de cada uno de los sitios para los que tenés configurado 2fa en tu dispositivo y los sube encriptados a los servidores de Authy.

A su vez, teniendo estos datos en la nube, los podés recuperar desde otro dispositivo (una tablet o, inclusive, una computadora, ya sea portátil o de escritorio) y mantenerlos sincronizados (es decir, si agregás un nuevo servicio en un dispositivo, se sincroniza, a través de la nube, con los demás).

De este modo podés tener Authy configurado y funcionando al mismo tiempo en tu móvil y tu tablet. Si te roban el teléfono, podés seguir usando los sitios con 2fa con la tablet. Más aún, cuando te comprás un teléfono nuevo, recuperás todas las configuraciones. Esto no ocurre con Google Authenticator; si perdés el teléfono, cuando instalás el nuevo tenés que ingresar a cada uno de los servicios y generar un nuevo 2fa en el teléfono nuevo para cada uno.

Cuando empecé a escribir este post, descubrí que LastPass ahora tiene un nuevo servicio llamado LastPass Authenticator que funcionaría en forma similar a Authy, tengo que ver si funciona de modo tal de no quedarme afuera si no tengo el 2fa para poder abrir el 2fa.

Conclusión

Yo utilizo KeePass, LastPass Bitwarden y Authy para mantener mis claves y datos confidenciales seguros.

Supongo que con un poco menos de paranoia, podría tener todo unificado en LastPass: es decir, comenzar a usar LastPass Authenticator en lugar de Authy e incorporar a LastPass toda la información que de un modo u otro significa guita y que hoy tengo en KeePass (a esto último soy realmente reticente).

Espero que le sirva a alguien… si no, al menos queda pensar que este blog se transmite en electrones reciclables.

Acerca del momento en que se anuncian los cambios en los husos horarios

Matt Johnson escribió en abril de 2016 On the Timing of Time Zone Changes en su blog y me autorizó a traducirlo y publicarlo.

¿Qué tienen en común Turquía, Chile, Rusia, Venezuela, Azerbaiyán, Corea del Norte y Haití? ¡Caos con el cambio de hora!

No, no es el remate de un chiste. Es un problema grave en realidad. El mayor problema con los husos horarios no es que existan, ni que haya horas de ahorro de energía en verano. Si no que estas cambien en forma completamente desorganizada. Déjenme explicar.

Primero hay que comprender que desde una perspectiva global, uno podría pensar que los husos horarios del mundo deberían ser manejados por una entidad internacional relativamente neutra, como la división UIT de Naciones Unidas, o quizás la UAI. Sin embargo, cada uno de los husos horarios del mundo se controlan, en realidad, desde una perspectiva local. Cada nación tiene el derecho soberano para decidir acerca de la hora local en las tierras bajo su jurisdicción. Esto incluye tanto la diferencia con la Hora Universal (UT), como las reglas que definen los cambios durante el año para el ahorro de energía, si deciden hacerlos.

Esto no es un problema en sí mismo y estoy absolutamente de acuerdo con que los países deberían poder hacer lo que quieran con los relojes adentro de sus fronteras. Sin embargo, una y otra vez, nos topamos con el mismo problema, que es que estos cambios se hacen sin una antelación suficientemente amplia. Todos los países mencionados más arriba han hecho esto recientemente, junto con muchos otros.

Es crucial que cuando los gobiernos hacen cambios a sus husos horarios o las reglas para cambiar la hora durante un período, permitan un tiempo suficiente para que la tecnología se adecue, haga pruebas a los cambios y publique y distribuya las actualizaciones. Luego hay que tener en cuenta que los individuos no siempre actualizan sus sistemas instantáneamente. Es muy común que una actualización de husos horarios esté disponible por semanas o meses antes de que el usuario final la instale efectivamente.

Caso de estudio – Turquía:

Tomemos a Turquía como ejemplo. En 2015 el gobierno decidió que sería una buena idea retrasar dos semanas la finalización del cambio de hora para ahorro de energía para permitir más horas de luz diurna durante las elecciones. Movieron la fecha de finalización de DST (cambio de hora para ahorro de energía) del 25 de octubre al 8 de noviembre.

  • Lo primero que se supo acerca de esto fue a través de una nota periodística no oficial publicada el 8 de septiembre, alrededor de 6 semanas antes de que se debieran cambiar los relojes. Sin embargo, el artículo recién fue registrado por la comunidad TZ alrededor del 19 de septiembre. Es difícil basarse solamente en notas periodísticas, ya que muchas veces son confusos o contienen errores. Unas pocas palabras de un político a un periodista simplemente no son suficiente.
  • El 29 de septiembre, una agencia del gobierno también reportó el cambio. Todavía no era completamente oficial, ya que no hacía referencia a ningún tipo de decreto o legislación. Pero era suficiente para convencer a algunos en la comunidad TZ de que era real y por lo tanto se comenzó a configurar un cambio en la IANA TZ database y se publicó unos días después, el 1° de octubre.
  • El anuncio definitivo del gobierno finalmente salió el 4 de octubre cuando se publicó en la Gaceta Oficial. Esto es alrededor de tres semanas de antelación oficial de la propuesta de cambio.
  • Muchos proveedores de tecnología, incluyendo a los grandes como Apple, Google y Oracle, tomaron los datos de IANA y los publicaron a través de sus propios canales. Por ejemplo, Apple lo lanzó para dispositivos iPhone y iPad con la actualización iOS 9.1 el 21 de octubre, dejando sólo 3 días para que los usuarios instalen la actualización para evitar que sus relojes cambien la hora el día incorrecto.
  • Para Microsoft Windows que sigue un procedimiento levemente diferente y requiere de un mayor grado de confirmación, se hizo un anuncio el 9 de octubre y se publicó la actualización el 20 de octubre.
  • En algunos casos, la fecha se pasó por completo, como en el caso de pytz – la popular biblioteca de manejo de husos horarios para el lenguaje Python, que publicó su versión 2015.7 el 26 de octubre.

Entonces ¿cuál fue el resultado? Bueno, citando a la BBC:

Turcos confundidos se preguntan «¿qué hora es?» luego de que los relojes automáticos desafiaran una decisión del gobierno para posponer el cambio de hora estacional.

O como reportó el IBT:

Millones de turcos se despertaron en una mañana confusa el domingo … ya que teléfonos inteligentes, tabletas, y computadoras habían cambiado la hora automáticamente del mismo modo que otros países en el huso horario de Europa Occidental (Eastern European Time zone), aun cuando Turquía retrasó el cambio de hora para dos semanas más adelante.

Como se podrán imaginar, esto tuvo en la votación exactamente el efecto opuesto a lo que el gobierno había intentado lograr. Sin embargo, podrían haberlo previsto ya que ¡pasó exactamente lo mismo el año anterior! como lo reportó la Agencia de Noticias Independientes de los Balcanes en 2014:

Una increíble confusión para 52,9 millones de votantes turcos fue causada por la decisión del gobierno turco de posponer por un día el cambio de hora que se aplica en todo el mundo, cuando los relojes se adelantan una hora. La razón para posponer la aplicación de la hora de verano según el gobierno de Erdogan, fue para facilitar la administración de las elecciones, pero nadie predijo el factor de la «nueva tecnología». Todos los teléfonos inteligentes de los ciudadanos turcos cambiaron la hora automáticamente, resultando en miles de votantes que fueron a a votar más temprano y tuvieron que esperar hasta una hora para poder hacerlo.

Problemas similares ocurrieron en computadoras que no habían bajado una nueva versión del software. También hubo problemas en el sistema de despacho de equipajes en el aeropuerto de Estambul ya que el sistema cambió la hora automáticamente, ignorando los planes del gobierno y, como resultado, el equipaje fue enviado a los pasajeros con grandes demoras. También hubo problemas con muchos vuelos ya que los pasajeros confundían el horario de partida.

¿Qué hay con el resto del mundo?

No sólo Turquía no aprendió de sus propios errores, otros países alrededor del mundo tampoco aprendieron de la experiencia y continúan teniendo este problema. ¿Recuerdan la lista que enumeré antes? Veámosla más de cerca:

  • Chile estuvo en «DST permanente» durante 2015, pero el 13 de marzo de 2016, el gobierno anunció que volverían a la hora estándar a partir del 15 de mayo de 2016 (2 meses de antelación).

  • Rusia tenía 11 husos horarios diferentes, desde UTC+02 hasta UTC+12, con una historia compleja de cambios en los límites entre ellas.

    Para 2016, seis regiones cambiaron sus husos horarios el 27 de marzo de 2016. Cada una de estas regiones tuvo su propia ley para hacer efectivo el cambio. Una fue firmada el 30 de diciembre (12 semanas de antelación), lo cual es razonable. Sin embrgo, las otras fueron firmadas o bien el 15 de febrero (6 semanas de antelación) o bien el 9 de marzo (2 semanas de antelación).

    Otras dos regiones tenían la legislación pendiente durante este período, una de las cuales recién la aprobó el 5 de abril, de la cual la fecha de vigencia se extendió hasta el 24 de abril (3 semanas de antelación). La otra todavía está esperando la firma final del Presidente, lo que se espera que ocurra en los próximos días, tiene fecha de vigencia al 29 de mayo (4 semanas de antelación). (Actualización: La ley se firmó el 26 de abril).

  • Venezuela estuvo en UTC-04:30 desde 2007, pero el gobierno decidió hace poco que retornaría a UTC-04 el 1° de mayo. El cambio se anunció el 15 de abril, el anuncio se convirtió en oficial el 18 de abril al ser publicado en la Gaceta Oficial del país (2 semanas de antelación).

  • Azerbaiyán canceló el cambio de hora permanentemente en 2016. La cancelación se haría el 27 de marzo pero recién se anunció el 17 de marzo (10 días de antelación).

  • Corea del Norte cambió de UTC-09 a UTC-08:30 el 15 de agosto de 2015. El cambio fue anunciado el 7 de agosto (8 días de antelación).

  • Haití canceló el cambio de hora al menos durante el año calendario 2016. Estaba programado para el 13 de marzo, pero el 12 de marzo (¡sólo 1 día de antelación!) el gobierno publicó un comunicado de prensa cancelándolo.

Otros problemas con los tiempos

Mientras todos los cambios descritos conllevan un cierto grado de sorpresa, hay algunas partes del mundo que simplemente no hacen ninguna programación anticipada para el cambio de hora.

Fiyi es una de esas zonas. Tuvo DST todos los años desde 2009. Sin embargo, cada año, el gobierno hace un anuncio indicando en qué fecha comienza y termina. Es levemente diferente cada año y no queda claro exactamente cuándo el gobierno tomará la decisión, o qué hacer ante la ausencia de un anuncio. Sería mucho más simple si decidieran hacerlo con una programación regular y sólo hacer anuncios cuando haya desvíos respecto de dicha programación.

Otro lugar así es Marruecos, donde la programación del primer inicio y el último fin del DST están definidos adecuadamente, pero cada año, desde 2012 hay un «período de suspensión del DST», de modo que DST termine antes del comienzo de ramadán y se restaure en algún momento luego de la finalización. Esto no sólo significa que los relojes deben cambiarse cuatro veces por año calendario, si no también que nadie sabe bien cuándo son las dos transiciones del medio hasta que el gobierno hace un anuncio. Parte de la razón de esto es que las fechas de ramadán están basadas en las fases observadas de la luna. Sin embargo, mi opinión personal es que aún así deberían fijar las transiciones de DST a un calendario prefijado, aun si comienza antes de ramadán y termina algún tiempo después. La imprevisibilidad de las fechas hace que sea demasiado difícil saber qué hora es en Marruecos a menos que estés realmente allí. (De hecho, Egipto también hizo lo mismo, pero sólo en 2010 y 2014).

Recomendaciones a los gobiernos del mundo

Primero, debo enfatizar que estas son mis recomendaciones personales. No hablo en nombre mi gobierno, de mi empleador, o de la comunidad TZ. Estas recomendaciones están basadas en años de experiencia trabajando con husos horarios en computación, y en la observación de hechos reales.

Si vas a hacer cambios en tu(s) huso(s) horario(s), ya sea para la distancia de tu hora estándar desde UTC, o la puesta en funcionamiento o desactivación del cambio de hora para el ahorro de energía, o para las fechas en que los cambios de hora ocurren, entonces, por favor, hacé todo lo siguiente:

  1. Da un aviso con una antelación importante, preferiblemente no menos de 6 meses. Un año o más sería aún mejor.
  2. Proveé ese aviso a través de un decreto oficial de gobierno o una ley. Publicá la ley y disponibilizala a través de un sitio web oficial del gobierno.
  3. Asegurate de incluir los detalles precisos del cambio, incluyendo la fecha y la hora del día en que el mismo debe hacerse efectivo. Por ejemplo, decí «los relojes avanzarán 30 minutos el 1° de abril a la 01:00 hora local». No digas simplemente «la hora va a cambiar en abril». Además, si el cambio sólo afecta una región particular de tu país, por favor, especificá las áreas exactas que son afectadas.
  4. Notificá a tus ciudadanos a través de comunicados de prensa y los medios de noticias, pero no cuentes sólo con esto para comunicar el cambio. El decreto o ley oficial debería estar por encima de cualquier declaración hecha a la prensa.
  5. Enviá notificaciones a la comunidad TZ. Para hacer esto, sólo tenés que mandar un mail a tz@iana.org que es la dirección de la lista de discusión tz. El mail debería contener un URL para el anuncio publicado en un sitio web oficial del gobierno.
  6. Si se aborta la decisión de realizar el cambio, por favor da aviso de esto también con mucha anticipación.

Seguir estos lineamientos te asegura que tu cambio sea observado por la tecnología, incluyendo computadoras, teléfonos celulares y otros dispositivos.

Recomendaciones para desarrolladores de software

  1. No trates de inventar tu propio sistema de husos horarios ni pongas una configuración de zonas manualmente en tu aplicación.
  2. Utilizá los recursos de tu plataforma o biblioteca de desarrollo para hacer conversiones de husos horarios. No intentes codificar las reglas vos mismo.
  3. No te bases únicamente en diferencias fijas desde UTC, ni hagas ninguna suposición sobre el cambio de hora para el ahorro de energía de día (daylight saving time) para un huso horario en particular.
  4. Estate al tanto de las actualizaciones de los husos horarios. Asegurate de saber como mantenerlos actualizados utilizando los mecanismos de tu plataforma o biblioteca.
  5. Suscribite a la lista de correo de anuncios de TZ, así sabés cuando está disponible cada actulización de los datos.
  6. Si sabés de un cambio que está por ocurrir en un huso horario en un área en particular que difiere de la información conocida actualmente, o si tenés otras preguntas acerca del husos horarios en computación, unite a la lista de correo electrónico de discusión de TZ.
  7. Usá timeanddate.com para validar cualquier suposición que tengas acerca de los husos horarios para una región en particular. La precisión de este sitio en particular ha sido bien establecida y sus propietarios participan en la comunidad TZ.
  8. Para Windows, .NET y otros productos de Microsoft, seguí el canal de noticias de este sitio para saber cuándo están disponibles las actualizaciones de la plataforma. (Aunque deberías preferir los husos horarios de IANA cuando sea posible, aun si implica que tenés que utilizar una biblioteca para hacerlo).

Addendum personal

Esto lo escribo yo, Mariano Absatz y no Matt Johnson, con lo cual, las críticas y quejas a esta sección deberán dirigirse directamente a mí.

Pienso que si Matt hubiese escrito esta nota a fines de 2008 el mayor ejemplo de torpezas cometidas, habría sido la Argentina en lugar de Turquía, ya que los cambios que se hicieron tanto en el verano 2007/2008 como los que no se hicieron en octubre de 2008 son un muestrario de todos los errores posibles de ser cometidos.

Para información al respecto ver las notas que escribí en ese entonces:

DreamHost migra de Debian a Ubuntu

La semana pasada recibí un mail de DreamHost (donde tengo alojada esta página y algunas otras) avisándome que el servidor donde está alojada mi cuenta se iba a actualizar a Ubuntu 12.04.

DreamHost es un proveedor de hosting compartido muy barato (cuanto más lo usás, más barato es ya que tiene un precio fijo de alrededor de US$9 por mes y no tiene límites en cuanto a cantidad de dominios, cuentas de mail, bases de datos, espacio en disco, etc). Una de las cosas que siempre me gustó es que tienen una política bastante abierta en cuanto a problemas generalizados en su sitio DreamHost Status y que los servidores tenían instalado Debian (que era la distribución que yo usaba) y te daban acceso a un shell y no sólo a través de FTP.

Dada la cantidad de servers que tiene DreamHost (entiendo que son decenas de miles), los upgrades de los sistemas operativos de cada uno de estos servidores (que, a su vez, tienen varios cientos de usuarios cada uno) es algo que encaran con bastante cuidado.

Yo recuerdo el upgrade de Debian 3.1 (sarge) a Debian 4.0 (etch) que fue el primero que me tocó vivir y que se hizo bastante tiempo después del release original de etch. Luego hubo otros upgrades a los que les presté menos antención.

La sorpresa este fin de semana fue que en lugar de avisarme que hacían el upgrade de Debian 6.0 (squeeze) a Debian 4.0 (wheezy), el upgrade era a Ubuntu 12.04 (Precise Pangolin).

From Debian To UbuntuMe puse a revisar el blog de DreamHost y encontré esta entrada de hace más de un año donde explican los motivos del cambio.

Uno de los problemas que tiene Debian es que su ciclo de lanzamientos (release cycle) es irregular y el lanzamiento se hace «cuando está listo». El otro problema (y el más grave para DreamHost es que una vez que sale una nueva versión de Debian, la versión anterior tiene soporte durante alrededor de un año.

Por el contrario, Ubuntu tiene un ciclo regular de lanzamiento de versiones cada seis meses (en abril y octubre de cada año) y, si bien el tiempo de soporte de una versión «común» es de sólo nueve meses luego de publicada, cada dos años (en abril de los años pares) se publica una versión que se llama de Soporte por un largo período (Long Term Support – LTS). Ubuntu garantiza el soporte de cada release LTS por cinco años desde el lanzamiento, con lo cual, una vez que sale una nueva versión LTS, la versión anterior todavía tiene una vida útil con soporte por tres años más. Esto le brinda a DreamHost un período largo y previsible para hacer los upgrades en forma pausada y controlada.

De hecho cuando el 14 de septiembre de 2014 comenzaron las migraciones de Debian 6.0 a Ubuntu 12.04, ya existía una nueva versión 14.04 LTS (Trusty Tahr), sin embargo, la versión que DreamHost tiene probada (porque empezó a hacerlo a mediados de 2013) es la 12.04.

El domingo pasado se produjo la actualización de mi host y, a propósito, dejé una terminal abierta con un par de comandos significativos el domingo a la tarde:


baby@dellores:~ $ ssh upson.dreamhost.com
                         
  _  _ _ __ ___ ___ _ _  
 | || | '_ (_-</ _ \ ' \ 
  \_,_| .__/__/\___/_||_|
      |_|                
 Welcome to upson.dreamhost.com

Any malicious and/or unauthorized activity is strictly forbidden.
All activity may be logged by DreamHost Web Hosting.

baby@upson:~ $ w
 13:19:28 up 209 days, 26 min,  1 user,  load average: 3.17, 5.78, 7.80
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
baby@upson:~ $ cat /etc/issue
Debian GNU/Linux 6.0 \n \l

baby@upson:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 6.0.6 (squeeze)
Release:	6.0.6
Codename:	squeeze
baby@upson:~ $ uname -a
Linux upson 2.6.32.45-grsec-2.2.2-r3 #8 SMP Mon Oct 10 13:33:17 PDT 2011 x86_64 GNU/Linux
baby@upson:~ $ 
Broadcast message from root@upson (Sun Oct  5 20:42:19 2014):

The system is going down for reboot NOW!
Connection to upson.dreamhost.com closed by remote host.
Connection to upson.dreamhost.com closed.

y el lunes a la mañana volví a conectarme y probé los mismos comandos:

baby@dellores:~ $ ssh upson.dreamhost.com
                                   
                                   
 m   m  mmmm    mmm    mmm   m mm  
 #   #  #" "#  #   "  #" "#  #"  # 
 #   #  #   #   """m  #   #  #   # 
 "mm"#  ##m#"  "mmm"  "#m#"  #   # 
        #                          
        "                          

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

baby@upson:~ $ w
 09:24:32 up  8:03,  1 user,  load average: 5.28, 5.06, 5.05
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
baby@upson:~ $ cat /etc/issue
Ubuntu 12.04.5 LTS \n \l

baby@upson:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 12.04.5 LTS
Release:	12.04
Codename:	precise
baby@upson:~ $ uname -a
Linux upson 3.2.61-grsec-modsign #1 SMP Tue Aug 12 09:58:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
baby@upson:~ $

En principio todo lo razonable funciona OK. Tuve (como con cada upgrade) algún problema con la wiki que instalé a mano y que es afectada por los upgrades de Python (esto me pasaba también con los upgrades de Debian), pero supongo que lo arreglaré en estos días.

¿Pásguord? ¿Guat pásguord?

Aprovecho que mi amigo Mauricio me conminó a escribir algo por él utilizando el clásico método del halago en un comentario de féisbuc para revivir este blog con un articulito corto y conciso. password security

La pregunta es ¿cómo elegir una buena password? Si uno no está utilizando ninguna ayuda tecnológica para guardar las claves que uno utiliza en distintos lugares como KeePass, LastPass o 1Password (cosa que recomiendo fervientemente, pero es tema para otro artículo), las passwords deberían ser fáciles para uno de recordar (y tipear) y difíciles de adivinar para una computadora que podría tener alguna información sobre vos.

Sin hacer ni remotamente un análisis serio sobre el tema, valga decir que, en principio, cuanto más larga es una clave, más difícil es de adivinar por una computadora, al menos utilizando un mecanismo de fuerza bruta (esto es, probar a lo bestia combinaciones de caracteres hasta dar con uno que funcione).

¿Cómo adivina una clave una computadora?

Si bien hay varias formas, el método más simple para una computadora para adivinar claves es aprovecharse de la velocidad de cálculo de la computadora y utilizar lo que se llama mecanismos de fuerza bruta.

En su forma más básica sería ir probando en orden:

  • A
  • AA
  • AB
  • AC
  • AD
  • …
  • AZ
  • B
  • BA
  • BB
  • ..

Eventualmente, va a encontrar todas las combinaciones posibles. Podría empezar en «AAAAAAAA» suponiendo que la longitud mínima es ocho caracteres. Con este método, utilizado en forma pura queda claro que, cuanto más larga es nuestra clave, más difícil es de descubrir.

Con una ayudita del atacado

En general el mecanismo de fuerza bruta puro casi no se utiliza o se deja como último recurso, ya que la gente tiende a utilizar palabras comunes o datos más o menos personales.

Posiblemente lo peor que uno pueda hacer es utilizar una palabra común como password ya que, por más larga que sea, lo más posible es que esté en un diccionario, ya sea «gastroenterologo», «prestidigitation», «Иллюзионист» o «טראַפּעז» y la computadora puede probar con todas las palabras de todos los diccionarios que tenga, rápidamente.

Muchas computadoras cuentan, además, con información que nosotros les dimos, ya sea directa o indirectamente, consciente o inconscientemente como ser, nuestra fecha de nacimiento, nuestro aniversario de bodas, nuestro número de documento, los nombres de nuestros hijos, mascotas, cónyuges, amantes, padres, primos, etc.

Una clave más larga que…

Una primera opción sería poner claves muy largas pero que nos sean fáciles de recordar, como ser un par de versos de una canción o una poesía que nos gusta, una línea de un personaje en una película, etcétera, por ejemplo: «Muchacha ojos de papel, no corras mas, quedate hasta el dia» o «Me parecio ver un lindo gatito, Es cierto! es cierto! He visto un lindo gatito».

Una condición para poder utilizar este tipo de claves es ser un buen tipista, como su servidor, ya que si uno no fue a la Pitman y sólo tipea con dos dedos buscando durante dos segundos la mitad de las letras en el teclado, ingresar la clave va a ser una tortura. Por otra parte, aun tipeando treinta palabras por minuto o más, si la clave se utiliza con cierta frecuencia o se debe ingresar en un dispositivo móvil con un teclado virtual en una pequeña pantalla que no se presta a la velocidad, termina siendo también una tortura.

En mi caso, yo utilizo estas claves muy largas para guardar otras claves dentro de KeePass o para guardar las claves privadas que me dan acceso desde mi computadora a otras sin tipear la clave, es decir, que una clave muy larga tipeada una vez, me da acceso a un montón de lugares sin volver a tipear una clave durante una sesión.

Cortala un poco, querés

Otra posibilidad, para no desgastar tanto los dedos es utilizar una clave más corta (sin exagerar, en principio una clave jamás debería tener menos de ocho o diez caracteres) es utilizar el mismo mecanismo de memoria, pero abreviarlo como proponía Mauricio en su comentario, poniendo sólo las letras iniciales de esas palabras. Así nuestros ejemplos podrían pasar a ser «Modp,nc+,qhed» y «Mpv1lg_Ec!ec!hv1lg». Notar que estas claves, si bien tienen una longitud más corta que las otras, sólo pueden ser atacadas con un mecanismo de fuerza bruta en el que las «ayudas» que pueda tener dicho mecanismo que vimos más arriba como ser: buscar palabras comunes de un diccionario primero, o utilizar datos significativos si se sabe algo de ustedes como fecha de nacimiento, aniversarios, números de documentos o nombres de las mascotas; serían inútiles.

Qué teclas usar (y cuáles no)

Conviene que la clave tenga una combinación de letras mayúsculas y minúsculas, números y quizás algun símbolo (como un punto, un espacio en blanco, un guión, etc). En algunos casos, hay sitios de internet que nos obligan a utilizar esto; cada vez es más común que si la clave no tiene al menos una letra mayúscula, una letra minúscula, un dígito numérico y al menos ocho caracteres, el sitio no la acepte cuando la tratamos de crear.

Dicho esto, hay caracteres que es conveniente evitar ya que no todos los sistemas los interpretan igual: las letras con acento, la eñe, los símbolos de apertura interrogación y admiración y otros que no están entre los que son comunes a todos los idiomas.

El problema con estos caracteres es que si bien existe y normalmente se utiliza un estándar internacional que soporta todos los caracteres utilizados en todos los idiomas en uso, no siempre esto está bien configurado en los servidores y en los clientes, y la posibilidad de que en algún momento tengamos que tipear la clave en una computadora, tableta o teléfono que no esté bien configurado y en consecuencia no podamos ingresar la misma correctamente es motivo suficiente para evitarlos.

Una lista razonable de los caracteres que conviene usar en una password es:

  • Todas las letras mayúsculas y minúsculas del alfabeto inglés (o, si preferimos no hacer referencia a otro idioma, del alfabeto español sin la eñe)
  • Los diez dígitos del 0 al 9
  • El punto, la coma, punto y coma, dos puntos, paréntesis, corchetes, llaves, guión bajo, signos más, menos e igual, barras diagonales y vertical, asterisco, porcentaje, numeral, signo pesos, arroba, signo de admiración e interrogación que cierra (no el que abre), signos de menor y mayor, el símbolo ampersand y el espacio en blanco

Hay que tener cuidado con las comillas dobles y simples (ya que, a veces se transforman en comillas orientadas, que diferencian la que abre de la que cierra), los guiones, que a veces se transforman en guión «ancho» o doble, etc.

Finalmente se terminó haciendo un poco largo, pero espero que la nota todavía sea legible por cualquiera.

Hot patches

Ok, agrego algo que parece relacionado con el sexo en el título, una foto engañosa y ya tengo su atención ¿no?. Bueno, lamento desilusionarlos, pero no se trata de eso.
Hot patches

La semana pasada, me crucé en twitter con el Ksplice . Un producto/servicio que permite aplicar parches de seguridad al kernel de linux sin rebootear el equipo.

La información que aparece a primera vista en el sitio es un poco muy marketinera (bueno, al nivel de márketing que se puede llegar si estamos hablando del kernel de un sistema operativo y no de una aplicación para usuarios finales), pero, por suerte, navegando un poco se encuentra fácilmente un paper presentado en 2009 en una conferencia de la ACM/SIGOPS (que todavía estoy leyendo).

Si bien Ksplice cuesta entre US$3 y US$4 por server por mes, para las versiones desktop de Ubuntu y para Fedora, el servicio es gratuito, así que lo instalé en mi Ubuntu Desktop.

Se instaló un “chequeador de updates” (en python) que corre una vez al día via cron, un daemon “Ksplice Uptrack Manager” que interactúa visualmente (en forma similar al “Update Manager” de Ubuntu), un repositorio apt-get para las actualizaciones y algunas cosas más.

Ayer finalmente apareció un update de seguridad en el kernel de mi Ubuntu, el Update Manager lo instaló pero no me pidió rebootear, con lo cual en mi compu seguía corriendo el kernel anterior (con las vulnerabilidades).

Ksplice Uptrack Manager antes de aplicar el updateHoy a la mañana, cuando llegué, el Ksplice Uptarck Manager me avisó que tenía 4 parches de seguridad para aplicarle a mi kernel (los tres nombrados en el Ubuntu Security Notice USN-1023-1 y uno más) mediante un signo de admiración sobre su iconito en el system tray.

Simplemente apreté el botón Install all updates y los mismos se instalaron sin ningún inconveniente. Ksplice Uptrack Manager antes de aplicar el update

Revisé y el kernel que estaba corriendo era el viejo, sin embargo, el mismo tiene aplicados los parches de seguridad del nuevo kernel.

La próxima vez que rebootee, se cargará automáticamente el nuevo kernel, pero, mientras tanto, funcionalmente, es como si ya estuviera instalado.

Lo seguiré probando algún tiempo, pero tengo la sospecha de que, especialmente para los servidores, vale la pena aún pagar cuatro dólares mensuales por server para no tener que estar rebooteando los mismos cada vez que sale un parche de seguridad para el kernel.

Y después de QZZ-999 ¿qué?

Mi amigo Mauricio se preguntaba hace veinte días ¿qué se acabará primero, las direcciones IPv4 o las patentes argentinas?

Se acaban las IPs

Parece que en uno o dos años finalmente llegará el tan preanunciado fin de las direcciones IPv4 de internet (ya hace más de 15 años que “se acaba en los próximos 5 años“, pero desde hace poco, parece que “se acaba el año que viene“).

OK, es un espacio finito, fue planeado hace casi 30 años cuando no sólo a nadie se le ocurriría pensar que podía haber una computadora (o más) en cada hogar… mucho menos se les podía ocurrir que gran parte de la humanidad tendría teléfonos móviles personales y que estos también tendrían asiganda una dirección IP.

Dentro de todo, y con no pocos malabarismos de por medio, el espacio de direcciones IPv4 se la habrá por 30 años si llegamos a septiembre de 2011.

La solución

La única solución viable parece ser migrar a IPv6 que se comenzó a diseñar alrededor de 1993 y se publicó en 1998. Entre otros cambios, el más significativo es que utiliza direcciones de 128 bits en lugar de 32 bits como IPv4.

Si bien desde su concepción, IPv6 se planteó con un plan de migración, la misma ha sido lenta y, a medida que se comience a forzar debido al agotamiento de las direcciones IPv4, será dolorosa.

Se acaban las patentes

PatenteAhora bien, las “nuevas“ patentes de los automotores en Argentina debutaron en enero de 1995 y ya le quedan sólo 3 ó 4 (a lo sumo 5) años más de vida.

Para colmo, hay que reconocer que en 1994 debería haber sido más previsible el crecimiento del parque automotor argentino en 20 años de lo que en 1981 podría haber sido el crecimiento de internet (que de hecho, no existía ni se llamaba así en esa época) en 30.

El sistema de patentes en Argentina consiste en tres letras seguidas de tres números. Como se utiliza el alfabeto inglés (26 letras, sin eñe), esto da un total teórico de 17.576.000 de patentes únicas (26 3 x 10 3).

Fuera de los “autos mellizos“ los números de patente no se reutilizan aun cuando un vehículo sea completamente destruido y dado de baja legalmente.

Algunos números

Más aún, las patentes que comienzan con la letra “R“ hasta “Z“ se reservaron para repatentar vehículos que ya habían sido patentados hasta diciembre de 1994. Estas son 6.084.000 (9 × 26 2 x 10 3).

Con esto sólo quedan, para autos patentados por primera vez a partir de 1995, las que comienzan con la letra “A“ hasta “Q“, un total de 11.492.000 patentes (17 × 26 2 x 10 3).

A mediados de 2010 habían pasado 15 años y medio y se habían utilizado las patentes que comienzan desde la “A“ hasta la “I“ que son 6.084.000 (9 × 26 2 x 10 3). Sólo quedaban 5.408.000 (desde la “J“ que ya se está utilizando hasta la “Q“, 8 × 26 2 x 10 3).

Si bien esto no parece tan poco, hay que tener en cuenta que los primeros 8 de esos 15 años, la venta de automotores tenía un ritmo muy inferior al actual, incluyendo la crisis de 2001. De hecho, al principio, una letra de comienzo de patente duraba alrededor de un año y medio, a veces más. Ahora se están consumiendo en el orden de dos letras o más por año.

Yo sospecho que si no se frena ni se dispara significativamente la venta de automotores en Argentina, el esquema actual de patentes se agotará a mediados de 2014… no falta mucho… son justo 20 años desde que se creó el esquema.

Me acota Marcelo (en facebook) que actualmente se están patentando en el orden de 600.000 vehículos por año (más o menos “una letra inicial“ por año: 26 2 x 10 3 serían 676.000), con lo cual arañaríamos el 2020 con suerte.

Al menos “la pegaron“ con la reserva para repatentamiento de automotores viejos. Creo que van por la “Y“ y no creo que se repatente mucho más. Los autos viejos que siguen circulando con las viejas placas de una letra y seis o siete números ya es difícil que alguien se tome el trabajo de repatentarlos.

Una modesta propuesta de solución

A diferencia de los complejos mecanismos para migrar el protocolo básico de comunicaciones en una red global de computadoras sin una entidad única de control (aunque sí de asignación de direcciones), hace unos años, cuando se me ocurrió que se acabarían pronto las patentes se me ocurrió un sistema simple y elegante para resolverlo.

Si bien no es brillante, vaya aquí mi pequeño aporte a la DNRPA

Mi idea es agregar una letra más al principio de la patente, de modo tal que las nuevas patentes sean de cuatro letras y tres dígitos.

Esto da un total teórico de 456.976.000 patentes únicas (26 4 x 10 3).

Si bien esto va a requerir una adecuación de los sistemas que utiliza la DNRPA (para que quepa la nueva primera letra), ese será casi el único cambio ya que no será necesario repatentar los automotores que tengan una patente del sistema actual (tres letras y tres dígitos).

¿Cómo es esto? considerando que todas las patentes que sólo tienen tres letras son precedidas por una letra A tácita. Esto es, consideramos la letra A con la misma funcionalidad que el número 0. De este modo, si en 2020 veo una patente “de las viejas“ como ser BBY 965, la consideraré como ABBY 965.

De este modo, y manteniendo la reserva de patentes para repatentar los vehículos del sistema anterior a 1995, la patente que vendrá luego de la última del sistema actual (QZZ 999, o también AQZZ 999) será la BAAA 000.

Las patentes entre ARAA 000 y AZZZ 999 corresponden a vehículos con patentes anteriores a 1995 que fueron o serán repatentados.

La ventaja de este sistema es que es relativamente barato de implementar y, una vez que estén adecuados los sistemas se puede comenzar a utilizar inmediatamente y sin desperdiciar patentes válidas.

De hecho, si se terminara de implementar, digamos, a mediados de 2012, quizás la patente siguiente a MZZ 999 puede ser directamente ANAA 000.

Otras mejoras posibles

Siempre manteniendo la simplicidad de implementación, se me ocurren otras mejoras complementarias (no para incrementar la cantidad de patentes posibles si no para mejorar algún otro aspecto):

  • Cambiar la tipografía: La tipografía cuadradota de las patentes actuales, amén de que puedan ser estéticamente más lindas o más feas que las anteriores tiene varios problemas. En particular, hay muchas letras que se confunden a mediana distancia (ejemplo, la O con la D y con la Q). Esto no ocurría en las patentes que había hasta 1994, con una tipografía mucho más redondeada y con la rayita de la Q mucho más notable.
  • Cambiar el indicador de patente duplicada, triplicada o cuadruplicada (hoy una pequeña D, T o C entre las letras y los dígitos) por un número (y que podría comenzar en 1 o 0 para la duplicada e ir incrementándose).

¿Qué más se les ocurre que se pueda mejorar sin que sea complejo?

¿Qué celu me compro?

El sábado perdí (o me robaron) mi vieja Palm Treo 680… si bien ahora ando con una igual prestada, estoy pensando seriamente en comprarme un teléfono nuevo… el problema es que no sé qué teléfono comprarme.

De hecho, no estoy seguro de conseguir un teléfono con todos los chiches que quiero (no digo necesito, porque no es cierto).

Me gustaría que tenga:
Nokia 1100

  • Android 2.1 (o más nuevo)
  • Teclado físico QWERTY (no me llevo bien con los teclados en pantalla, ni siquiera con el del iPhone que se supone que es de lo mejorcito)
  • Pantalla multitouch de 3.5” o más de buena resolución (800×480 en adelante)
  • GSM/GPRS/EDGE cuatribanda (850/1900 + 900/1800)(uno siempre tiene la esperanza de poder irse de vacaciones a Europa)
  • 3G (UMTS 850/1900/2100)
  • En tren de pedir, también podría tener 3.5G (HSDPA/HSUPA), pero con 3G por ahora me arreglo
  • Wifi
  • GPS
  • Bluetooth con perfil A2DP (estéreo)
  • Lector de tarjeta de memoria extraible (microSD o similar) que soporte tarjetas de 16Gb o más
  • Camara de fotos/video decente con flash (no tiene que ser un sustituto de una cámara dedicada, pero tiene que poder sacar una foto más o menos decente)
  • USB (poder conectarse a una compu en modo USB esclavo como si fuera un pendrive, sin necesidad de drivers en la compu)
  • Plug estándar para headset estéreo (así lo uso para escuchar música)
  • Estaría bueno que también tenga FM, pero puedo vivir sin eso :-)
  • … continuará…

¿Alguien conoce teléfonos con estas características?… lo tengo que usar con Movistar, pero preferiría que no esté lockeado al proveedor.

Más sobre el dispositivo del “sexto sentido” del Media Lab de MIT

Hoy TED publicó una nueva charla de Pranav Mistry sobre el dispositivo del que comentábamos la semana pasada.

Lamentablemente (al menos por ahora), los subtítulos sólo están disponibles en inglés:

Pranav Mistry: The thrilling potential of SixthSense technology

Para muestra, baste un botón…

Ayer comentaba acerca de TEDxBuenosAires.

Para que vean el nivel de las conferencias TED miren lo que comenta Pattie Maes del Media Lab del MIT acerca de las nuevas intefaces de usuario (o “¡Comete esta, Minority Report!):

La charla es de febrero de 2009 y está disponible en el sitio de TED para bajarla (tanto el audio como el video) ya que esta, como todas las charlas de TED están disponibles con una licencia Creative Commons que permite redistribuirla tal cual en forma no comercial haciendo referencia a la fuente.

TEDx Buenos Aires… se develó el misterio

Finalmente, luego de unos meses de lo que podríamos llamar teasers y preanuncios 2.0, con acciones en LinkedIn, Facebook, Twitter (quizás en alguna otra también), se anunció oficialmente la realización de TEDx Buenos Aires el 8 de abril en la Rural.

Para los que no lo saben, TED es una organización que realiza anualmente conferencias (TEDTalks) en Estados Unidos e Inglaterra (y ahora también en India).

Las mejores conferencias se publican en video en el sitio TED.com con una licencia Creative Commons que permite su utilización y redistribución en forma gratuita.

Las conferencias TEDx son eventos “tipo TED“, organizados para distintas comunidades, ya sea por afinidad geográfica, organizacional u otra. Si bien los eventos son con una licencia de TED, los mismos son responsabilidad de sus organizadores.

En este contexto es que se organiza TEDx Buenos Aires, organizado por Santiago Bilinkis y un equipo (que parece un All Stars), ya tiene varios oradores confirmados, entre ellos Adrián Paenza, Alberto Kornblihtt, Manu Ginobili, Roberto Guareschi y Luis Pescetti.

Como podrán ver, la diversidad es uno de los aspectos más interesantes en estas conferencias… espero ansiosamente el 8 de abril de 2010 para asistir.