news
Security and blobs, by Alex Oliva (GNU Linux-Libre)
Reprinted with permission from Alex Oliva.
Linux-libre turned 18 recently, and I'm told there are still some people who try to pass as security experts who disapprove of the refusal to load binary blobs that claim to fix security problems.
I kind of understand the appeal of security bug fixes, but delivering them in the form of binary blobs mean that the one who accepts them has to trust them blindly and to give up any pretense of security from the vendor, and that seems to be a problem that many pretense security conscious minds seem to disregard, for whatever reason.
At the same time they advise people to not open messages from untrusted senders, and to not install random programs even when they claim to offer security improvements. They even criticize people who fall in such traps, while pushing others to do just that!
Sure, in one case it's possibly an evil anonymous attacker, while in the other it's a well-known active corporation in the enshittocene, thus also evil. Thanks, but no, thanks, I'll take neither.
What these people don't seem to want to understand is that there is a significant risk in granting the vendor (just like to anyone else) a new round of control over your computer, especially over a component that can access pretty much everything you do. The risk is not only for your freedom, but also for your security.
When there is a known, exploitable vulnerability in your computer, plugging that hole with a blob may seem like a lesser risk than leaving it unpatched, even if the blob brings with it unknowns (other security holes), risks (new backdoors, new forms of remote control), limitations (new license restrictions, "improvements" that stop you from doing things on your computer that the vendor doesn't want you to do any more), and known downsides (slowing down your computer).
If they allowed you to inspect the changes, to choose which ones you want and which ones you don't, to make further improvements yourself, to plug holes independently from them, then the conclusion could be very different.
But they don't, because they don't respect your freedom. This means they don't want you to have defenses against their control.
They might even care about your security against others, but clearly not about your security against themselves.
If you have already mitigated the risks from the known holes that the blob purports to plug, then the only effects of the blob on you are negative: exposing you to unknowns, to risks, to limitations, and to its known downsides.
It's a net negative, even security wise.
I suppose the miscreants can't picture someone who mitigates the potential security problems brought about by CPU bugs by not allowing random programs from random third parties to be installed and run on their computers, not even through web browsers, and by only installing programs known to serve their users and from trusted sources. Some of us even audit changes ourselves!
For them, it's probably easier to tick a box and then go about recklessly running nonfree (because they run under control of the remote server) programs on their browsers, or installing and running other pieces of software remotely controlled by third parties, whose behaviors they wish to contain somehow.
But for someone who cares about freedom to the point of meticulously selecting hardware that will run with only free software, allowing such nonfree web blobs to run is undesirable to begin with. Installing nonfree programs that don't permit auditing is also out of the question.
These choices are for freedom purposes, but they are also a form of security in depth that miscreants seem unable to conceive of. That these freedom defenses also mitigate security issues is a welcome bonus.
That misguided security and freedom miscreants egg their own faces by promoting security-risking and freedom-denying blobs, because they can't see that newer blobs bring newer problems, is just priceless.
So blong, █
Copyright 2007-2026 Alexandre Oliva
Permission is granted to make and distribute verbatim copies of this entire document worldwide without royalty, provided the copyright notice, the document's official URL, and this permission notice are preserved.
The following licensing terms also apply to all documents and postings in this blog that don't contain a copyright notice of their own, or that contain a notice equivalent to the one above, and whose copyright can be reasonably assumed to be held by Alexandre Oliva.
This work is licensed under the Creative Commons License BY-SA (Attribution ShareAlike) 3.0 Unported. To see a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.