Towards the Web of Trust

Recently, I exchanged some e-mails with Anne van Kesteren about security models for the Web. He wrote his thoughts down in an interesting post on his blog titled Web Computing. This is sort of a reply to that post with my own thoughts.

Today, 10,000 days after, the first published Web is still working (congratulations! ^^). 10,000 days ago, JavaScript did not even exist but now we are about to welcome ES6 and the Web has more the 12,000 APIs.

Latecomers Service Workers, Push and Sync APIs have revitalized web sites to compete with their native counterparts but if we want to leverage the true potential of the Web we should increase the number of powerful APIs to stand at the same level of native platforms. But powerful APIs imply security risks.

To encourage the proposal and implementation of these new future APIs, an effective, non-exploitable revocation scheme is needed.

In the same way we can detect and block certain deceptive sites, we could extend this idea to code analysis. Relying on the same arguments supporting the success of open source communities, perhaps a decentralized network of security reviews and reviewers is doable.

Captura de pantalla 2016-07-26 a las 10.06.25
I imagine a similar warning for web properties proven to be harmful.

This decentralized database (probably persisted by user agents) would declare the safeness of a web property based on the presumption of innocence which means, in roughly statistical terms, that our hypothesis should be «the web property is evil» and then try to find strong evidence to beat the null hypothesis «the web property is not evil».

Regardless the methodology chosen there will be two main categories: we have not enough evidence for a web to be declared harmful (or we are completely sure it is safe) and we have strong evidence for a web to be considered harmful. We should take some action in the latter and not alert the user in the former but, what should we actually do? Not sure yet, honestly.

For instance, in case of strong evidence, should the user agent prevent the user from accessing the web site? Or should it automatically revoke some permissions and query the user again? Could the user decide to ignore the warnings?

There are more gaps to fill starting by providing a formal definition of harmful. I.e., what does harmful mean in our context? Should a deceptive site be considered harmful from this proposal’s point of view? Consider a phishing site with a couple of input tags for faking Gmail login page with a simple POST form and no JavaScript at all… In my opinion, we should not focus on site’s honesty but in API abuse. We already have mechanisms for warning about deception and if you want to judge web site reputation, consider alternatives such as My Web Of Trust.

In his response, Anne highlighted the importance of not falling in the CA trap «because that means it’s again the browsers that delegate trust to third parties and hope those third parties are not evil«.

OpenPGP has the concept of ring (or web) of trust for a decentralized way to grant trustworthiness. What if instead of granting trustworthiness, UAs provide a similar structure to revoke it? Kind of issuing a mistrust certificate.

And finally, there is the inevitable problem related to auditing a web site. The browser could perform some static analysis and provide a per-spec first judgement but what would happen after? Can we provide some kind of platform to effectively allow decentralized reviews by users?

In my ideal world, I imagine a community of web experts providing evidences of API abuse, selecting a fragment of code and explaining why that snippet constitutes an instance of misuse or can be considered harmful, other users can see and validate the evidence. Providing this evidence would be a source of credit and recognition to the same extent as contributing to Open Source projects.

Another bunch of uncomfortable questions arise here, though. What if the code is obfuscated or simply minified? How does the browser track web site versions? Should the opinions of reviewers be weighted? By which criteria?

Well, that’s the kind of debate I want to start. Thoughts?


On Google plans for the Web

Now I’m talking publicly about progressive web apps and the future of Web development and the Internet, I’ve been asked a lot for my opinion about instant apps and, before instant apps, about why Google was trying to close the gap between the Web and native platforms, i.e. Android.

Actually, I don’t really know but despite the strategy would seem contradictory, after Google I/O it seems obvious to me: Google is running an experiment about switching its distribution platform. to bring more users to the search engine.

Why? Well, it makes sense that there should be a correlation between the time a user spends on Google search engine and the amount of money Google earns. So here is my assumption: given the marketplace is free from ads and most of the content is free, browsing the marketplace is not profitable or, at least, not as profitable as the Google search engine.

But we like applications, and to use applications implies some behaviour patterns, the result of all these years of mobile education. So, in order to make Web applications more appealing (and so, to increase the time a user spent in the search engine) why not to add native-application characteristics to Web applications?

In the other hand, it is Android. Another common question these days is: will we, Android developers, loose our jobs in the future? As if some of Android developers would feel threatened by progressive web apps in some way.

Well, honestly, I think no, at least in the near and mid time scenarios and Google has provided some extra warranties to make Android last for even more time. With Instant Apps, Google is closing the gap from the other end, it’s bringing to Apps what we like most from the Web: immediacy (no market, no download, no installation) and URLs so now we can search for Apps in Google engine. And that’s the point! No market, more time spent in Google search engine.

And why to bet for two approaches instead of one? Because it brings more users to the search engine and… they can (in terms of costs). If both initiatives succeed, both developer communities will be happy and users will spend their time into the most profitable distribution platform they can use: the Internet. Everybody win and the world is a wonderful place… for somebody. 😉

And that’s all folks! Notice that I could be totally wrong since all this is based on the premise that Google earns more money from the engine than from the market but there is some data to support my assumption out there (google it!) and, in the end, this is only speculation.

EDIT: I changed the nature of the experiment as it was not accurate enough. It is more clear now.



ETA: fin del «conflicto armado»

Yo no suelo opinar de política en medios como este que va a leer mucha gente. Porque me considero un ignorante de cuidado.

Por supuesto, me alegro del «cese del conflicto armado» pero a qué precio, me pregunto yo. Algo tendré que decir dado que tengo mi propia opinión. Y esto es lo único que diré:

