En busca de un formato para las guías prácticas: CodeLab

Siempre ocurre lo mismo.

Cuando me dispongo a crear algún tipo de material didáctico, como una guía práctica, ronda la misma pregunta en mi cabeza: ¿En qué formato la realizo?

Puede parecer una pregunta trivial, quizás deba centrarme únicamente en el contenido, pero la realidad es que no lo es.

Por un lado, me interesa que el formato perdure lo máximo posible. Crear el material conlleva un tiempo y esfuerzo que ya no recuperarás, por lo que sería una pena hacerlo con una herramienta propietaria, que dependa de un servicio en la nube, y sobre la que no tienes ningún control. Aunque sean herramientas que se promocionan por todas partes y que estén de moda en el ámbito educativo. Quizás el resultado sea muy atractivo pero… ¿Depender de los intereses de una empresa para seguir accediendo a mi material? No, gracias. Por cierto, este argumento también incluye que sea fácil de cambiar y mantener en el futuro… Las guías prácticas en el ámbito de la informática tardan muy poquito en quedarse obsoletas.

Por otro lado, el formato, bajo mi punto de vista, debe ser atractivo, adaptable a todo tipo de pantallas y de fácil navegación a través del mismo. Al fin y al cabo, si conseguimos que el alumnado quiera pasar tiempo en el contenido, probablemente se acercarán más a nuestro objetivo de aprendizaje.

Hasta ahora, me he decantado por crear las guías con Markdown y generar una página HTML del mismo. Puedes comprobar el resultado en esta guía que adapté sobre WireGuard. Así, he estado cumpliendo con los principios que más favorecen al creador del contenido: formato perdurable y fácil de mantener. Ahora… Atractivo, lo que se dice atractivo, no es. Fácil de navegar a través del mismo… Bueno, tiene una tabla de contenidos, pero no me parecía suficiente.

Así que me puse a investigar al respecto. De lo que he encontrado, me ha gustado mucho cómo crean guías prácticas en Apple y en Google. Por cierto, sospechosamente parecidas. Pero difícil de replicar. Hasta que di con los CodeLabs de Google. Y eso sí me convenció. Fácil de navegar y seguir, con secciones para no tener demasiado contenido a la vez en la página y adaptable a cualquier tipo de pantalla. Incluso permite al alumnado notificar de errores en la guía. Ahora solo falta que pueda replicarlo fácilmente, con un formato que perdure y fácil de mantener.

Y existe. Resulta que hay una comunidad de voluntarios que han creado una herramienta capaz de generar un sitio estático con una guía en formato CodeLab partiendo de un archivo Markdown. Y ahora la guía sobre WireGuard luce así. Creo que estaréis de acuerdo con que la mejora es muy notable.

Como siempre, cuando os cuento algo no lo hago sin un objetivo. En este caso hay dos.

El primero, es que si conocéis herramientas similares que cumplan estos requisitos básicos y sean útiles para crear guías prácticas o material didáctico similar, sabéis que me interesa que me lo contéis.

El segundo objetivo es enseñaros a vosotros también a crear estos CodeLabs si os ha gustado el formato. Para ello, he creado un CodeLab sobre la creación de un CodeLab. Únicamente es una adaptación del original creado por Marc DiPasquale, al que desde aquí le doy las gracias por permitirme adaptarlo al castellano.

Estoy deseando ver qué es lo próximo que vais a crear.

Private Relay: ¿La solución definitiva para el anonimato en internet?

El pasado 7 de junio, en la WWDC (WorldWide Developer Conference) anual, Apple presentó las novedades en sus sistemas operativos. Una de ellas fue Private Relay.

Añadamos antes un poco de contexto (puedes saltártelo si tienes nociones básicas de redes). Cuando navegamos por internet, lo hacemos identificados con una dirección llamada IP. Esta IP es necesaria para que, cuando hagamos una solicitud a una página web, la respuesta pueda volver a nuestro dispositivo. Además, para conocer la IP de la página web que queremos visitar tenemos que preguntársela a otro servidor (esto es una petición DNS). Al final del proceso, tanto nuestra IP como la página web que vamos a visitar es conocida por:

