Una de las novedades introducidas en Tractis durante la última semana es la posibilidad de marcar contratos y plantillas como destacados. Esta funcionalidad te ofrece una forma fácil de obtener un acceso rápido para aquellos documentos que consideres importantes: contratos en los que estás trabajando, plantillas públicas a las que no quieres perderles la pista, contratos firmados que quieres tener bien localizados…

¿Cómo utilizo los destacados?

En los listados de contratos y plantillas aparecen iconos para representar el tipo de documento en la columna de la izquierda. Con solo hacer click en el icono este cambiará para mostrar una estrella y el documento quedará marcado como destacado.

Cuando ya tengas tus destacados podrás acceder rápidamente a ellos a través de los botones que aparecen en las páginas en de contratos y plantillas.

Mantente al día sobre tus destacados

Para completar la funcionalidad, te permitimos configurar tu página de alertas de forma que puedas estar al día sobre lo que sucede en tus contratos y plantillas destacados.

Como siempre, aceptamos comentarios, sugerencias y críticas

No te preocupe que la gente pueda robar tus ideas. Si tus ideas son medianamente buenas, tendrás que empujarlas por sus gargantas.

Howard Aiken, ingeniero principal del Harvard Mark I.

El viernes pasado sacamos a producción el nuevo sistema de alertas de Tractis. Este sistema te permite configurar qué eventos quieres se te notifiquen: nuevos comentarios en tus plantillas, nuevas firmas en un contrato importante, avisos de crédito bajo, etc.

Además, como principal novedad de el sistema, también podrás recibir las notificaciones por SMS, además de por e-mail y RSS.

Configuración de alertas

Configurar tus alertas es muy sencillo. Puedes especificar alertas a nivel de contrato, pudiendo especificar para cada contrato qué alertas recibir y cómo. Para ello no tienes más que ir a la sección de Alertas de ese contrato y hacer tu selección.

Aparte de configurar tus alertas contrato a contrato también puedes suscribirte a ellas a nivel general: nuevos comentarios en mis plantillas, nuevas firmas en mis contratos, etc. Para suscribirte a estas alertas no tienes más que acceder a tu página de Alertas del apartado de configuración.

Al final de esta página también podrás encontrar tendrás una lista con todas las alertas a las que te has suscrito en contratos específicos, pudiendo repasar todas tus suscripciones en un único sitio, sin necesidad de andar paseando por todos tus contratos.

Ventajas de las alertas por SMS

Los SMS son una buena vía para recibir alertas de forma rápida sin que necesites estar pendiente de otra cosa que no sea tener el móvil a mano. Se acabó el quedarse atado al ordenador pendiente de si la otra parte firma un contrato, o el comprobar el e-mail cada cinco minutos. Deja que Tractis te avise cuando las cosas estén listas y aprovecha mejor tu tiempo.

Esto está muy bien pero ¿cuánto cuestan los SMSs?

Hemos decidido lanzar el servicio sin ningún coste. Todo lo que necesitas es tener un teléfono móvil y completar el sencillo proceso de configuración

Una vez completado el proceso podrás empezar a recibir alertas por SMS.

Ahora mismo el servicio solo está disponible para teléfonos móviles en España (Telefónica, Vodafone y Orange), pero esperamos poder ampliarlo en el futuro a otros países.

Como siempre, estamos encantados de saber qué opináis sobre esta nueva funcionalidad.

Introducción

En posts anteriores hemos desgranado parte de los procesos que llevamos a cabo para poder validar las firmas electrónicas que se generan dentro de Tractis.

En este último post de la serie voy a concentrarme en los riesgos derivados de equivocarse en dicha validación, la importancia de las baterías de tests, para acabar centrándome en una de ellas: la batería de tests PKITS del NITS para validación de certificados.

Validar firmas electrónicas no es tarea para pusilánimes

Nuestro trabajo de desarrollo goza de una criticidad especial ya que se trata de implementar procesos donde se busca la preservación de datos e identidad de partes en procesos de firma.

Están en juego relaciones contractuales de compraventa, reclutamiento, control de calidad, operaciones financieras, suministro, inversión, partnerships o prestación de servicios, por poner unos pocos ejemplos. Contratos de los que dependen la operativa, reputación, estrategia, supervivencia financiera y, por qué negarlo, los “sueños” de las partes. Cada firma esconde muchas horas de trabajo y negociaciones previas y desdencadena consecuencias a posteriori con un impacto real y visible en la vida de personas y empresas.

Semejante responsabilidad es una carga enorme. Hay que ser especialmente rigurosos para poder asegurar que todo funciona como debería hacerlo y solo hay una manera de conseguirlo:

Tests, tests y más tests

