Zoom es el grán éxito de la temporada, casi hasta el punto de convertirse en genérico. Es un sistema de videoconferencia que ha gozado de gran éxito y que ha aumentado su número de usuarios de una forma espectacular. Ya hablamos aquí de un Análisis de amenazas de un sistema de cifrado entre extremos para videoconferencia pero ahora traemos el análisis de otro experto, Daniel Miessler, que dice que This Zoom Hate is Silly.

Es cierto que tiene (o tenía) problemas de seguridad, pero la respuesta que hubo en algunos ámbitos no tenía mucha lógica.

I get there are security issues. And some seem pretty bad. But the amount of highly-coordinated PR against the company feels more like an operation than regular criticism…

La competencia era abundante y notable. Skype, Hangouts, Webex , …

Lots of companies had competing products much earlier than them. Years earlier. Skype, Hangouts, Webex—they all had their shot. But Zoom comes in and makes something people actually want to use.

Pero… ¿seguro que no tenían sus propios problemas de seguridad?

But if you’ve been in security a while you know that vulnerabilities aren’t absent just because they aren’t being talked about. If you looked at Hangouts, or WebEx, or any of these other options the same way we’re looking at Zoom, it’d likely be just as nasty.

Pero claro prohibir una herramienta que ya mucha gente usa supone dejarlos a buscar sus propias alternativas y desperdiciar su esfuerzo.

Banning Zoom requires that the risk to people is as bad or worse than what’s gained from its use. And during a pandemic when most other solutions are nowhere near as approachable, that’s a very high bar.

La seguridad es un compromiso, entre facilidad de uso, comodidad, seguridad… Y, en este caso, tal vez dejar a alguien sin posibilidad de comunicarse.

Everything in security is a tradeoff. The only question is whether you’re properly measuring both sides to make an informed choice.

For people banning Zoom all over the place right now, the tradeoff is not communicating easily with people in a moment of intense need. Not. Communicating. During. Intense. Need. That’s on one side of the balance.

Hay que establecer un balance entre ventajas e inconvenientes.

Una de las cosas que voy haciendo en mi tiempo libre es programar. En los últimos años el trabajo no me da muchas oportunidades de hacerlo y he descubierto que me relaja y me entretiene. Ya hace unos años que compré una Raspberry Pi y en su momento empecé a pensar qué hacer con ella. De allí salió la idea de manter un gestor de información personal (Personal Information Manager, PIM) y hacerlo mediante un bot: en un contexto de movilidad, donde uno no siempre tiene un ordenador a mano, o no puede sacarlo con comodidad, parece adecuado tener servicios similares con una intervaz más adecuada.

Me hubiera gustado presentarlo el año pasado en esLibre, que era en Granada pero las fechas no eran adecuadas para mi. Este año esLibre era en Madrid y pensé que podría hacer una escapadita aunque fuera en el día y presenté mi propuesta, Un bot (no inteligente) multi-interfaz y distribuido como asistente personal que fue aceptada.

Lamentablemente, luego vino la pandemia y el encuentro se canceló, hasta que los organizadores (¡bravo por ellos!) decidieron lanzarse a la organización telepresencial. Con esto hemos perdido la cercanía, las charlas de café… Pero hemos ganado que mucha gente que de otra forma no habría podido, asista. Y también disponer de la grabación en video de la presentación. Es posible que más adelante escriba las ideas principales pero de momento nos conformaremos con poner el vídeo

También la presentación utilizada:

Espero que les guste.

En programación existen varias discusiones eternas. Una de ellas es la comprobación de tipos. Hay lenguajes más exigentes y (nos dicen) por ello mucho más seguros y robustos y otros mucho menos y (nos dicen) por ello mucho más productivos y eficaces.

En Our journey to type checking 4 million lines of Python nos hablan de Dropbox, y su esfuerzo para mejorar la verificación de tipos en sus programas escritos en Python.

Dropbox is a big user of Python. It’s our most widely used language both for backend services and the desktop client app (we are also heavy users of Go, TypeScript, and Rust). At our scale—millions of lines of Python—the dynamic typing in Python made code needlessly hard to understand and started to seriously impact productivity.

Python es un lenguaje con tipado dinámico (esto es, una variable puede tener un tipo en un momento dado y más adelante tener otro). Eso es cómodo, porque nos quita preocupaciones cuando programamos pero puede ser un inconveniente cuando el código crece y empezamos a no entender lo que sucede.

Once your project is tens of thousands of lines of code, and several engineers work on it, our experience tells us that understanding code becomes the key to maintaining developer productivity. Without type annotations, basic reasoning such as figuring out the valid arguments to a function, or the possible return value types, becomes a hard problem.

¿Qué puede devolver esta función? ¿Cómo debería ser este argumento? ¿Qué puede significar este nombre?

Puede que haya documentación, pero que sea ambigua o poco precisa.