• Nuestro proveedor de servicios de internet (ISP).
• El servidor DNS que procesa la petición.
• El servidor de la página web que visitamos.
• Cualquier otro intermediario en la red.

Además, la dirección IP puede usarse en ocasiones para conocer tu ubicación. Al menos, si usamos HTTPS el contenido de esa conexión sí que estará cifrado. Pero solo con esos dos datos, nuestro ISP puede bloquearnos y registrar el acceso a determinadas páginas, el DNS también puede tener nuestro historial de navegación y el servidor del sitio web puede compartir la información de nuestras consultas con terceros, creando perfiles comerciales mucho más personalizados de lo que le gustaría a nuestra privacidad. Algunas soluciones disponibles a este problema:

• DNS sobre HTTPS. Muchos navegadores modernos y routers permiten cifrar las consultas al servidor DNS. Esto permite que nuestro ISP no vea esa consulta (aunque sí la que hacemos posteriormente al sitio web), aunque el servidor DNS sí que podría registrarla. Los servidores DNS que ofrecen este servicio dan su palabrita de que no almacenan ninguna información que pueda perjudicar a la privacidad.
• Usar un Proxy. Consiste en utilizar un servidor intermediario para navegar por internet. Cualquier consulta que hagamos pasará por el proxy. Esto únicamente oculta nuestra IP al servidor del sitio web, pero no a nuestro ISP y por supuesto tampoco al dueño del proxy.
• Usar una VPN. Las redes privadas virtuales o VPN se diseñaron para permitir a trabajadores remotos usar los recursos locales de una empresa como si físicamente se encontrasen en ella. Crean un túnel cifrado a través de internet entre el dispositivo de una persona y el servidor VPN. Esto oculta el tráfico a nuestro ISP, pero no al dueño del servidor VPN.
• Usar TOR. Con un navegador especial podemos cifrar nuestras comunicaciones con varias capas, a costa de una conexión más lenta. No obstante, es posible identificar con un análisis más o menos profundo quién está detrás de esas comunicaciones.

Volvamos a Private Relay. Hay que tener en cuenta que este servicio se centra en ocultar el conjunto de nuestra dirección IP y sitio web que visitamos, para que absolutamente nadie (ni ISP, ni servidor del sitio web, ni Apple, ni intermediarios) conozcan nuestro historial de navegación. No obstante, no protege las consultas DNS, por lo que habría que combinarlo con DoH (consultas DNS cifradas sobre HTTPS) o similar. En el caso de los dispositivos de Apple, en la WWDC de 2020 se emitió una sesión hablando sobre ese tema.

Por ahora no he encontrado demasiada sobre el funcionamiento técnico de Private Relay. En este post voy a contaros lo que se sabe al respecto hasta el momento y cuál es mi interpretación. Exponemos primero los hechos y después pasamos a las opiniones.

La información técnica proporcionada por Apple podemos encontrarla en la sesión Apple’s privacy pillars in focus disponible públicamente. Voy a realizar una traducción libre de la misma usando imágenes del vídeo.

Los pilares del servicio Private Relay son:

• Todas las conexiones están cifradas.
• Tu dirección IP ya no te identifica.
• La localización exacta de tu dirección IP está protegida.
• Ninguna compañía (ni siquiera Apple) puede ver lo que haces.

El discurso proporcionado por el técnico de Apple es el siguiente:

“Vamos a explorar brevemente cómo funciona Private Relay cuando voy a comprar cosas para mi nueva casa. Primero, cuando hacemos una conexión a una web de venta de mobiliario, se eligen aleatoriamente dos servidores Proxy diferentes en la red de Private Relay, por lo que un solo operador no tiene el control ni tampoco puede ver el escenario completo. El proxy que acepta mi conexión desde internet se llama Ingress Proxy (proxy de entrada). Este proxy oculta mi IP de otros servidores y cifra mi tráfico de internet para que mi proveedor de servicios no sepa qué estoy haciendo. La retransmisión de la petición hacia internet la realiza el Egress Proxy (proxy de salida), para evitar que el Ingress Proxy conozca el sitio al que estoy realizando la petición.

Private Relay gestiona el acceso a la red de forma que no requiere ningún tipo de identificación o información personal, usando firmas RSA ciegas. Una operación criptográfica de cegado realizada por mi dispositivo me permite acceder a la red sin dar ningún tipo de información sobre mi cuenta o sobre quién está realizando la conexión.