Testear es un proceso clave en el desarrollo de software de calidad. El realizar un testeo riguroso y de calidad puede marcar la diferencia entre un producto excelente y otro mediocre y mal acabado.

El software que compone una infraestructura de firma digital no solo no escapa a estas apreciaciones sino que, dada su complejidad y criticidad, debe hacer especial énfasis en procesos de testeo.

Testear de principio a fín una infraestructura como la de Tractis es una tarea en estado de perfeccionamiento y mejora contínuos. Cada elemento de la infraestructura (Autoridad de Atributos -AA-, Autoridad de Sellado de Tiempo -TSA-, Archivo de Larga Duración -LTA-, etc) requiere distintos enfoques de testeo. Solo la Autoridad de Validación Semántica -SVA- incluye múltiples componentes: unos validan firmas criptográficamente, otros miran la adecuación de la firma del punto de vista sintáctico comprobando que la información contenida en la misma es suficiente y correcta … y, como no, componentes que validan el certificado o certificados que intervienen en la misma. Una infraestructura con múltiples elementos, cada elemento con varios componentes, cada componente con sus propia batería de tests.

Para ejemplificar uno de los procedimientos que hemos seguido a la hora de comprobar que nuestra infraestructura funciona de manera correcta, ilustraremos el testeo del componente de validación de certificados.

Validando al validador: Los tests PKITS del NIST

Implementar un validador de certificados no es tarea fácil. Por un lado tenemos una serie de excelentes documentos RFC que nos explicitan el comportamiento esperado exacto de este tipo de componentes. Por otro lado, no son documentos triviales de implementar y su análisis requiere una atención máxima al detalle.

Una vez desarrollado el software que plasma en código los algoritmos definidos en el RFC 3280, surge la pregunta interesante: ¿Lo hemos hecho bien?.

Hay multitud de situaciones descritas y casos particulares que una buena batería de tests de validación de certificados debería tener en cuenta para poder dar garantías suficientes de que el componente es robusto y consistente con la especificación del RFC. El construir esta batería requiere de un análisis minucioso de la especificación y de encontrar ejemplos y contraejemplos que validen que el software responde de manera coherente a todos los diferentes casos derivados de la casuística de las entradas. Afortunadamente existen baterías de este tipo ya diseñadas y disponibles de manera pública.

Una de estas baterías, la que la mayoría de los expertos consideran “la batería de tests definitiva en validación de certificados” por su excelente calidad, es la llamada PKITS que pone a disposición pública el NIST. El NIST o “National Institute of Standards and Technology” es la agencia del gobierno estadounidense dedicada a garantizar el cumplimiento de estándares y favorecer la interoperabilidad entre distintos fabricantes. Las pruebas PKITS diseñadas por la “NIST - Computer Security Division” y la NSA (Agencia de Seguridad Nacional) son utilizadas por las distintas administraciones del gobierno federal estadounidense como un método fiable para medir la calidad de los distintos despliegues PKI del gobierno. Dentro del PKITS, el caso que nos compete es la parte referente a “Path Validation Testing Program” diseñada para garantizar un cumplimiento exquisito de las especificaciones X.509 y RFC3280.

Nosotros llevamos a cabo este testeo como parte de las baterías de pruebas de nuestro backend de validación de firma y estamos orgulloso de anunciar que, desde la semana pasada:

Tractis supera satisfactoriamente la totalidad de tests que “PKITS - Path Validation Testing Programs” establece.

Esto no es sencillo. De hecho, no hay muchas implementaciones de validadores de certificados que pasen la totalidad de la casuística definida en PKITS. La superación de estos tests es el resultado de un trabajo duro durante los últimos dos años y nos otorga confianza de que estamos actuando diligentemente cuando prestamos servicios de firma digital a nuestros clientes.

Finalmente, quiero aprovechar para agradecer a David Cooper, Computer Scientist del NIST, por su valiosa ayuda a la hora de pulir las últimas aristas necesarias para superar el 100% de los tests y reiterar que PKITS es solo una pequeña parte (adecuación al RFC 3280) de una estrategia global de tests que incluye la validación de la adecuación a XAdES, DSS, RFC 3161 (cada uno merecedor de su propia serie de posts) y demás estándares empleados en la construcción del backend de Tractis.

Con este post termina la serie “Validación de firmas en Tractis”. Esperamos que haya sido de vuestro interés.

Introducción

En el primer post de esta serie dedicada a la “Validación de firmas en Tractis”, comentamos que el proceso de validar una firma es bastante complejo porque requiere la validación de numerosos elementos. Nos concentramos en explicar el más importante de ellos (pero no el único): la “validación del certificado con el que se realiza la firma”.

Explicamos:

