No Food for Thought

By now, everyone has consented to cookie usage hundreds of times. All technologists are aware this phenomenon was started by the Privacy and Electronic Communications Directive 2002/58/EC, also known as the ePrivacy Directive (ePD).

But why is it you had to consent thousands of times? Sure, the web is a chaotic network of way too many websites. I had about 5 cookie prompts just while I was researching this post. But just before that, why did I have to also consent to cookies when scheduling my fifth vaccine against SARS, using the same browser profile, and the same website? Can all websites be so bad?

It turns out the answer is mostly negative. The main reason is unfortunately legislative; according to 2 sources I found, the EU's maximum consent duration is just 1 year.

According to CookieYes's "How long does cookie consent last?":

According to Proton Technologies AG's Cookies, the GDPR, and the ePrivacy Directive:

Is that to say we are doomed to endless clicking? Not quite, since a software solution is apparently possible. The UK's 2012 Guidance on the rules on use of cookies and similar technologies already stated:

I just wish at least one browser will get there before more decades go by. How good would it be to go back to the good old times...

Quelle stratégie un pays comme le Canada, devant des précipices démocratiques, environnementaux et économiques, devrait-il choisir? Simplement adopter le principe pollueur-payeur serait, bien entendu, beaucoup trop efficace pour se faire sans controverse. Mais peut-on au moins cesser d'encourager la pollution, en cessant d'accorder aux pollueurs des subventions? Ne serait-ce pas un bon premier pas pour ralentir la dégradation environnementale tout en réduisant le déficit?

Comme l'explique Québec Science dans un éditorial de Mélissa Guillemette, il est bien plus simple d'user d'un brin de rhétorique que d'écouter la science. Le gouvernement évite ainsi une gestion de changement, et―qui sait―pourrait arriver à survivre quelques années de plus.

Il est permis de rêver à ce que notre pays serait devenu si nos prédécesseurs s'étaient autant démarqués en matière de populisme. Peut-être serait-on arrivés à lutter contre le tabagisme bien plus efficacement si, au lieu d'instaurer une taxe favorisant la contrebande, on aurait tout simplement choisi de subventionner Imperial Tobacco. Après tout, ce sont bien à eux que l'on doit les regrettées Player's Lights!

Ben Rothke asks if there's a shortage of information security professionals. I found his piece very interesting, as I've been puzzled by the crazy flow of security openings. In the provincial government, it must be something like 10 security openings for every development opening!

However, the impact in my context is quite different. The employer accepts even some of the poorest applicants, either because it's indeed unable to evaluate aptitudes, or because public sector rules force it. I've worked with a colleague clueless not just about IT in general, but even about security, who was paid more than I did, as a so-called "expert". Indeed, an incredible share of the Quebec government's security openings offer an expert bonus.

But the most important crisis is not in information security jobs. It's in the security of generalist IT workers. Employers just don't grasp how security works. People who don't know IT just think of it like they would think of residential security.

Similarly, most people think of IT security as a feature, rather than as a quality. A feature which can be added. Unfortunately, such IT security features tend to be heuristic and buggy/costly. It's more accurate to picture security as low insecurity than as a sum of measures. And insecurity is a sum of flaws. Real security comes when the entire information system is built with security in mind, by IT workers who all keep flaws in mind.

The problem is not so much that we don't have enough resources for security. It's mostly that we don't have them at the right place and time. Getting a 10 M € budget to overhaul security after a major breach will get you nowhere close to where an extra 2 M € over the project's life would have. When a system's architecture was rushed due to lack of resources, patching gets costly and nowhere as efficient as a rewrite, which would be too risky.

What we do need is developers and other IT workers all putting security first. Not just as an afterthought (at best). It's been called the security-first mindset, security-first culture, or developer-first security. But for security-first to happen, developers need the means first. As long as development is rushed and QA a lucky bonus, we will keep producing bugs of all kinds. Developers need to have the necessary knowledge and to feel responsible. And for this, their reputation needs to track their full record.
As long as most IT workers will stay ignorant or careless about security, organizations will keep getting hit. If you want peace of mind, prepare for security early.

Juste avant une rentrée scolaire chaotique, le ministre de l'Éducation du Québec tentait de rassurer la population avec une déclaration aussi inquiétante qu'impuissante :

Le mot de la rédactrice en chef, Claudine St-Germain, dans l'édition d'octobre de L'actualité1 illustre bien que cette rentrée et cette affirmation surréaliste ne sont pas des exceptions, mais malheureusement bel et bien représentatives d'une situation généralisée qui―on ne peut qu'être d'accord sur ce point―doit effectivement changer!

Le télécopieur, devenu une aberration, reste omniprésent dans le système de santé québécois. Mais comme un court article du Dr Alain Vadeboncœur1 explique bien, le télécopieur n'est pas une maladie, mais plutôt un symptôme.

Le résultat d'un manque de vision d'ensemble, et d'une fragmentation. Initialement, celui d'établissements adoptant des systèmes différents, sans réfléchir à long terme. Et maintenant, celui d'une province trop petite pour se permettre une solution… avant encore bien des efforts gaspillés et de nombreuses tragédies.