Usando la clave pública del servidor de tokens de acceso, un proxy Private Relay puede verificar rápidamente el permiso de acceso a la red. Antes de hacer una conexión, el Servidor de Tokens de Acceso de Private Relay proporciona un conjunto de tokens diferentes a mi dispositivo. Esto me da acceso a cualquier proxy que elija cuando lo necesite.

Para forzar la separación de información entre los proxies que elijo, la conexión se encapsula usando varias capas de cifrado. Los proxies van eliminando esas capas conforme la conexión pasa a través de ellos. Solamente mi dispositivo puede descifrar cada capa, lo cual es necesario para conocer que estoy accediendo a la web de mobiliario.

Cuando se realiza la conexión, el Egress Proxy elige una IP aleatoriamente. Esto ayuda a evitar que se relacione mi búqueda de un sofá con mi búsqueda del cortacésped, o con mi pedido reciente de una mesa. A lo largo del tiempo las conexiones Private Relay se crean automáticamente y se reutilizan para proporcionar protección contra el rastreo de IP y un buen rendimiento. La forma en la que Private Relay oculta mi IP tiene un beneficio más sobre la privacidad. Puesto que la dirección IP de mi casa puede geolocalizarse, el Ingress Proxy puede compartir esa localización conmigo. Esto me permite informar al Egress Proxy qué grupo de direcciones IP elegir. Esto es un gran ejemplo de buen servicio manteniendo la privacidad. Los sitios web pueden proporcionar contenido local en Safari mientras mi localización precisa permanece oculta.

Recuerda, el Ingress Proxy es el único que puede ver mi dirección IP y la convierte en otra dirección que pertenece a la misma área geográfica. Así, el sitio de venta de cortacésped puede saber desde qué área aproximadamente se realiza la conexión. En este ejemplo, el Ingress Proxy devuelve el área “Bay Area, California”, la cual es reenviada al Egress Proxy para ayudarlo a elegir un grupo de direcciones IP asignadas a ese área general. Con una dirección IP regional, los sitios con los que establezco conexión pueden seguir mostrándome tiendas cercanas a mí.

Vamos a ver cómo funciona. Cuando me conecto, ambos sitios ven conexiones entrantes desde una dirección IP que se geolocaliza en mi área general. Pero hay varias posibles localizaciones de las direcciones IP de Private Relay que son compartidas por todos en la región.

Cuando la opción “Use Country and Time Zone” se selecciona en las opciones de iCloud Internet Privacy, no se le da ninguna pista al Egress Proxy.

Así que se elige una dirección IP del grupo que representa toda la región que pertenece al Ingress Proxy. Como resultado, los sitios web verán conexiones realizadas desde un área regional extensa. El mismo conjunto de direcciones IP se utiliza para todos en la región.

Con la configuración de localización generalizada, el sitio web del cortacésped ahora ve una localización aleatoria, la cual para mí pueden ser lugares como Los Ángeles en lugar de Cupertino.”

Hasta aquí los hechos (información proporcionada por la propia Apple), a partir de ahora todo es interpretación y opinión.

Private Relay es un servicio incluido en iCloud+, por lo tanto, no es un servicio público. Así que es necesario dar permiso al usuario para acceder al mismo. El problema es que hay que darle permiso sin identificar al usuario, por seguir manteniendo su privacidad. Para solucionarlo, Apple utiliza un servidor de tokens de acceso. En función de la información proporcionada, voy a intentar explicar cómo se crean de forma simplificada:

1. Tu dispositivo genera un token de sesión de tu cuenta iCloud en la que mantienes la sesión iniciada usando una función y un número aleatorio.
2. Tu dispositivo le solicita al servidor de tokens de acceso de Private Relay su clave pública.
3. Tu dispositivo usa la función, el número aleatorio y la clave pública que ha obtenido para crear un token de sesión “ciego”. Nadie puede comprobar que ese token está asociado a tu cuenta.
4. Tu dispositivo le envía al servidor de tokens de acceso de Private Relay el token de sesión ciego y tu autenticación de iCloud.
5. El servidor de tokens de acceso de Private Relay, una vez verificada tu autenticación de iCloud, firma el token de sesión ciego y se lo envía a tu dispositivo.