1. Por qué debe validarse el certificado en el momento de la firma (si no validas el certificado utilizado para firmar, no te enterarás de si ha sido revocado, robado o falsificado).
2. Los principales fases para validar un certificado correctamente (1. construcción del path del certificado y 2. validación del path).
3. Los principales recursos que describen cuales son las comprobaciones y como deben realizarse (RFC3280).

Ahora que hemos descrito con cierto grado de detalle las operaciones a realizar para poder validar un certificado, en este segundo post, iremos un paso más allá. Describiremos en qué consiste “validar una firma”, los desafíos que supone y como una “Autoridad de Validación Semántica” responde a estos desafíos.

Validación de Firmas: La importancia del Sello de Tiempo

Para poder validar una firma electrónica necesitamos la firma en si, el documento firmado (en caso de que éste no este contenido como parte de ésta) y el momento del tiempo en el cual fue realizada la firma.

A vista de pájaro, una validación básica de firma require:

1. Validación criptográfica: validar la no alteración del contenido mediante algoritmos criptográficos de verificación de firma digital,
2. Validación de certificado: verificar el estado del certificado del firmante en el momento de la firma, y
3. Determinación del tiempo de la firma: conocer con el mayor grado de exactitud y certeza el tiempo en el cual fue realizada la firma.

No vamos a hablar del primer punto de validación criptográfica ya que intervienen algoritmos complejos que no aportan demasiado a un discurso de alto nivel como el que nos ocupa. Solo indicar que se persigue garantizar que el contenido no ha sido alterado. Asimismo, el proceso de validación de certificados ya lo describimos con un detalle razonable en el post anterior.

Vamos a centrarnos en el proceso de determinación del tiempo de firma, algo que puede llevarse a cabo de diferentes maneras pero en el que todas esas maneras tienen algo en común: alguien debe decirnos cuando ocurrió la firma. En nuestro caso, el tiempo de firma viene acotado por un “sello de tiempo” sobre la firma.

El sello de tiempo no es más que una firma (otra más) que protege el contenido sobre el que se aplica (en nuestro caso, la firma del contrato) y que además contiene un instante de tiempo. La conjunción de ambas cosas nos permite conocer de manera fidedigna cuando fué realizada la firma. Tractis realiza una validación de la firma justo después de firmar y añade un sello de tiempo para preservar ese instante.

Aunque quizás pueda parecer que no aporta demasiado al proceso de validación, esta coordenada temporal es clave. Nos permite averiguar si el certificado utilizado para firmar era válido en el momento de realización de la firma, independientemente del estado actual del certificado. En otras palabras, aunque nuestro certificado haya caducado o sido revocado hoy, las firmas realizadas con él hasta hoy (en que cambia de estado), deben ser consideradas válidas.

Dado que el sello de tiempo es una firma en sí misma, también debe ser validado aplicando los mismos criterios que aplicamos a cualquier otra firma.

En Infraestructura de Clave Pública (PKI), el ente encargado de realizar todas estas comprobaciones se denomina “Autoridad de Validación”. Todas las comprobaciones que hemos mencionado (validaciones criptográficas, de certificado y de sellos de tiempo) dan una idea de la complejidad de su tarea.

Desafíos: ¿Esta firma es válida?

Uno podría pensar que la pregunta de si una firma es válida o no se responde siempre con una afirmación absoluta. Decidir si la firma ha sido criptográficamente alterada se hace con un cálculo matemático que solo tiene dos posibles resultados: el contenido ha sido alterado o no ha sido alterado. ¿No es cierto?. Pues no, no es tan sencillo.

La respuesta sobre si una firma es válida o no puede variar según quien realice la comprobación.

Esto puede sonar chocante y sin sentido… ¿como puede una firma ser válida para mi pero invalida para el vecino si es la misma cosa y seguimos los mismos criterios y algoritmos de validación?. Pues puede y, de hecho, tiene todo el sentido ya que no todo el mundo tiene el mismo concepto de lo que es válido o no lo es.

Veamos un ejemplo: Imaginad que tenemos una misma Autoridad de Validación que da servicios a varias instituciones. En este escenario cualquier conjunto de firmas será válido o invalido para todos los usuarios. Imaginad ahora que uno de los clientes que consume los servicios de esa Autoridad de Validación solamente quiere aceptar una serie de certificados concretos (p.ej: solo certificados de Autoridades de Certificación alemanas) o solo una série de algoritmos (p.ej: claves más fuertes que supongan mayores garantías de integridad). Más aún, sigamos imaginando ahora que uno de los clientes de esa Autoridad de Validación requiere de certificados y algoritmos diferentes en función del proceso de contratación o la cuantía involucrada. Tiene sentido: un acuerdo por la compra de un CD no requiere las mismas garantías que un acuerdo por la compra de una empresa.

