I understand that PureOS and other FSF-endorsed distros use a version of the Linux kernel that doesn’t contain binary blobs. You can also install the Linux-libre kernel on other distros to do without binary blobs. So far so good.
I don’t understand how the standard Linux kernel handles these blobs. If you choose to use the standard Linux kernel on a Librem laptop, since the laptop doesn’t require such blobs to run, do these blobs ever get activated? If they don’t, is there still a security risk?
depends where the blobs are and what the actual code inside does … who wrote it … what the intention was … the magnitude of the scope etc.
but that’s the thing with obscure code - you can’t be sure of anything …
Most distros only install the binary blobs that your hardware requires. It is the job of the installer to detect the hardware that your system has and install what is needed to run on your hardware.
Some non-free packages will install for a whole class of hardware, so you can get extra blobs that way. For example, Debian’s firmware-iwlwifi package places 20 files in the /lib/firmware/ directory for every type of Intel WiFi card, but only one of those files is used to pass proprietary firmware to the one Intel WiFi card installed in your system when it boots.
However, if you install Mint or Pop!_OS on your Librem 13/15, I doubt that their installers will select any non-free packages for installation, since the Librem hardware doesn’t need non-free packages to function.
As for proprietary software like H.265 codecs, Microsoft fonts or Adobe Acrobat Reader, almost no distros include that kind of software by default, except for a few minor distros created for commercial mobile devices which are sold with Linux preinstalled.
Proprietary firmware and proprietary drivers are only used if your system is configured to use them. Malicious code or a hacker might modify your udev rules or use modprobe to execute a binary blob, but that is unlikely to happen if your system is secure.
Also proprietary firmware is less of a threat because it is basically just passing a stream of binary code to a component when it is initialized, whereas a proprietary driver is loaded into the Linux kernel and executed without the restrictions of user space. For this reason, Google is encouraging the use of user-space drivers for greater security in Android, but Linux doesn’t do this.