Este procedimiento se realiza varias veces, lo que proporciona a tu dispositivo un conjunto de tokens de sesión ciegos. Cuando quieres utilizar el servicio de Private Relay, ocurre lo siguiente:

1. Tu dispositivo se comunica con el proxy correspondiente de Private Relay usando uno de los tokens de sesión ciegos obtenidos previamente.
2. El proxy con el que se ha conectado tu dispositivo solicita al servidor de tokens de acceso de Private Relay su clave pública.
3. Con la clave pública obtenida, verifica que el token de sesión ciego contiene una firma válida y permite a tu dispositivo el acceso al servicio.

Por lo tanto, el servicio se puede utilizar sin identificarte como usuario. Por hacer un símil, es como si comprásemos unas cuantas fichas de lavado de coche. La empresa que nos ha vendido esas fichas no puede saber cuándo las usaremos ni dónde. Ni siquiera cuántas hemos usado porque no sabe cuántas tenemos aún en nuestro poder. Sin embargo, podemos usar el servicio para lavar el coche cuando queramos. Este procedimiento no es nuevo, por ejemplo, Google One también utiliza uno similar para permitir el acceso a su VPN. Puedes leer más información sobre cifrado ciego RSA en este artículo de Cathie Yun.

Ahora es cuando comienza verdaderamente a funcionar el servicio de Private Relay. Voy a limitarme a hacer una propuesta simplificada de cómo podría implementarse usándose un esquema simple de clave pública y privada. La premisa de partida es simple, cada actor en la comunicación genera un par de claves matemáticamente relacionadas de forma que lo que se cifre con una de las claves se descifraría únicamente con la otra. Pero no hay manera de que, teniendo una de las claves, pueda obtenerse la otra. En este caso intervienen cuatro agentes:

• Dispositivo del usuario. Genera su clave privada (SU) y su clave pública (PU) relacionada. Únicas por cada conexión.
• Proxy de entrada (Ingress). Tiene una clave privada (SI) y su clave pública (PI) relacionada.
• Proxy de salida (Egress). Tiene una clave privada (SE) y su clave pública (PE) relacionada.
• Servidor del sitio web. Tiene una clave privada (SS) y su clave pública (PS) relacionada.

Cuando realizamos una petición a un servidor web en Safari (una vez resuelto el DNS) pasaría lo siguiente:

1. Nuestro dispositivo, usando uno de los tokens de sesión, solicita al servicio Private Relay dos servidores proxy aleatorios (uno de entrada y otro de salida) y sus respectivas claves públicas (PI y PE).
2. Nuestro navegador cifra el contenido de la petición junto con su clave pública (PU) usando la clave pública del servidor web (PS). Básicamente esto es lo que realiza el cifrado HTTPS.
3. Vuelve a cifrar lo anterior, enmascarando la IP de destino de la petición (la del servidor del sitio web) y añadiendo otro token de sesión y su clave pública (PU), con la clave pública del proxy de salida (PE).
4. De nuevo vuelve a cifrar lo anterior, añadiendo otro token de sesión y la IP del proxy de salida elegido, con la clave pública del proxy de entrada (PI).

5. Ahora envía el paquete con todas sus capas de cifrado a la dirección IP del proxy de entrada.
6. El proxy de entrada descifra la primera capa con su clave secreta (SI) y verifica con la clave pública del servidor de tokens de acceso que el token es válido. A continuación, geolocaliza la IP del usuario y le asigna una zona extensa aproximada.

7. Envía el paquete con el resto de capas y la zona aproximada al proxy de salida cuya IP ha descifrado usando uno de sus puertos (y registrando que las comunicaciones de ese puerto pertenecen a la IP del usuario).
8. El proxy de salida registra el puerto origen de la petición y lo mapea con otro de sus puertos, por el que reenviará la petición. Descifra una capa más con su clave privada (SE) y obtiene la IP destino (la del servidor del sitio web) y un token de acceso. Verifica el token de acceso y elige una IP aleatoria de la zona que le ha indicado el proxy de entrada. Le envía lo que queda del paquete, usando esa IP elegida como origen, al servidor del sitio web.