I used to be very excited about RYF certification, but after looking into the details, I realized that there are many problems with it. RYF does call attention to the problem and makes people think about the blobs in their devices, but RYF certification actually discourages hardware makers from producing new RYF devices and discourages the community from working on freeing hardware.
There are certain components like CPU, GPU, WiFi, Bluetooth and cellular modem, where it simply isnt safe to have firmware which isn’t upgradable, and the FSF is being ridiculous by using ambiguous language in its RYF criteria and not answering my pointed questions as to whether proprietary firmware updates are allowed or not. I repeatedly asked the FSF to clarify its position on this point and I never got a response. The FSF can’t expect any hardware company to design and produce new RYF hardware if it probits firmware updates, because that is a security risk; but at the very least the FSF needs to clarify its position as to whether RYF certification allows updates to proprietary firmware or not. If updates are allowed, under what conditions are they allowed?
Right. And the FSF operating system “endorsement” is even worse since you must not in form or fashion even mention non-free things in it. So the OS can neither include nor point to such upgrades and it can only in a very limited fashion include the tools to do the upgrade (maybe include the tool but must not point to a source where to get the actual non-free upgrade).
Issues with e.g. WPA vulnerabilities were already public and many of these could only be fixed by a firmware upgrade, so the non-upgrade indeed left users in a vulnerable situation. So we are not talking about theoretical possibilities, this has already happened and endangered users.
I totally get that this is a problematic fine line and one has to be careful not to open the floodgates to binary-only hell. But we have to come up with something.
@nicole.faerber I have some questions, hopefully not too stupid ones
What do you think about the BL602@ChriChri mentioned?
Apart from it “only” being b/g/n, has it any problems or drawbacks?
From this comment I gather that it is specifically low-power oriented, which makes sense as it is a new chip, but skipping the 5 Ghz band.
And while WiFi 5 or 6 might be nice to have, honestly, I couldn’t care less about more (theoretical) bandwidth. I care about stable connectivity, preferably even two rooms away.
For huge transfers I’d probably use a wired connection anyway.
What about USB-WiFi-BT-dongles?
No, hear me out I gather we are looking for mid-term viable solutions, something between “give up” and “spend millions on our own silicon”.
So, a quick search turns up a WiFi-5+BT-Thumbstick, tiny, cheap …
So, there should be a pinky-nail sized PCB with USB connectivity in this thing. Yes?
How could we use that (best first)?
source the PCB, attach own antennae and USB (laptop + phone!)
just… put the stick inside the laptop (does that work for the radio?)
have something like a “bay” for dongles on the laptop, so they don’t stick out
At least for that I can say this is based on RTL8821CU and this again needs a runtime firmware, pretty sure. I have sourced and tested a bunch of them and did grind through the kernel drivers looking for the firmware load - and everyone I looked at did load a firmware at startup
The GIT driver you link to for example does it too, if you look into: hal/rtl8821c/rtl8821c_mac.c
Around line 112 is the firmware load (at least one of the spots). I would need to analyze the code deeper to figure out where the firmware actually comes from, i.e. if they load it from the filesystem via the Linux kernel firmware subsystem or if they buried it in hex in some header file (which IMHO would not be acceptable and would also never be accepted upstream (anymore)).
Of course I can not tell if there is really absolutely no chip that does it. But over the years I looked at a lot and so far all tries came up empty.
As for the BL602 this is for sure an interesting project, but not usable for us I’m afraid for reasons I also tried to explain before. Even if we would use it with a freed firmware, once this exists some fine day, we get into regulatory trouble. We could of course try to make use of it as-is (as we could with regular ESP chips as well) and develop a firmware that gets flashed into it using the proprietary bits, but these would raise an eyebrow or two, especially in our PC based products where, and that’s a fact, customers expect at least almost up to date performance - and quite some customers already complain at us about the poor performance of the Atheros. This will then be even a lot worse.
Something like the BL602 or the ESP chips for that matter can be acceptable for something like a phone where huge bandwidth, at least to me, is rather secondary, but where power saving is more important. But in a PC? Meh, no, don’t think this would not end well. And it would still be a significant effort needed to go into such a project since these chips usually can not be used as Linux WFi/BT cards but usually run the whole stack on their own. There once was a SDIO station firmware and even a Linux driver for the ESP8266 but that is now unmaintained and wasn’t really stable, as far as I know.
I work in R&D for a large silicon chip manufacturer. I’ve been there long enough that I can pretty much talk to almost anyone either at the lunch tables in the company cafeteria, or through inquiring e-mails that go outside of my usual area of expertise, to people I know in other areas of the company. Nicole’s assessment of the situation is quite accurate.
A high level marketing person who I get along well with and who I see at the lunch table most days (pre covid), even said that he could arrange a meeting with the company president if we could put together a compelling presentation for my fully-free cell phone SOC idea, while also showing some skepticism by saying that the cell phone chip market is extremely competitive. But he started an email thread that went quite high up the chain in the marketing department anyway, to see what the feedback from others would be. Nothing we could discuss or come up with was compelling from the chip manufacturer perspective. Unless tens or hundreds of millions of dollars in profits are obviously on the table, the free (as in open) cell phone niche market is far too small now. I spoke to and exchanged emails with several people individually also. The consensus is that the Chinese companies have driven the prices down so far that there aren’t any profits to go after in the cell phone market, especially when needing to make large investments. One other marketing person I spoke to used the word “bloody” (a term that probably has a different meaning in the US than it does in the UK. In the US in this context, it’s more like likely to cause financial bleeding and financial injury) to describe the cell phone market when it comes to silicon chips. Also, any investment dollars are competing with other big ROI projects in the company.
I think a lot of them humored me by engaging the topic after they realized that we were talking about a cell phone SOC. The response was generally that their knowing the market, no executive would approve anything to do with cell phone chips. After seeing responses from Directors and Marketing executives and others, I tend to agree with their logic as it relates to the best interests of the company and the careers of those involved.
Also, most of those who I communicated with about this were totally on-board with the personal and societal benefits of free (as in opensource - Todd’s vision) hardware. They really get it. In fact, I suspect that’s why they entertained the idea while knowing as professionals that there was no money in it before the conversation even got very far. But then it was back to reality and the bottom line. We’re all there to make profits for the company.
But if someone thinks there that a closed-source proprietary firmware upgrade is needed to secure their system, then that person has adopted a world view that says their security relies on proprietary software. Is that a reasonable position?
Here is how I look at my system communicating with the world, where the dashed box is my computer (like my Librem 5 or my laptop):
Now, suppose my use case is that I communicate by email and I use GPG to encrypt and sign emails as described in the Email Self-Defense guide – then, I can achieve secure communication despite the fact that the Wi-Fi chip cannot be trusted. I use it, I communicate through it, just like my communication passes throuugh lots of routers and other networking devices before reaching the recipient who will decrypt my messages. Any actors that look at my messages in transit, including the Wi-Fi chip, will not be able to decrypt or distort my messages because they do not have my private key.
If someone says “there is a vulnerability in your Wi-Fi chip, you should install this proprietary firmware upgrade” then my answer would be that the Wi-Fi chip is anyway fundamentally insecure, with or without that upgrade it can still not be trusted. So is that upgrade really critical for me?
I guess my point is that instead of accepting the common view that proprietary firmware upgrades are strictly necessary for security, we can focus on using free software tools in ways that allow us to stay secure without being dependent on proprietary software for security (remembering that the proprietary software may still be spying on us no matter how many proprietary firmware upgrades we install).
Oh, I was in no way suggesting that this would be “strictly necessary” or the solution to security and privacy. But I think we can agree that being able to additionally apply these fixes to known problems would be beneficial? These kind of fixes not necessarily always have to do with security sometime it is also about usability and stability. To stay with WiFi there are known vulnerabilities in some implementations that also allow third parties to either crash the firmware from remote, even taking control over it. Or take the deauther as another example. These problems do not necessarily have to do with security (privacy) of the data sent over the link but also with overall system safety and access to a service. Some other of these things could introduce new features to existing hardware too. Or take the Intel microcode as another example. Just recently we have seen a number of microcode updates, which are of course blobs, which fix CPU vulnerabilities which could even compromise what you point out as your “FOSS core system”. Right now we go around this problem by providing these microcode fixes as part of Coreboot but not all users update their BIOS on a regular bases. But the OS can load microcode updates at startup and all bits and pieces for that are there, just that we can not use them with current PureOS and the FSF endorsement.
Like I said before, I am not at all advocating opening the floodgates for blobs. But I still think that a more flexible and accessible approach than we have now would be beneficial while still keeping our goal of striving for as much free software as we possibly can. I think that in some areas we simply have to accept the fact that it is close to impossible to free them - like the microcode. So instead of limping along with some crutch like hiding blobs somewhere (like microcode in Coreboot) better pull them out in the open so that users get better control over them? Then adding firmware signing (by the user) also gives some piece of mind that these cannot be replaced without the user knowing.
I’m still curious about the internal or semi-interal USB path. That wouldn’t cause trouble for the RYF certification, as I understand it, and would enable using the latest and greatest wireless networking technology.
My non-expert way of doing this would probably involve a cable connected to the existing USB interface making a sharp 180* turn within the space of the connector (so it does not stick out), and then going to a USB wifi/bt board stuck (literally probably glued) somewhere within the laptop case. We’d have to find a board with appropriate connectors for the antennas already in the case in a retrofit scenario, or source adapters.
Amateur radio manufacturers have a responsibility to build radios that do not encourage or support illegal use of the radio spectrum also. There are many books out there that have a page or two for every amateur radio model in the market. Typically, you can follow the instructions for your given model of transceiver, to modify the radio. So you open the radio, remove a diode or clip a conspicuously easy-to-access blue wire or something similar that is very easy to do, per those instructions. Then you put the radio back together. The modification allows you to transmit on any frequency that the radio is capable of transmitting on, legal or not. In most cases, a VHF/UHF amateur radio can then transmit on nearly any commercial or public service frequency in the VHF/UHF spectrum. The desired frequency can then be typed-in to the keypad as easily as dialing a telephone number. Occasionally, you can read articles published by the ARRL, where some idiot got arrested and fined for menacing the police on their own public service radio channels. This kind of amateur radio modification is how they do it.
The point is that if reputable companies such as Allinco and Icom can manufacture and sell two-way radios that allow such easy modifications, then obviously, the bar of legal responsibility for a radio transceiver manufacturer is low. I don’t see why it should be Purism’s job to tightly lock everyone out of the radio chip on their cell phone. A simple and easily circumvented safety lockout should suffice. The goal should be to put safeguards in place, not necessarily to prevent anyone from violating the law.
For over a century now, automobile manufacturers have sold cars that are very capable of routinely violating speed limits, even by accident. No safeguard is even installed by the manufacturer in that case. So there is nothing to circumvent if someone wants to violate the speed laws. I think it is wrong to justify closed firmware blobs using legal arguements that involve keeping the code a secret for the ‘public good’. If necessary, use encryption keys to keep people out of a specific (manufacturer) installation. But still keep the firmware opensource. If someone wants to compile and install different firmware to the radio, at least that is not as easy as just removing a diode, or clipping a blue wire.
I urge purism to not let some supposed mistaken obligation that they may think they have, guide their direction. If Purism is forced to use closed-firmware chips as the only available means to get 4G or 5G chips that will make the phone work, then so be it, for now.
But there is a reason why rooting your own Android phone is not illegal in most cases. People need to continue doing their own development, and not only let big-tech be the only ones doing on-going development. After Purism grows up, is Purism going to become ‘big tech’ too? Maybe I can modify my Librem 5 phone to also let me use it as an amateur radio in the GHz frequency range. Such use and experimentation would be completely legal as long as the phone owner also has an amateur radio license. Maybe the radio firmware code could also be used by a hobbyist to make significant improvements if that code stays open. If it’s not open then bad things eventually happen. We don’t need the politics of law enforcement to be coded in to our firmware, even if the reason seems to be logical at the time. Let the law-breakers suffer their own fates while the public maintains access to the code. Hopefully, Purism never buckles to the political forces that say “the public can not be trusted with this information”.
Ha, totally get your point
Though I am not sure if we can really operate like this, and honestly I would have to ask a lawyer what this would imply or how this would work. How do these amateur radio devices get certified, I mean CE/FCC? Because this is something we most definitely have to do or else we get into real trouble. And I think we as a company would also have a responsibility to make sure that devices and their functions get into the proper hands. I know e.g. quite for certain that I, who am not a licensed HAM radio operator, am legally not allowed to operate such devices - even if I knew what I was doing etc. I think my point here is that we as a company can not knowingly put devices in the hands of customers of who we know can not legally operate these. We could of course try to cover our butt by putting some kind bumper sticker on it “Only to be used by licensed HAM operators!” but I am not sure if this would a) be enough and b) would really solve the problem.
Like I said before my point in this discussion is not to turn 180 degrees and just use all closed and proprietary stuff, not at all. My point is rather that with our current approach we already accept binary blob firmware but we expect it to be hidden away from the users in some storage either not accessible at all or only with very special tools (be it hardware or software). We have these blobs already in pretty much all of our devices, it’s just that we do not see them.
Given the choice between not being able to see them at all and having the very same blob but on my harddisk under my control, I would rather go for the “under my control” way. Next step after that is of course making this blob free, i.e. replacing it with something free. Freeing it, to me, starts with seeing the blob and being able to analyze and eventually replace it with something as I see fit.
I also very much like the idea of freedom you are describing. These are the freedoms also enshrined by the FSF, the freedom to use, study and modify as you see fit. This is indeed essential and we will for sure never give up on these rights especially for the software we make ourselves.
Each radio service in the US (and presumably in other countries) is governed by a set of federal statutes that regulate that specific radio service. The only one that Purism needs to comply with, is the one that governs cell phones. If an amateur radio operator modifies the phone to operate on the amateur radio bands, then all legal compliance issues are on the licensed amateur radio operator personally and not on Purism. The amateur radio services are unique legally in several respects. Amateur radio is the only radio service in the US that allows the radio operator to use equipment that is not “FCC type accepted”. The hardware does not require any certification at all in the case of a radio operating in the amateur radio services. That allows experimentation which is a big aspect of the amateur radio service. An old marine radio or police radio can be tuned to the amateur radio service frequencies and used there legally. The same goes for a phone. But the reverse is not true. In most cases (very few exceptions) amateur radio equipment can not legally transmit outside of the amateur radio frequencies because the hardware does not have the proper certification to operate outside of the amateur bands. So all Purism has to do is to get the phone licensed in the cell phone services and then Purism’s job is done.
The only remaining question is about how far Purism must go to prevent the phone owner from modifying the phone to make it be capable of illegal operation. The standard in the VHF/UHF radio services (for example) is quite low. The operator controls on the face of the radio must not allow illegal operation. If someone opens the back of the radio and alters the circuit board, they may be violating the law. If someone reprograms the radio, they may be violating the law. The radio manufacturer is not responsible in either event anymore than the Ford company is responsible if someone violates the speed limit in a Ford vehicle. If the person doing the modification work is an amateur radio operator who is tuning the radio to operate on the amateur radio bands, then that action is completely legal.
I don’t think that Purism is responsible for how their phones are used, as long as they are shipped with the intended user controls to not allow illegal operation without modifying the radio hardware or software or firmware. Many people in this forum could make such modifications. But once again, Purism is not tasked to be the police. It just shouldn’t be easy by accident, to use the radio illegally.
The reasons this matters is that the amateur radio services are granted small slivers of radio spectrum space in several dozens different parts of the overall radio spectrum. All it takes is one sliver of amateur radio spectrum space next to a 3G, 4G, or 5G radio band and the radio experimenter has what they need. If the chip is 5G (for example), and if a sliver of amateur radio spectrum space exists just above or below the given 5G band, then the experimenter may be able to tune the 5G chip to operate in that GHz amateur radio band, just above or below the cell phone frequencies. From there, experimentation might create new modulation types that could be incorporated in to other radio or cell phone services. I can remember a time when no one had cell phones except for the ham radio operators who could make calls in to the public telephone system from their hand-held radios. Back then, doctors and other high-importance professionals carried pagers, while amateur radio operators could initiate phone calls from almost anywhere.
Also, the people on this forum are not typical of what Purism’s average customer will be like after Librem phones go mainstream. Android phones would not be what they are today if not for the developers who often root their phones. But everyone does not root their phone. This compares to how some people might experiment with their phone’s radio chip, while most people will not. For those who have the proper personal licenses, they can do it legally.
That still comes up against the key question: does the device require the driver to load firmware in order for the device to become operational as a WiFi and/or BT device? (as discussed above)
Right, this is the main question, i.e. the driver firmware load, and to my knowledge all current USB WiFi chipsets also require this blob download at startup.
Having USB devices internally is no black magic or anything new. The Bluetooth in the Librem laptops/Mini is also a USB device sitting on the M.2 card. So USB itself would not be the problem. But the firmware requirement would be.
persuade one WiFi device manufacturer to store its firmware locally to the device and not require firmware load at all?
reverse engineer the firmware for one WiFi device?
persuade RYF to lower their standards?
abandon the goal of RYF certification?
engineer a front-end chip for a USB device that passes through most USB stuff in both directions but intercepts firmware loading, taking a placeholder firmware file from the host, ignoring that file, and substituting that file with locally stored firmware before passing it on to the USB device?
Almost. So far we have not even tried to get RYF for the PC (Intel) based products because it will be close to impossible due to the FSP needed to get the Intel booted at all. So RYF is less of a problem here.
The bigger “problem” is PureOS and whether we want to accept any form of blobs in there and if yes under which (maybe strict) rules. Right now the FSF endorsement of PureOS rules out any form of blobs, even pointing to a source of blobs from the OS is not allowed (which is BTW also the reason why Debian itself is not FSF endorsed because it “advertises” the non-free package repository). Some form of this non-free repository would be at least one of the possible solutions to the problem - with strict rules and guidelines for what can go in there and what not. But in that very moment we would loose the FSF endorsement for PureOS.
The other possible solution would be to implement some other form of storage into the devices which can store the firmware and which gets mounted at runtime. While this would solve the problem with the FSF endorsement it has other drawbacks, like how will updates to the stored firmwares be distributed then if PureOS must not offer any means to retrieve and install those (which again would be “advertising” as far as I understood the FSF endorsement)?
A method we have discussed internally could involve Pureboot. We could store the firmware as part of Coreboot’s CBFS and inject this in the booted system. This would then also automatically add verification to it. But then the only way to update the firmware is by updating PureBoot. And storage is very limited, we could only ship exactly the firmware needed specific to our hardware - if you would, say, change your WiFi card or add some other component then this scheme would break.
I can see all points, the benefits and detriments for all of that and none is the silver bullet we are looking for, I’m afraid. It’s all more or less good crutches. My favorite option right now would be a well curated non-free package repository only for these firmware blobs with pretty strict rules for the packages going in there - like “no blobs/firmwares that would need to be executed on the main CPU” and maybe some more of such rules. I would also like to limit these to the absolute minimum, as much as we can - no floodgate opening. Only parts strictly necessary, e.g. none of the Intel i915 blobs, the system works well enough without them, no Realtek Etnernet blob, the Etnernet (in the Mini and Librem14) works fine without it etc. But should at any point e.g. a security issue should be revealed that can be mitigated or resolved by such a blob, we would need to very thoroughly think about it again. So far this has not, to my knowledge, happened but it is possible and I would like us to be able to make the fixes, as much as would like them to be open and not in a blob, easily and conveniently available to our users and customers. Since most rely on the packaged and automated updates through the OS this is probably the best, most convenient and also safe approach.
Yeah, right, kind of
Though I also understand the FSF’s position, I think it was also mentioned here in the thread before. The FSF needs to take the hardest and most extreme possible stand, the strongest force that everything else can gravitate against. I honestly appreciate that because I also believe if such forces would not exist, nothing would move. Nevertheless of course such position is not almost pragmatic. It helps the greater good in the long run.
This conversation is maybe why it is time to admit that FSF’s view on the matter is extremist and impractical. By creating such arbitrary barriers (when viewed through the realities of the world we live in) by which Purism is allowed to operate you are damaging the company’s ability to help customers benefit from the freedom your products provide.
Why is the narrow definition provided by the FSF even necessary for your products to represent what Purism believes in?
The position of the FSF is, like Nicole explained, extremist on purpose. It’s impractical because we as the industry made it impractical, but the FSF is taking a stance to attempt to undo it and influence our reality. It’s an ideological stance that’s meant to prevent others from getting complacent.
Speaking for myself, but I also believe a large part of Purism, this is exactly the position we believe in, even if it’s not easy to reach yet. Settling for something less without the end goal annoyingly dangling in front of our noses would be just that: settling.