For well over a decade now, handheld PCs have been one of technology's hottest topics. In 2021, more than a year after my Motorola Nexus 5X's Android had lost its security support, I decided it was time to replace it. The pandemic and the fact that I had never purchased a handheld was one reason why shopping the replacement took so long, but I never expected it would take me nearly a year. Indeed, the options were so bad that I decided to wait until Google would release its Pixel 6a (which―of course―was considerably delayed). The main reason was durability. Most phones would barely offer a meagre 3 years of software security support and the Fairphone was unavailable in Canada. The Pixel 6 finally offered a reasonable 5 years of security support, so I finally bought a Pixel 6a in July 2022.

While it's much better than my 3 previous handhelds, my new phone is far from perfect. Bugs were there on day 1, and the fingerprint reader is still so much less reliable than on my Nexus 5X. Overall, defects are visible each week. Yet, I am pleasantly surprised to hear of the progress Google is making this month. Not so much by releasing Android 14, which is a modest improvement, but rather with the Pixel 8, which comes with the open-source Android and 7 years of security support. As Android 14 is showing, the evolution of handhelds is slowing down… which allows their maturation to start, and support to finally adapt to this new status.

I'm eager to see Google release affordable editions making this (early) maturity widely available, and hoping that by the time I replace my Pixel 6a, 7-year support has become the norm in a somewhat sustainable market where durability is an expectation.

The above image is probably copyrighted.
Thanks to my friend Sahar for sharing this, and to its author, which I unfortunately don't know. I assume the text is old and would be challenging to trace. As for the presentation, the bottom label suggests it may come from the book The Memeing of Life: A Journey Through the Delirious World of Memes by Kind Studio, but I am unable to verify that. If you know the origins, please let me know.

Kune ni povos has always promoted unity while fighting fragmentation. Yet despite exceptionalism's impact on unity, I was not quite aware that exceptionalism can be the norm at every level. A 1977 study already showed that 94% of college teachers in the USA thought they were better than the average. Wikipedia's article on illusory superiority has a lot more statistics and details about this phenomenon.

A highly interesting article from the BBC associates self-inflation with individualism and exaggerated self-esteem. If the BBC's description of Hokkaido is accurate, it would make sense that the USA, which was largely populated by self-confident and ambitious settlers in the recent past, would remain a very individualistic country. It would make sense that teachers from the USA would be the most prone to overconfidence, since the USA are the most affected by individualism. It would also be predictable that less diverse populations as those in Asia would diverge less in the way each individual defines Right and Wrong. And indeed, the same article claims that self-inflation is almost completely absent from collectivist societies in Eastern Asia.

But exceptionalism is far from being limited to the individual. Some collective forms of exceptionalism will pit a continent against another, a country against its neighbors, a province against a neighbouring province, and even a city against another city a few hundreds of kilometers away. And let's not forget linguistic exceptionalism, racial exceptionalism, male chauvinism, nor human exceptionalism. If individualism increases individual exceptionalism, it might seem logical that it also favors state exceptionalism. If so, USA exceptionalism should be no surprise. Yet, exceptionalism can also be found in Eastern Asia, no further than in China.

At this time of increasing international tensions, it would help to know what exacerbates collective illusory superiority and what avoids it. Indeed, if a country managed to heal from exceptionalism, I would suggest it to modestly offer the planet its secret cure, hoping to end an exceptionally dangerous pandemic.

More than a decade ago, Greg Kroah-Hartman started offering some Linux versions with significant support. Linux 2.6.32 was designated as a "long term" support release, even though the term was just about 2 years.

Fast forward to today and "longterm" releases have actually become long term, i.e. they provide 6 years of support. That is, until now. While I have no doubt those releases will keep being marketed as having "long-term support", that support is actually being cut back to just 2 years.

The first argument provided ("There's really no point to maintaining it for that long because people are not using them.") is doubtful to say the least, as the most popular GNU/Linux vendor still supports Red Hat Enterprise Linux 7's Linux 3.10, older than the oldest supported vanilla Linux. The second one ("Linux code maintainers are burning out") though, is certainly true. Indeed, Coase’s Penguin warned about the challenge of integration even before Linux 2.6 released:

And unfortunately, our global governance certainly hasn't gotten us any closer to a solution for that actually long-term problem.

In computer science, we're often taught that security is only as strong as the weakest link in the chain. This weakest link principle is true, but looking for that weakest link is not always the best way to harden a system.

Microsoft's analysis of how China (Storm-0558) breached the email accounts of senior USA officials earlier this year is an interesting case of cumulative mistakes, where a series of limited issues results in catastrophic damage. Even though the analysis is not confirmed and some details are missing, it's interesting to have a high-quality analysis of a real-world example of an attack exploiting multiple weaknesses:

1. an unstable software component crashing
2. a race condition causing sensitive data to be included in the crash dump
3. that crash dump being moved to a wider organizational network (the debugging environment) following a failure to identify its sensitivity
4. compromission of the corporate account of an engineer with access to the debugging environment
5. an authorization bug allowing a consumer key to access "enterprise" email, apparently as a result of unclear API-s

As a senior developer having served numerous organizations for various projects, it's easy to relate to most of these weaknesses. And yet, it's easy to imagine how reporting most of these issues could have easily been brushed off by management as unlikely/alarmist, failing to see the risk from cumulative negligence.

Security is about strengthening each link, but it's also about keeping security in mind at all times.