Yeah, hmm… very unsatisfactory, totally get it. The only kind of solution I can offer is to install the binary firmware for the ar3k Bluetooth part, I’m sorry. The problem is with the FSF and the PureOS endorsement which we have not been able to straighten out. We must not include any blobs in PureOS and we must not endorse any sources that would carry such blobs.
While I understand the goal of it and also support that this puts us into a very VERY difficult situation - and this Bluetooth issue is just the tip of the iceberg! Pretty soon we will run out of WiFi chips that will work without binary blobs! And then?
I think this binary blob firmware issue needs to be thought over. It does not fit into the current hardware world anymore. Most hardware is full of proprietary firmware but this stays unnoticed because you do not see it - starting from the touchpad to the DP-HDMI transceiver to the battery charge controller, the SD card reader etc. etc. - there are at least a dozen firmwares hidden in the laptop that are not free. But these are assumed to be “OK” since they come with the hardware, in some form. But actually by hiding them from the user this also keeps them out of control - no way to see them, analyze them or update them. For some of these firmwares this can even impose a security risk as we have seen in the past (not with Purism hardware luckily) with WiFi exploits that were only possible to fix in firmware. So hiding the firmware in some ROM can actually be harmful.
So I am wondering how we can move this forward in a reasonable way?
Of course we do not want to give up our goal to free everything! As soon as and as good as we can.
But our corridor for hardware chips not requiring firmware blobs is getting more and more narrow and for some it is close to impossible to develop free firmware. Soon we will run out of ATH9k WiFi cards and there are no chips on the market than can be used without the blob download at runtime. None, seriously, I am looking literally for years now.
With the FSF’s super strict policy we are hurting ourselves and also users by cutting us off from a lot of hardware.
So the question is what can we do to move forward?
I do not at all want to preclude anything here, there is no decision made, the following is just a very personal train of thoughts (and especially NOT a Purism policy change, OK?).
I would be in favor of rethinking the binary blob firmware situation. What is the real goal? What do we want to achieve with a blob policy? What are certain risks we want to mitigate with it? What are longer term goals? Are there possible security threats? Etc. So first bring all that on the table and then discuss possible new solutions that can address these concerns and reach these goals.
My personal view on this is…
Soon there will be no other choice than to support binary blob firmwares - or we will loose a substantial part of our functionality (like WiFi). Binary blobs in themselves are not harmful - it is the same proprietary binary if you include it in some chip or on your harddisk, does not make a difference (concerning the content and its purpose). Having the blob on storage can have security implications. It could get replaced without the user’s notice. But that could get addressed by signatures etc. Blobs in general could include code that could access main memory - think of peripherals like an integrated graphics chip which has access to main memory. We may not want to allow that, so a new rule or barrier for firmware blobs could be where it is executed and which kind of access and control the main operating system can have over that. And finally of course if such blob would need to be executed by the main CPU that also runs the operating system and applications. Here I would say is a clear red line, this would not be acceptable. Having the main CPU take the binary and shove it into some chip, maybe OK, but not execute mystery code, no way.
Something along these lines. I could see something like Debian does, having a non-free repo that contains such blobs. Plus maybe implementing a system so that a user can sign these once they land on the system, with his/her own key and that only properly signed firmware can get loaded (I think we could implement that along with a necessary chain of trust using the LibremKey). And to only provide firmware of course that are vetted against rules like “not being executed on same CPU running user software” etc.
I would be very interested in more opinions and especially the reasoning behind these!
Like to share?
Maybe with an open discussion we can develop a new set of rules that properly address concerns while keeping access to current hardware.
Cheers
nicole