Aunque la Autoridad de Validación diga que la firma es válida desde el punto de vista técnico, no lo es desde el punto de vista del conjunto de reglas que el cliente ha definido. Estamos pasando de la “simple” firma de un mensaje criptográfico a “algo más” donde la validez depende de la naturaleza del contenido firmado.

Estamos añadiendo “semántica” a la validación.

Bienvenidos a Tractis: Validación Semántica de Firmas

Cuando decimos que una Autoridad de Validación es semántica, queremos decir que permite a sus usuarios crear diferentes tipos de reglas de validación para validar distintos tipos de documentos firmados, independientemente de la configuración por defecto de la que disponga el servicio en si.

Normalmente la validación suele darse mediante unos mecanismos técnicos estándares que suelen dar un resultado concreto para una solicitud de validación determinada. Es decir, muchas Autoridades de Validación actuales no pueden observar casos particulares dependiendo de quien solicite la validación.

Tractis da respuesta a los desafíos mencionados a través de nuestra “Autoridad de Validación Semántica” o “SVA”, uno de los componentes de la infraestructura back-end de Tractis. La SVA de Tractis se encarga tanto la validación técnica como de la validación semántica de cada firma. El que Tractis soporte certificados de diferentes Autoridades de Certificación de diversos paises no significa que nuestros clientes deban aceptarlas todas como válidas. Nosotros realizamos recomendaciones sobre los distintos grados de seguridad y garantía de cada método de firma pero nuestros usuarios conservan la libertad (y el poder) para decidir que consideran válido y que no para cada tipo de contrato.

Actualmente, el componente semántico de la Autoridad de Validación de Tractis está solo disponible para grandes cuentas pero, siguiendo la filosofía de Tractis de “todos disfrutan del mismo nivel de seguridad y funcionalidad”, pronto lo pondremos a disposición de todos los usuarios, particulares y pymes.

Como podeis imaginar, añadir semántica a la validación incorpora un nivel de complejidad (y utilidad) sin precedentes. Gestionar dicho servicio y garantizar su correcto funcionamiento se convierte en el auténtico desafío. Como lo conseguimos en Tractis es el tema del próximo, y último, post de esta serie.

–

Próximo post: Validación de firmas en Tractis (3): Validación a prueba de fallos.

Introducción

En Tractis ofrecemos un servicio web que permite a particulares y empresas firmar contratos 100% online y con la misma eficacia jurídica que la firma manuscrita. Para ello empleamos tecnologías de firma digital que garantizan la integridad del documento, la identidad de las partes y la no repudiación futura de los compromisos adquiridos por los firmantes.

Nuestra plataforma no sólo permite un firmado de contratos sin más, sino que antes de añadir cualquier firma al contrato la validamos para evitar cualquier tipo de irregularidad en el proceso de firma. El responsable de realizar este proceso en nuestro back-end es un elemento al que denominamos “Autoridad de Validación Semántica” (SVA o Semantic Validation Authority). La SVA de Tractis valida desde aspectos criptográficos a temporales y, por supuesto, valida que el certificado empleado para realizar la firma es apto para ello.

Como el proceso completo de validación de la firma es demasiado complejo para explicar en un solo post (personalmente diría incluso que es demasiado complejo, a secas), en este primer post nos centraremos en el proceso de validar el certificado con el cual se ha realizado la firma.

Validación de certificados

Para que exista “firma electrónica reconocida” (equivalente a firma manuscrita), la legislación europea no requiere que se valide el certificado electrónico con el que se realiza la firma en el mismo momento de la firma. Sin embargo, en Tractis siempre lo hacemos. No es ninguna tontería. Imaginad una empresa que entrega un certificado electrónico a un empleado para que firme contratos electrónicos en representación de la compañía. Ahora imaginad que esa empresa despide al empleado y revoca su certificado. Si se utilizasen herramientas de contratación online que no validan online el estado del certificado, el ex-empleado podría engañar a terceros y utilizar el certificado para firmar en nombre de la empresa ¡incluso a pesar de estar despedido!. Las pérdidas podrían ser cuantiosas. No en Tractis. En Tractis no se realiza ninguna firma electrónica reconocida sin antes validar online en tiempo real el estado del certificado. Esto es así para todos los certificados que admitimos, sean del país que sean. Y, ni siquiera haciendo esto, hemos terminado nuestro trabajo.

Mucha gente piensa que validar un certificado consiste simplemente en lo que hemos comentado: consultar, en el momento de la firma, el estado del certificado a la Autoridad de Certificación que lo emitió y averiguar si el certificado es válido y no ha sido revocado. Nada más lejos de la realidad. Validar un certificado de una manera ortodoxa no es algo sencillo. Validar que el certificado no este “expirado” o mirando una CRL o consultando un OCSP para ver si está “revocado” es sólo una pequeña parte del trabajo.

