De vez en cuando encontramos una entrada como esta y la recomendamos: HTTP headers for the responsible developer habla justamente de eso, las cabeceras que se recomienda enviar hoy en día pensando en la seguridad y en un trato adecuado a nuestros lectores. Si se puede, claro.

Como desarrolladores tenemos una responsabilidad, que es construir cosas que ayudan y dan fuerza a las personas.

Developers have the power to build the web for everyone, but that power needs to be used responsibly. What matters, in the end, is building things that help and enable people.

Luego hablan de las cabeceras relacionadas con una conexión segura, con una política adecuada de contenidos (CSP)… Pero también se preocupan del coste (que no haga falta una máquina de última generación para poder usar nuestro sitio, por ejemplo).

While I write this article, I sit in front of a relatively new MacBook using my fast Wi-Fi connection at home. Developers often forget that a setup like this is not the default for most of our users. People visiting our sites use old phones and are on crappy connections. Heavy and bloated sites with hundreds of requests give them a bad experience.

También con respeto para los usuarios, no hacerles esperar, no molestarles innecesariamente…

Finalmente, también nos recuerda que debe ser para todo el mundo.

In this article, I only covered a few headers that could help improve the user experience. If you want to see an almost complete overview of headers and their possibilities I can recommend having a look at Christian Schaefer’s slide deck “HTTP headers – the hidden champions”

Muy interesante.

En Git ransom campaign incident report—Atlassian Bitbucket, GitHub, GitLab una nota que emitieron Bitbucket, GitHub y GitLab sobre el secuestro de sitios gestionados dentro de sus sistemas.

Today, Atlassian Bitbucket, GitHub, and GitLab are issuing a joint blog post in a coordinated effort to help educate and inform users of the three platforms on secure best practices relating to the recent Git ransomware incident.

Algunos usuarios entraban a la plataforma y se encontraban con que alguien había entrado en sus cuentas y había ‘secuestrado’ su contenido. Aparentemente se debería al despiste de estos usuarios que habrían divulgado sus credenciales de alguna forma.

Each of the teams investigated and assessed that all account compromises were the result of unintentional user credential leakage by users or other third-parties, likely on systems external to Bitbucket, GitHub, or GitLab.

En estos sitios se observaba actividad de datos en el fichero .git/config y otros parecidos que, en algunas ocasiones contenían credenciales, tokens de acceso y otros datos sensibles.

Further investigation showed that continuous scanning for publicly exposed .git/config and other environment files has been and continues to be conducted by the same IP address that conducted the account compromises, as recently as May 10.

Los consejos para protegerse son los de siempre: utilizar doble factor, utilizar claves fuertes y únicas para cada sitio, utilizar un gestor de contraseñas…

Use strong and unique passwords for every service.

Y, con respecto a los tokens de acceso, considerarlos como credenciales y gestionarlos de manera adecuada (lo que incluye no ponerlos en el propio código).

Otra lectura interesante, Foundations of Correct Code donde se habla de que el código no sólo ha de pasar los tests y las pruebas, sino que estas deben tener en cuenta que el código sea correcto.

En este sentido nos recuerda los conceptos de los contratos, pre y post-condiciones y nos recuerda su historia:

You may well have heard the terms before: contract, pre-condition, post-condition. But you might not be aware of their origins.

Posteriormente, entra en la discusión entre lo que llamamos programación defensiva (si no se cumple lo que esperamos lanzamos un error antes de hacer algo que, a priori, puede ser incorrecto) o bien el diseño por contrato, basado en el principio de que si el proveedor cumple su parte, nosotros devolveremos un resultado correcto.

We have two choices here: defensive programming, and Design by Contract.

…

Defensive programming guards the body of a function or method, checking that the pre-condition holds and throwing an error if it doesn’t.

…

all of the interactions between its components must be correct. A Hoare triple describes a contract between a client and a supplier of a service (e.g., a method of a class), such that the supplier ensures that the post-condition is satisfied, and the client ensures that they never a method or function unless the pre-condition is satisfied.

A la hora de elegir, puede depende de nuestra relación con el resto de proveedores: si nosotros producimos todo el código, hay cosas que podemos (o deberíamos poder) asegurar. En otros casos, tenemos que tener cuidado con lo que hayan podido hacer otras personas.

One final thought on defensive programming vs. Design by Contract, relating to the design of the system as a whole: when it’s us writing the client code, we have control over whether the inputs are correct. When someone else is providing the inputs – e.g., a web service client, or an end user – we don’t have that control. So it’s usually necessary to code defensively at system/service boundaries.

Tampoco tiene sentido conformarse con lanzar un error cuando algo no vaya bien: normalmente el usuario puede que ni siquiera tenga la culpa y nosotros tampoco queremos molestarle.

Offering users choices that aren’t actually available and then displaying an error message when they select them not only annoys the user, but also complicates the application’s internal logic as it now has to handle more edge cases.

De esta forma, es posible que tengamos que usar ambas aproximaciones:

I’ve found the best approach to delivering correct software that’s simple in its internal logic is to design the UX carefully to simplify the inputs, do some defensive programming just below the UI to validate the inputs, and then apply Design by Contract for all the internal logic, with test-time assertion checking in case we made a boo-boo in some client code.

Por ahora Python no es el lenguaje de programación con mejores características de concurrencia (fundamentalmente, el intérprete no es lo que se llama `thread safe’ así que hay que imponer restricciones para que las cosas funcionen Global Interpreter Lock). Esto no significa que no haya primitivas para gestionar la concurrencia y que, en algunos casos, podamos obtener ventajas de la concurrencia.

Por eso (y porque la concurrencia es un tema que me gusta mucho) traigo aquí An Intro to Threading in Python que me pareció una buena introducción al tema, didáctica y con ejemplos, sin olvidar el tema de las condiciones de carrera.

Allí también nos recuerdan que la concurrencia es limitada:

But for most Python 3 implementations the different threads do not actually execute at the same time: they merely appear to.

Y que si queremos ir más allá tendremos que utilizar un intérprete no estándar:

Getting multiple tasks running simultaneously requires a non-standard implementation of Python, writing some of your code in a different language, or using multiprocessing which comes with some extra overhead.

No obstante, es un tema interesante para explorar y siempre podremos obtener las ventajas típicas de la concurrencia, que consisten en poder hacer avanzar algunas tareas cuando otras se quedan atascadas (en operaciones de entrada/salida, o esperando algún evento, …). En otros casos no vamos a obtener una ventaja real, pero siempre está bien utilizar este lenguaje para aprender conceptos que luego pueden utilizarse en otros.

A través de Un ingeniero de Microsoft explica cómo es Windows 10 por dentro: el código ocupa 0,5 TB y se extiende por 4 millones de ficheros llegamos a unos cuantos datos e informaciones sobre las interioridades de Windows 10 que se agradecen, porque no siempre ha sido muy fácil conocer estas cosas.

Como lenguaje de programación se utiliza fundamentalmente el C, aunque también hay código en C#, JavaScript, TypeScript, VB.NET o C++.

Sobre el tamaño, como dice el titular, estamos hablando de que

Según explica Rietschin, el árbol completo con todo el código fuente, el código de prueba y todo lo que constituye el “código fuente de Windows” tiene más de medio terabyte de tamaño, en más de 4 millones de archivos

Muy interesante y para guardar como referencia.

Actualización (2019-09-18): En Which programming language is used for making Windows 10? podíamos leer algo más de información relacionada con el tema.