Good to know -- issue 2021.02

by Ciprian Dorin Craciun (⁠ciprian.craciun@gmail.com⁠) on 

Articles and tools I've found interesting in the last few days.

// permanent-link // hacker-news // index // RSS

About "Good to know"

Each morning during my "coffee hour" I read a couple of IT related articles (and other topics) from various sources. (OK, I admit, usually it's a couple of hours...)

And each couple of weeks (although in reality so far it was months) I intend to create a note of the most worthwhile articles or tools that I've encountered.

(Please note that I don't usually just copy-paste links I've found on Hacker News, although some of these links might have been found starting from such links.)

(for the internet citizen)

In the light of the NSO Group revelations with regard to exploits against up-to-date Apple and Android devices, Matthew Green has written a nice article against nihilism in the security world that explains the perils of just shrugging off these kinds of situations.

In essence, it is true that security is hard, especially given how we like to buy needlessly complicated things, but in the end we need to ask for (and pay for) more security from our vendors.

Why? Because if we don't, then it's a race to the bottom...

(for the policymaker)

In an article over ACM Queue, Poul-Henning Kamp (author of Varnish and FreeBSD contributor) advocates to policymakers to create some form of investigative body that should intervene when major (negative) technology related events happen that impact the public, the society at a large scale, or worse human loss.

A good examples of such events are massive private data leaks, like it happened with Equifax or the NHS, the Facebook / Cambridge Analytica. Moreover, these investigations should also cover failed deployments at governmental scale.

More interestingly, the purpose of such investigations is not to find culprits, but instead to find the mechanisms that were not in place, that failed to work, or anything that we can learn from.

(for the open-source producer or consumer)

This one took me by surprise, although I do follow closely open-source licensing topics...

Bradley Kuhn provides some interesting history about one of the requirements of GPL that I wasn't aware existed, namely that vendors (especially in the case of embedded devices or physical products) not only have to provide access to the source code of (modified or not) GPL code, but they also must make sure that the users have access to the proper documentation, scripts and other details that allow a user not only to build but also install the resulting binaries.

Moreover, GPLv3 actually goes even further, and it forbids the vendor from crippling the product in case it detects a patched version of the GPL covered code.

Interesting...