El proceso de validar un certificado con garantías suficientes es bastante mas complejo, ya que hay que tener en cuenta la validación de todos los elementos relacionados con el certificado como certificados de Autoridades de Certificación, listas de revocación (CRL) o mensajes OCSP que deben ser a su vez validados de manera análoga.

El porque de tener que validar todos estos componentes deriva de que el encargado de validar el certificado no suele ser el mismo que el emisor de dicho certificado. Nos encontramos entonces con que el validador debe confiar en la información emitida por un tercero para poder emitir un veredicto respecto al certificado a validar. No obstante, antes de poder utilizar esta información para poder emitir un veredicto, ésta debe ser validada. Debemos comprobar que nos hayamos ante información confiable: que no ha sido alterada y que es adecuada para efectuar la validación del certificado en el instante de tiempo en el cual éste debe ser validado. Y es que el momento en el cual se valida el certificado es un punto clave a la hora de efectuar todo este proceso ya que el componente temporal afecta enormemente al proceso de validación. No es lo mismo validar un certificado en el momento actual, que hace 5 años o que de aquí a 5 años.

Por ello, y por poner un ejemplo sencillo, en el caso de una firma no podemos simplemente validar el certificado en la actualidad sino que debemos determinar de manera fidedigna cuando fue realizada la firma y validar el certificado en ese momento. Veamos un ejemplo: si firmé mi hipoteca y al año siguiente me robaron mi e-ID (sea el que sea: DNIe español, beID belga, Cartão de Cidadão portugués, Carta d’dentitá elettronica italiana, Bürgerkarte austriaco, FINEID finlandés, ID-Card estonio…) y lo anulé, no me gustaria que todas las firmas que hice antes de ese momento (incluyendo mi hipoteca) sean consideradas a partir de ese momento como invalidas, ¿no?.

Aparte de las consideraciones ya comentadas hay además multitud de detalles críticos como la comprobación de longitud de paths, espacios de nombres admitidos, extensiones críticas aceptadas o no, firmas de la información de revocación, etc… que deben ser tenidos en cuenta.

Para simplificar, abstrayéndonos un poco de toda esta ingente cantidad de procesos que deben llevarse a cabo, el proceso de validación de un certificado se divide en dos grandes partes: (1) la construcción del path de certificación y (2) la validación del mismo.

La necesidad de construir un path… y validarlo

Para validar un certificado, ya sea como parte una validación de firma o validándolo de manera aislada (por ejemplo para logearse en un portal mediante el uso de TLS), es necesario contruir todo su “certification path“ y validarlo.

El concepto de “path” viene determinado por el como las Autoridades de Certificación emiten sus certificados. Cada certificado de entidad final (el que emiten a personas o entidades ) contiene una serie de atributos tales como “nombre”, “organización”… que hacen referencia al sujeto que es objeto de la emisión del mismo. Además, cada certificado incluye una clave pública que será empleada en el proceso de validación criptográfica de toda firma realizada con la clave privada asociada a ese certificado.

Este certificado es una representación off-line de estos datos en la que un tercero (tu banco, tu gobierno…) nos garantiza la veracidad de estos atributos para este individuo. Por ejemplo con la emisión de un certificado donde figure mi nombre, apellidos, empresa y DNI, la autoridad que emite el certificado garantiza que esos atributos son constituyentes de mi identidad y además los asocia a una clave pública.

Como hemos comentado un certificado no es más que un mensaje codificado según una serie de reglas establecidas, pero como es un método de transmisión de información off-line debe haber alguna manera de garantizar la autenticidad de los datos que figuran en el mismo. De esta necesidad de preservar la integridad de los datos viene el requerimiento de que todo certificado debe estar firmado por la autoridad de certificación que lo emite. Así, deberemos validar criptograficamente el certificado de entidad final para garantizar su autenticidad y no alteración, utilizando para ello la clave pública del certificado de la Autoridad de Certificación (CA) emisora.

Este certificado de CA emisora puede estar emitido a su vez por una CA de grado superior y esta por otra hasta llegar hasta la llamada “CA raíz”, un certificado de CA que esta emitido por el mismo y como tal esta firmado con su propia clave privada.

Para que todo el proceso sea consistente estos “certificados raíz” deben ser conocidos por el validador por medios fuera de banda. ¿Os suena el repositorio de certificados que Windows lleva para que os podáis conectar a servidores vía https sin que salgan advertencias de seguridad?, pues es algo así.

Más aún, una vez construido el path, este debe ser validado teniendo en cuenta un gran número de consideraciones relativas a restricciones sobre el mismo o validar el estado del certificado de entidad final así como de las CAs involucradas (sin contar la raíz) contra CRLs, OCSPs u otros métodos de comprobación del estado de la revocación.

