Hace unas semanas me invitaron desde la Cámara de Comercio de Zaragoza a moderar una sesión sobre el sector tecnológico del Foro: ‘Claves Para Entender El Nuevo Mercado Laboral’, junto con Pilar Fernández de la Cámara y Mertixell Laborda de Océano Atlántico.
El encuentro se celebró el dia 10 de septiembre en la recién rehabilitada sede de la Cámara de Comercio de Zaragoza.
Participaban personas muy interesantes, algunas de ellas viejas conocidas (incluso ex-alumnos) y otras con las que no había tenido la suerte de coincidir:
Eran empresas muy variadas, desde tecnológicas puras a otras para las que su enfoque es la producción pura. Familiares, empresas con fines sociales, …
Dedicándose a logística, alimentación, informática, servicios…
A mi me llamaba la atención cómo algunas empresas no se consideran tecnológicas a pesar de que su negocio depende fuertemente de las herramientas (y no me refiero solo a la gestión) y que en muchos casos la tecnología puede hacer que seamos diferenciales con respecto a nuestra competencia.
Surgió la necesidad de captar estos perfiles, para todo tipo de empresas (pero tal vez para las que no se dedican a la tecnología un poco más), se habló de los perfiles, la formación (que tiene sus propias dificultades) y un poquito de la llegada de la inteligencia artificial y cómo puede afectarnos.
Durante la sesión hice un pequeño juego (no hubo mucho tiempo para preparar la sesión) al hacer la presentación de las presonas y de sus empresas a través de lo que veía en su página web.
Queda como ejercicio para el lector sacar sus propias impresiones.
Este sitio se basa, casi exclusivamente, en comentarios sobre diversas notas que voy encontrando por la red. En estos casos siempre, sin excusa, hay un (o más) enlaces a lo que originó la publicación así que me gusta mucho traer Why I Attribute donde Stephen Downes nos da sus razones para hacerlo.
Una de las claves es que cuando hay atribución se puede ver no sólo el comentario de la persona que estamos leyendo, sino también los de las personas referenciadas, si el tema nos interesa lo suficiente.
By the time it got to you, you had not only the original story but also some interpretations or perspectives on that story.
También se muestra un cierto apoyo: no significa que estemos de acuerdo con lo que se pueda comentar en los otros sitios, pero al menos la historia ha interesado a una serie de personas y no solo a la que te lo muestra.
It means each of us felt that this story was important enough to pass along. By the time you got it, the story had been vetted three times.
Al final, se construye una red de relaciones, que puede verse como una comunidad, porque normalmente no habrá un solo seguidor de este contenido, ni del enlazado, ni del…
Few people have only one follower. Most people have several. Some have thousands. Nobody has millions, as on mass social networks - there's an upper limit somewhere where too many followers doesn't really work on a federated social network (which is why we are very unlikely to see advertising-supported federated social networks).
These followers constitute a community.
Y como resultado de este ‘entramado’ puede ser más sencillo darle credibilidad a algunas ideas, o simplemente evaluarlas.
Getting the message in this way puts you in a much better position to assess the message, evaluate whether it is true, and decide whether to act on it (or pass it along to your own community).
Luego elabora sobre las redes sociales y cómo cortocircuitan este mecanismo, de la misma forma que lo hacen muchas veces los medios de masas, más preocupados por la cantidad de atención sobre todas las cosas.
Sin olvidar del esfuerzo que supone la validación a través de la atribución.
These functions, though, have all but disappeared from news media. Because news media depended on advertising, and therefore mass audiences, it came to value engagement over all. The layers of validation and verification were not only expensive overhead, they got in the way of prioritizing engagement.
De hecho, iba a comentar arriba que en redes sociales no suelo enlazar a las fuentes tanto: por una cuestión práctica (o dos), que tiene que ver con el espacio limitado, y porque parece que nada importa demasiado allí.
Si hablamos de contar pensaremos que se trata de una tarea fácil, porque es algo que hacemos habitualmente sin demasiados problemas. Incluso disponemos de herramientas que nos ayudan: cuántas fotos he hecho, cuántos pasos he dado, …
Aunque a veces no es tan sencillo. En Computer Scientists Invent an Efficient New Way to Count nos preguntan cómo contaríamos el número de seres vivos en un bosque. Incluso con herramientas como ese contador de la cámara de fotos y disparando una foto cada vez que lo necesitemos sería complicado.
Imagine that you’re sent to a pristine rainforest to carry out a wildlife census. Every time you see an animal, you snap a photo. Your digital camera will track the total number of shots, but you’re only interested in the number of unique animals — all the ones that you haven’t counted already. What’s the best way to get that number?
¿Y el número de usuarios distintos que se conectan cada día a una red social como Facebook? Tendríamos que comparar cada nueva entrada de un usuario con una lista inmensa de entradas previas, para asegurarnos de que era un nuevo usuario.
It gets worse. What if you’re Facebook, and you want to count the number of distinct users who log in each day, even if some of them log in from multiple devices and at multiple times? Now we’re comparing each new login to a list that could run to the billions.
</blockquote>
El problema tiene nombre propio, el problema de los elementos diferentes (the distinct elements problem) y recientemente Sourav Chakraborty del Indian Statistical Institute, Vinodchandran Variyam de la University of Nebraska, Lincoln, y Kuldeep Meel de la University of Toronto han propuesto una solución novedosa, que se puede ver en Distinct Elements in Streams: An Algorithm for the (Text) Book.
El algoritmo evita almacenar todo lo que se ha contado hasta el momento, basado en la aleatoriedad: podemos ir tomando elementos, hasta llegar a los 100, evitando las repeticiones. Cuando los tenemos, lanzamos una moneda al aire (¡aleatoriedad!) por cada elemento contado: si sale cara, se queda en la lista; si sale cruz, lo borramos. Al final deberíamos tener unos 50 elementos.
When the space is full, press pause and flip a coin for each word. Heads, and the word stays on the list; tails, and you delete it. After this preliminary round, you’ll have about 50 distinct words left.
Ahora seguimos contando y cada vez que encontramos un elemento que ya tenemos en la lista volvemos a lanzar la moneda: si sale cruz la borramos, y si sale cara la mantenemos en la lista. Continuamos hasta que volvamos a tener 100 elementos y volvemos a borrar de manera aleatoria aproximadamente la mitad.
Con esto hemos terminado la primera ronda.
Proceed in this fashion until you have 100 words on the whiteboard. Then randomly delete about half again, based on the outcome of 100 coin tosses. That concludes Round 1.
Para la segunda, haremos algo parecido; pero en este caso será más difícil que un elemento permanezca en la lista. Si sale la cruz la borramos, igual que antes; pero si sale cara, lanzamos la moneda otra vez y mantenemos el elemento solo si vuelve a salir cara. Una vez que tenemos los 100 elementos ocupados de nuevo eliminamos alrededor de la mitad de las palabras otra vez, igual que en la vuelta anterior.
ontinue as in Round 1, only now we’ll make it harder to keep a word. When you come to a repeated word, flip the coin again. Tails, and you delete it, as before. But if it comes up heads, you’ll flip the coin a second time. Only keep the word if you get a second heads.
En la tercera ronda, hará falta que salga cara tres veces para mantener el elemento, en la cuarta, cuatro. Y así sucesivamente.
In the third round, you’ll need three heads in a row to keep a word. In the fourth round you’ll need four heads in a row. And so on.
En algún momento habremos terminado con los elementos que tenemos que contar y por la forma de proceder cada elemento tiene exactamente la misma probabilidad de estar allí que el resto: 1/2k.
Por ejemplo, si hay 61 elementos en la lista y el proceso ha costado seis rondas, podemos dividir 61 por la probabilidad (1/26) lo que nos da un resultado de 3904 elementos.
The point of the exercise has been to ensure that every word, by virtue of the random selections you’ve made, has the same probability of being there: 1/2k. If, for instance, you have 61 words on your list at the conclusion of Hamlet, and the process took six rounds, you can divide 61 by the probability, 1/26, to estimate the number of distinct words — which comes out to 3,904 in this case.
Lo que han demostrado es que la precisión de este método aumenta con el tamaño del espacio que usamos para contar. Si la memoria es suficientemente grande podemos obtener una precisión del 100%.
Variyam and his colleagues mathematically proved that the accuracy of this technique scales with the size of the memory.
¿Por qué es interesante?
Como dice William Kuszmaul, incluso para problemas sencillos de entender, básicos y que han sido muy estudiados se pueden encontrar soluciones simples pero no obvias.
“This is a great example of how, even for very basic and well-studied problems, there are sometimes very simple but non-obvious solutions still waiting to be discovered,” said William Kuszmaul (opens a new tab) of Harvard University.
Para personas menos acostumbradas a estas cosas también puede servir cómo, a veces, lanzar una moneda al aire nos ayuda a obtener resultados que no seríamos capaces de conseguir sin ella en un tiempo razonable.
Vivimos tiempos verdaderamente complicados. Aunque no entraremos en los detalles más técnicos, este verano fue noticia el casi conseguido ataque a un conjunto de programas desconocidos por la gente menos técnica, pero muy importantes en muchas distribuciones de Linux (xz utils). La cosa tiene casi las características de una película de intriga, porque el análisis posterior de la cosa nos muestra como alguien se infiltra en un proyecto de software libre, con tácticas de ingeniería social (esencialmente dar la lata, presionar, …) consigue hacerse con el control del proyecto e insertar código malicioso; pero no de cualquier manera, porque lo esconcía en alguna parte de la batería de pruebas, despistando a cualquier examinador que intentara encontrar algo raro. Pero algo raro había, porque un desarrollador de Microsoft se da cuenta que una determinada operación tarda más tiempo de lo que debería y, tirando del lío, descubre el problema. Justo cuando esos programitas ya habían empezado a entrar en las actualizaciones de las distribuciones, pudiendo ser un peligro muy importante.
En Jia Tan and SocialCyber ilustran el caso desde una perspectiva interesante, que es la actividad de las personas que contribuyen a este tipo de proyectos. No sólo desde el punto de vista puramente ténico, sino a través de otras señales que se pueden observar.
Jia Tan era el nombre de este contribuidor (seguramente un equipo) que estuvo a punto de liarla gordísima.
Pero aquí nos queremos centrar hoy en el punto de vista de los indicios cuando algo va mal, porque en el desarrollo de los programas hay una parte técnica y tecnológica, claro, y otra parte que podemos llamar ‘social’. Esto es, están las instrucciones y las líneas de código, la interacción con los repositorios donde se pone el trabajo en común…. pero también están los mensajes que se intercambian, la red social de personas que se relacionan directamente con el trabajo de desarrollar …
..., and that software includes both the technical artifacts (aka, the commits) and the social artifacts (messages around software, and the network of people that build the software), holds true to this day, and has not, in my opinion, received the attention it deserves.
En el caso del tal Jia Tan, si prestamos atención a los detalles podíamos ver:
Problemas en la línea de tiempo (fechas/horarios que no son compatibles/razonables).
Medidas de la actividad del usuario en cuestión.
Modificaciones en ‘zonas’ del código que normalmente no tocan.
Amistades ‘peligrosas’.
Verificación de las direcciones de correo electrónico utilizadas, a través del análisis en los sitios de divulgación de incidentes relacionados con ellas (ahora resulta que si tu dirección de correo no aparece en ningún indicente hay bastantes probabilidades de que sea peligrosa).
Comparación de similaridades con otros programas maliciosos
- Time zones (easily forged, but often forgotten), sometimes you see "impossible travel" or time-of-life anomalies as well
- Pagerank (measures "importance" of any user in the global or local scope of the repo). "Low" is relative but I just pick a random cutoff and then analyze from there.
- Users committing to areas of the code they don't normally touch (requires using Community detection algorithms to determine areas of code)
- Users in the community of other "bad" users
- Have I Been Pwned or other methods of determining the "real"-ness of an email address - especially email addresses that come from non-corpo realms, although often you'll see people author a patch from their corpo address, and commit it from their personal address (esp. in China)
- Semantic similarity to other "bad" code (using an embeddings from CodeBERT and Neo4j's vector database for fast lookup)
Podemos estar de acuerdo en que no siempre es muy sencillo hacer estas comprobaciones y menos todavía si no somos personas de perfil técnico; pero también lo estaremos en que podemos detectar situaciones ‘raras’ prestando un poco de atención y haciendo las preguntas o las indagaciones correctas. Y eso está en la mano de casi todo el mundo.
Uno de los problemas fundamentales en la seguridad informática aparece cuando por el mismo canal de comunicación aparecen información y datos de control (instrucciones): aunque los marques para diferenciarlos, alguien lo hará mal alguna vez o alguien encontrará una forma de saltarse las medidas que pongamos.
Cuando hablamos de inteligencias artificiales estos días casi siempre nos referimos a los modelos gigantes de lenguaje (large language models, LLMs) y Bruce Schneier nos hablaba del problema en LLMs’ Data-Control Path Insecurity.
Comienza recordando que las primeras centralitas telefónicas eran vulnerables al problema y cómo alguna gente enviaba tonos especiales que les permitían llamar gratis.
Back in the 1960s, if you played a 2,600Hz tone into an AT&T pay phone, you could make calls without paying.
El problema era el que comentábamos: por la misma línea iban los datos (el sonido de la llamada) y la información de control (esos tonos y otros que se usaban).
This general problem of mixing data with commands is at the root of many of our computer security vulnerabilities.
Es el mismo problema que la inyección de SQL, los desbordamientos de memoria… que son un poco técnicos para ponerlos aquí.
Cuando han llegado los modelos de lenguaje, se ha empezado a hablar de la inyección de preguntas (prompt injection) y la idea vuelve a ser la misma: el mismo canal que nos sirve para interrogar al modelo, permite controlar determiandas formas en que responderá. Por lo tanto, alguien podrá engañar al modelo para que proporcione información que no debería.
Prompt injection is a similar technique for attacking large language models (LLMs). There are endless variations, but the basic idea is that an attacker creates a prompt that tricks the model into doing something it shouldn’t.
Es relativamente sencillo tratar de evitar estos ataques cuando se conocen, pero el problema es que hay muchas formas en las que esto puede suceder y esto es, en sí mismo, un problema.
Individual attacks are easy to prevent once discovered and publicized, but there are an infinite number of them and no way to block them as a class.
Además, y a diferencia de los sistemas previamente mencionados, no es posible separar en estos sistemas los datos de las instrucciones, porque justo esa es una de sus características: queremos que los datos cambien el comportamiento de la cosa.
But unlike the phone system, we can’t separate an LLM’s data from its commands. One of the enormously powerful features of an LLM is that the data affects the code. We want the system to modify its operation when it gets new training data. We want it to change the way it works based on the commands we give it. The fact that LLMs self-modify based on their input data is a feature, not a bug. And it’s the very thing that enables prompt injection.