Even if there is a docstring, it’s often ambiguous or imprecise, leaving a lot of room for misunderstandings.

Si definimos los tipos y podemos verificarlos, tenemos algunas ventajas: no poner datos en lugares donde no serán bien recibidos, por ejemplo. Pero también, por ejemplo, poder cambiar el código (refactorizar) más fácilmente:

Refactoring is much easier, as the type checker will often tell exactly what code needs to be changed.

El trabajo se ha desarrollado sobre casi 5 millones de líneas de código y ha permitido mejorar la situación:

It has been a long journey from the early prototypes to type checking 4 million lines in production. Along the way we’ve standardized type hinting in Python,…

La organización ha asumido este trabajo como propio y ya se da por supuesto, pero aún queda camino por recorrer:

Even though type checking is already taken for granted at Dropbox, I believe that we are still in early days of Python type checking in the community, and things will continue to grow and get better

Intersante.

Zoom ha sido uno de los vencedores de la pandemia. Es una plataforma de videoconferencias sencilla de usar, que funciona bastante bien (casi todas hoy en día, esa es la verdad) y que para mucha gente ha sido un verdadero hallazgo.

En Trusting Zoom? que no me importan tanto por la plataforma en sí, sino por el análisis que hace de algunas prevenciones que se comentaron durante el inicio de la pandemia. Ya digo que algunas cosas habrán cambiado (y sigue habiendo polémicas sobre la plataforma, al máximo nivel Zoom lied to users about end-to-end encryption for years, FTC says).

Lo primero que dice es que, a pesar de los puntos débiles, la plataforma proporciona un servicio con unos beneficios tan importantes en aquel momento que superarían los inconvenientes, salvo que perjudicasen notablemente a alguien:

In other words, the benefit of using Zoom is considerable, and I have an ethical obligation to do it unless the risks to me, to my students, or to the university are greater.

Prefiere la aplicación porque no se fía de los navegadores:

My reasoning for not using the browser option is a bit different: I don’t trust browsers enough to want one to have the ability to get at my camera or microphone.

Sobre todo porque cualquier fallo le pondría en un compromiso sólo cuando utilizara la aplicación y no el navegador, que lo usa mucho más:

But apart from my serious privacy reservations, flaws in the Zoom app put me at risk while using Zoom, while flaws in a browser put me at risk more or less continuously.

Sus clases, al final son públicas (para su audiencia, e incluso cuelga materiales de manera pública)

But apart from my serious privacy reservations, flaws in the Zoom app put me at risk while using Zoom, while flaws in a browser put me at risk more or less continuously.

Y luego se pregunta si las debilidades de Zoom son suficientemente importantes para evitar su uso:

Are Zoom’s weaknesses sufficiently serious that my university—and I—should avoid it?

Sobre los métodos criptográficos utilizados, sin ser los mejores, parecen suficientes para lo que se está haciendo:

That’s already a substantial part of the answer: I’m not worried about the Andromedan cryptanalysts trying to learn about my students’ personal tragedies. Yes, I suppose in theory I could have as a student someone who is a person of interest to some foreign intelligence agency and this person has a problem that they would tell to me and that agency would be interested enough in blackmailing this student that they’d go to the trouble of cryptanalyzing just the right Zoom conversation—but I don’t believe it’s at all likely and I doubt that you do.

Por otra parte, ese atacante tendría que tener acceso de alguna forma al tráfico de la red:

There’s another part of the puzzle for a would-be attacker who wants to exploit this flaw: they need access to the target’s traffic. […] Routing attacks don’t require a government-grade attacker, but they’re also well up there on the scale of abilities.

Por lo que atacar y sacar partido del cifrado entre extremos sería algo complejo:

What it boils down to is this: exploiting the lack of true end-to-end encryption in Zoom is quite difficult …

Finalmente, destaco que el autor trata de hacer todo su contenido académico público, así que tampoco teme los robos. Puede haber excepciones:

Nothing that I personally do would seem to meet that first criterion—I try to make all of my academic work public as soon as I can—but there are some plausible university activities, e.g., development of advanced biotechnology, where there could be such governmental interest.

Como decía, me pareció una lectura interesante.

Hace no mucho he descubierto dev.to, una comunidad de desarrolladores que van compartiendo conocimiento e información. Muchas veces, casi a modo de recetas. En esta ocasión traigo Navigating files in Linux que habla del sistema de ficheros de Linux y cómo se organizan algunas cuestiones alrededor de él.

En Linux todo es un fichero:

On Linux, everything on the system is represented with a file—Keyboards, disk drives, robotic arms, running programs and the rest: All files. Naturally, a Linux system needs a lot of files—And a sensible way to organize them.

Y luego pasa a detallar la estructura de un sistema de ficheros y qué podemos esperar encontrar en cada sitio. Interesante.