Espero que no afecte a las elecciones. Espero que la gente indiferente no piense «¡anda!, pues esta clase política no será tan mala después de todo». Porque lo es.

De todas formas, las posibilidades de una reestructuración importante del gobierno han pasado de bajas a escasas.

Eso es todo.

BOLA EXTRA: ver el comunicado de ETA me ha puesto nervioso (estrictamente, casi me hace hervir la sangre), pero claro, qué van a decir, no van a soltar «lo sentimos mucho, somos unos asesinos y los nuestros están bien entre rejas, ¡colgadnos!». Esto es propaganda. Espero que la estrategia de nuestros políticos esté a la altura de las futuras negociaciones y, por lo que más respeten, espero que se les siga dando caña.

Arch Linux ¡y Gnome3! sobre Virtual Box

Los que sigais este blog sabreis que ya publiqué esta guía antes. Pero como Arch Linux es una distribución muy volátil, que trata siempre de estar a la última, os dejo aquí una buena puesta al día de la Guía de Instalación de Arch Linux sobre Virtual Box cuya principal novedad es que incluye la instalación de GNOME 3.

  1. Arch Linux sobre Virtual Box 1/5: cubre las partes I y II, descripción y configuración de Virtual Box respectivamente.
  2. Arch Linux sobre Virtual Box 2/5: sólo la parte III. Trata de la instalación de Arch Linux.
  3. Arch Linux sobre Virtual Box 3/5: partes IV y V, primera ejecución y gestión de paquetes con pacman.
  4. Arch Linux sobre Virtual Box 4/5: parte VI, aplicación sudo y entorno de escritorio GNOME 3.
  5. Arch Linux sobre Virtual Box 5/5: parte VII, explicación de AUR, el gestor de paquetes yaourt y el entorno gráfico Awesome.

Teneis más información acerca de la instalación en la wiki de Arch Linux.

Django 1.3 en «cero coma» II

La primera entrega de este tutorial sirvió para introducir en 10 pasos algunos aspectos interesantes de Django 1.3. en esta segunda parte vamos a tratar de ser más caseros, programando un poco más pero utilizando correctamente el framework. Aquí tenéis un resumen:

  1. Añadiremos un propietario al modelo
  2. Mejoraremos la administración de posts
  3. Implementaremos un sistema de comentarios
  4. Retocaremos el administrador para gestionar los post y comentarios
  5. Implementaremos un formulario de búsqueda muy sencillo

Seguir leyendo «Django 1.3 en «cero coma» II»

Fail en la plataforma WebCT

Sé que no es sólo mi opinión pero pienso sinceramente que la plataforma WebCT, un campus virtual de pago, es extremadamente deficiente y anticuada.

Pero anonadado me he quedado cuando me he encontrado en la siguiente situación:

Puntuación de 11 sobre 10 en el panel de calificación.
Ahí teneis el 11 sobre 10 en el panel de calificación

Resulta que tengo el «privilegio» de porder acceder a esta platadorma como profesor. Un alumno me ha sorprendido con una práctica muy bien entregada y en los comentarios, he bromeado con él acerca de que, si pudiera, le pondría un 11 sobre 10. Basándome en mi opinión personal sobre la plataforma y tentando a la suerte, he introducido 11 en el cuadro de calificación (como podeis ver en la captura que acompaña a estas líneas) y he pulsado aceptar.

Y sí, amigos mios, sí, se lo ha tragado con patatas como podeis comprobar aquí:

Lista de calificaciones con el 11 sobre 10
Mirad qué bien queda, un 11 sobre 10, todo un orgullo para el alumno y un facepalm del tamaño de la Estrella de la Muerte para los programadores.

En fin, sinceramente, vergüenza ajena.

usuario ALL=ALL(ALL) ALL

¿Qué significa usuario ALL=ALL (ALL) ALL?  Esta línea es muy común en las configuraciones de Linux pero qué pinta tanto ALL y qué quiere decir son cosas que poca gente sabe.

Sudo es una aplicacion de Linux que permimte ejecutar comandos como si fuéramos otros usuarios, de hecho sudo viene de «substitute user do«. La configuración de sudo, es decir, qué podemos hacer como otros usuarios y dónde, se refleja en un archivo llamado sudoers normalmente situado en el directorio /etc aunque tal archivo sólo debería modificarse mediante la aplicación visudo.

La sintaxis del archivo sudoers no es complicada pero sí bastante extensa. Podeis leerla online en el enlace anterior o en vuestros equipos consultando el manual. Aquí, sólo voy a indicar qué significa la línea que da título al post:

La clave para leer la especificación de usuarios es saber qué significa cada parte. Podríamos resumirlo en:

fulanito, en ciertos equipos, puede ejecutar los siguientes comandos como si fuera menganito; o puede ejecutar estos otros como si fuera jaimito

Traducido a la sintaxis de sudoers:

fulanito ciertos_equipos=(menganito) comandos, (jaimito) estos_otros_comandos

En definitiva:

usuario hosts=(como_quién) qué_comandos [, (como_quién) otros_comandos]...

A veces, la coma se omite pues el paréntesis de apertura sirve como separador. Si el como_quien también, indica que nos referimos a nosotros mismos.

Así que cuando especificamos usuario ALL=ALL (ALL) ALL lo que estamos diciendo es:

usuario, en todos los equipos, puede ejecutar cualquier comando (siendo nosotros mismos) y todos los comandos como si fuera cualquier usuario

Y así de fácil es la cosa.