Y aún hay más, CRLs y OCSPs son objetos firmados con lo cual para poder emplearlos y ser confiables deben ser validados criptográfica y sintácticamente así como validar el certificado con el cual han sido firmados de manera similar a la comentada para los de entidad final: construyendo su path y validándolo.

Como veis, en la validación de un certificado intervienen una serie de actores adicionales como CAs e información de revocación que debe ser tenida en cuenta, procesada y validada haciendo que la complejidad y el coste de validar un certificado explote.

Afortunadamente las normas RFC 3280 especifican de manera detallada como debe llevarse a cabo el proceso de validación del path de certificados. Así, este procedimiento queda detallado en un documento y todos los validadores que, como Tractis, dispongan de una implementación que respete RFC3280 validarán siguiendo el mismo conjunto de reglas.

Conclusiones

El proceso de validar una firma electrónica es un proceso complejo que se puede dividir en diferentes procesos complementarios que validan las diferentes partes de la firma: la criptográfica, la relativa al tiempo de firma … y, como una de las destacadas, la relativa a la validación del certificado con el que se realiza la firma.

Hemos descrito este proceso a vista de pájaro y de forma resumida pero con el suficiente grado de detalle como para demostrar que conocer el estado de un certificado de manera diligente es mucho más complicado que consultar a un servicio OCSP de estado de certificados o bien mirar las entradas de una CRL.

También hemos visto que, por suerte para los que construimos infraestructuras de este tipo, existen especificaciones de lo que debe y no debe hacerse en dicho procesos. Estas especificaciones hacen posible que dispongamos de implementaciones de validación coherentes, respetuosas con estándares abiertos e interoperables entre los diferentes fabricantes.

–

Próximo post: Validación de firmas en Tractis (2): Validación de firmas

Hola a todos,

Llevo un año y medio traduciendo el blog de Negonation de español a inglés para que puedas leer los pensamientos y opiniones de los colaboradores españoles. Después de pensarlo mucho, he decidido que ya no puedo dedicar tanto tiempo y esfuerzo para hacer bien este trabajo, así que este es mi post de despedida.

Me gustaría dar las gracias a David Blanco y a los demás colaboradores de Negonation por darme la oportunidad y el espacio y tiempo para aprender y madurar como traductor. He aprendido mucho sobre firmas electrónicas, autenticación y diseño y desarrollo de aplicaciones además de mejorar bastante mi español. Muchas gracias. Seguiré leyendo el blog y os deseo mucha suerte para el futuro.

Antes de despedirme, me gustaría compartir algunas opiniones sobre traducción. Primero tengo que confesar: No soy traductor profesional; soy programador. Tampoco hablo español como nativo. Entonces, cuando empecé a traducir el blog de Negonation, pensé que lo mas difícil sería entender los posts españoles, y tenía razón; por lo menos al principio. Pero pronto, mi nivel de español mejoró y empecé a darme cuenta de que el verdadero problema de traducción es uno de representación.

¿Que haces cuando una frase no tiene traducción directa al inglés? ¿Lo traduces palabra-por-palabra o representas el significado original del contenido? Por ejemplo, en español ‘tanto X como Y…’ significa ‘Both X and Y’ en inglés, pero si lo traduces literalmente sería ‘As much X as Y…’. Adivina cual usé al principio…

¿Y si el post original contiene algo que opinas que no está muy claro o puede estar expresado de una forma mejor? Yo creo que tienes que usar tu ‘artistic license’ aquí, pero la tienes que usar con cuidado porque sí, estas haciendo que la cosa esté mas clara, pero también estás bajando la calidad de la traducción. La gente quiere leer lo que escribió el autor original, no lo que tú crees que él debería haber escrito.

No es sorprendente que los posts más fácil de traducir fueran los que se trataban de conceptos de ordenadores. Sabía el vocabulario español y escribo documentos informáticos muy a menudo en inglés. Con diferencia, los posts más difíciles han sido los de temas legales. Conceptos difíciles, palabras que nunca había oído en español (¡y en algunos casos tampoco en inglés!) y, con todos mis respetos a los autores, algo en lo que tengo menos interés.

Espero que mis errores no te hayan impedido disfrutar de este blog y que hayas aprendido tanto como yo de cada uno de los posts.

Muchas gracias por seguir el blog y hasta la vista.

Kevin McCormack

Este Miércoles 16 presentaré Tractis en Suscipe.

Suscipe es un foro de emprendedores co-organizado por las asociaciones de antiguos alumnos de London Business School, Massachusetts Institute of Technology, y Stanford University en España, y la Asociación de ex-becarios de “la Caixa”, con la colaboración de la Escuela Técnica Superior de Ingenieros Industriales de la Universidad Politécnica de Madrid.

Este es el programa (pdf) del evento. Es gratuíto y puedes asistir solo a las partes que te interesen:

• 19:15: Proyecto innovador: Tractis.
• 20:00: Invitado especial: Angel Iglesias, fundador de Ikusi, una empresa española con más de 700 empleados y presente en más de 80 países.
• 21:15: Evento de networking.

Mi presentación se centrará más en el proyecto en sí, mientras que la de Angel Iglesias en su actividad y experiencia emprendedora. El lugar es la Sala C de la Escuela Técnica Superior de Ingenieros Industriales de Madrid (c/ José Gutierrez Abascal 2. Zona Paseo Castellana - Nuevos Ministerios).

Francisco Hernández, uno de los coordinadores de Suscipe, me contó ayer que ya hay 113 asistentes confirmados pero que aún queda sitio. Tanto si utilizas Tractis como si no, si estás montando tu propio proyecto o simplemente quieres compartir un rato con gente con ganas de cambiar el mundo, me encantará conocerte en persona.

Con bastante retraso, quiero anunciar los ganadores de la cuarta edición de los Premios Glider (Diciembre 2007).

Los Premios Glider son los premios que Negonation entrega a sus colaboradores más valiosos. La novedad de esta edición estriba en que todos los premios han sido decididos por los empleados (vs. votos de colaboradores en pasadas ediciones). Esto responde a una estrategia que seguimos desde mediados del año pasado con el objetivo de restringir el número de colaboradores y aumentar la intensidad de la colaboración con unos pocos.

El primer agraciado con un premio de 1.000 € ha sido José Luis Gordo Romero. José Gordo es un habitual de estos premios: ya ha recibido reconocimientos en pasadas ediciones y, en esta ocasión, ha vuelto a quedarse en primera posición. Por tanto, José Gordo se convierte en el primer colaborador en la historia de Tractis en repetir el título de “Glider Hacker” (la primera fue en la primera edición de los premios). Durante estos últimos meses (en realidad desde los inicios del proyecto), José nos ayuda de forma continuada en la administración de sistemas, configuración de servidores, certificados de servidor, gestión de DNSs, back-ups, etc. Es un auténtico placer trabajar con él. Una persona realmente profesional, competente y que hace honor a todos sus compromisos. ¡Tractis no sería lo mismo sin tí José!.

El segundo premio, también de 1.000 €, ha sido para Choan Gálvez. Conocimos a Choan gracias a Diego Lafuente, nuestro Director Creativo. Choan es un auténtico mago del javascript y el creador de Protomean, el editor de contratos que utilizamos en Tractis. Además de manejarse estupendamente en el (pobremente documentado) mundo del javascript, Choan es un enamorado de los cuentos breves y los juegos de tablero.

Aunque no ha recibido premio en metálico, merece una mención especial Tatiana Nubiola, nuestra gurú linguista, guardiana del libro de estilo y obsesionada del Diccionario de la Real Academia de la Lengua Española, responsable de muchas de las traducciones al inglés y elecciones de copy que ves en Tractis. Tatiana tiene el honor de ser el primer colabordor reconocido en los Glider que es (1) mujer, (2) vive fuera de España (New York para los curiosos) y (3) no programa una sola línea de código. Tatiana es la prueba de que no hace falta programar para ser un hacker.

¡Enhorabuena a los premiados!

Y disculpas por el retraso. Prometo postear antes la próxima vez

Y tenemos página de inicio nueva. Luego de dos semanas intensivas, al fin estrenamos la nueva forma de entrar y conocer Tractis. Todas las semanas estamos mejorando cada aspecto de la aplicación y, me muerdo la lengua por no decir las cosas que vienen.

Cómo empezó todo

Cuando salimos al aire con Tractis teníamos una página de inicio similar a la que tenemos ahora. Cuando digo similar, me refiero a que, tenía una organización de datos igual a la que podéis observar ahora: iniciar sesión, tour, etc.

En aquella época, Tractis era un proyecto cerrado, que sólo favorecía a un grupo de betatesters, e invitaba a cualquiera a serlo. Era una página de inicio a modo de trailer de lo que vendría después en agosto del 2007. Nuestra aplicación, que estaba creciendo tenía look and feel más oscuro que el actual, y era lo mejor que podíamos hacer para invitar a la gente a descubrir Tractis en aquel entonces, dado que el parque de DNI electrónicos era bajo en España.

Pero luego vino el lanzamiento del sitio, en su versión 1.0. Tractis ya dejó de ser un sitio beta, cerrado al público, y comenzamos a ofrecer la posibilidad de que la gente se registrara. Hicimos una refactoría total de toda la aplicación; nuevas secciones; nuevas convenciones; nuevo estilo gráfico, etc. Abrimos la aplicación de pi a pa para que todo el mundo pudiera descubrir, sin miramientos, la aplicación. Aprovechamos todo nuestro conocimiento, nuestra forma de programar estándar para que Google nos trajera una inmensa cantidad de visitantes, que se registraron y comenzaron a utilizar la aplicación, mayoritariamente, para compartir plantillas.

Si bien la cantidad de visitas subió notablemente, esto produjo un daño colateral que identificamos: la gente comenzó a pensar que Tractis era un sitio sólo para compartir plantillas. Lo cual es algo realmente falso: estamos especializados en firma electrónica, y además de integración de servicio de firma electrónica y comprobación de identidad en sitios de terceros y que la gente se enterara de esto de sorpresa no beneficiaba mucho.

Ahora que el DNIe está en auge, queríamos potenciar las herramientas de negocio que teníamos para que Tractis no se quedara sólo en una herramienta exclusiva de creación de plantillas. Diseñamos una página con funciones de contenido para dos casos de uso muy concretos. De esta forma podemos transmitir a nuestros usuarios nuevos más información sobre la funcionalidad principal de Tractis, sino que también otras cosas maravillosas: lector gratis, API, editor nuevo, firma digitales, etc.

Producción

El sketching de la aplicación, como todo, parte de la concepción del papel y boli. Hacemos muchos ejemplos con papel y boli para hacer el bosquejo inicial. Luego, todo el bosquejo (obra digna de movimiento abstracto) se pasa a PDF, con elementos de nuestro kit GUI que tanto aprovechamos para tener un panorama claro, con copy fantasía de la aplicación.

El código fue una parte dura, pero entretenida de cómo montar la nueva página. Utilizamos un slider bastante popular llamado Coda Slider. Nos vino al pelo y nos ahorró unas cuántas horas de desarrollo, y tuvimos, claro, que meter nuestras manos a fondo para que muchas de las cosas que no contemplaba el slider funcionara con el esquema de uso que planificamos para Tractis: casos de uso, diferentes cantidades de pestañas por casos, colores, contenidos, etc. El trabajo de código y puesta en marcha fue de aproximadamente 1 semana.

Otra parte importante, y que, en muchos casos, cuando hablamos de diseño y programación es el copy. Mucha gente, me incluyo, nos olvidamos de comentar esta esencial parte del desarrollo que hace del proyecto algo más sólido y con forma, de hecho, es algo tan vital para nosotros que cada nuevo desarrollo intentamos mejorar la forma de aprovechar un buen copy con el diseño y la programación para que nadie se sienta perdido en la aplicación. La nueva página de inicio además, necesita esto: una explicación clara de qué es Tractis, para qué sirve y las ventajas que uno gana al utilizarlo.

El resultado

Lo que hoy podréis apreciar al entrar a nuestra dirección es una página de inicio que tiene información producida exclusivamente para dos tipos de usuarios: los usuarios que no conocen Tractis y nuestros usuarios habituales. Cada caso cuenta con un set de información y herramientas exclusivas para cada necesidad.

Los usuarios no registrados podrán enterarse nuestra principal especialidad: una herramienta para hacer y firmar contratos online que puedes hacer validar en el mundo offline, además de la interesante promoción del lector de tarjetas inteligentes, registrarte con un clic, aprender más sobre la API de Tractis y más. Nuestro principal objetivo en este caso es que la gente sepa que es Tractis y se registre.

Los usuarios que ya son habituales en Tractis no necesitan ver todo esto, por ello, habilitamos una caja de inicio de sesión rápida y en el visor exponemos todas las cosas geniales que venimos desarrollando para que nuestros usuarios se conviertan en powerusers. Queremos que nuestros usuarios le saquen el jugo a toda la aplicación. Conociendo detalles de la API, utilizando el lector, conociendo nuestras tarifas, colaborando con Tractis y con futuras nuevas funcionalidades de la aplicación. Nuestro principal objetivo en este caso es que el usuario tenga a mano las cosas para iniciar sesión y aprenda de una forma cómoda las nuevas cosas que trae la plataforma.

Vuestra opinión

Seguimos abiertos a vuestras sugerencias, es más, suplicamos que nos envíen más, porque sin dudas nos vienen al pelo. Sabemos que no podemos contentar al 100% de la gente en todo, pero no desestimamos nunca una sugerencia vuestra. Es vital para una empresa que sus usuarios les realicen sugerencias, incluso las más alocadas. Para nosotros vuestra sugerencia, vuestros comentarios ya sean por el blog o bien, utilizando el enlace de “Feedback” de la aplicación nos da tremenda emoción.

¡Hasta el próximo anuncio!