> doing what they believe is best for software freedom

It is quite self-evident that not being open about the existence of proprietary code is not the best for software freedom.

I know about their certification process; my entire argument is that their criteria are terrible and the lack of transparency about specific devices and what firmware they contain deceptive. You bringing up their criteria repeatedly isn't helping you counter that point. This silly loop of "The criteria suck. / These are the criteria." doesn't get us anywhere.

If the FSF believe in software freedom, why are they not informing their users about the nonfree software that exists in the devices they sell as "Respects your Freedom"? I'm not saying "why are they certified here"; fine, they have their rules. Why are they not documenting how these devices interact with those rules? Why are they obscuring all of this? What do they have to gain by keeping people in the dark?

To me it is just very clear that they're doing this because they are trying to build a narrative that is different from reality, and the only way that narrative works is if people don't discover the problems with it. Your opinion may differ, but everything I've seen about the FSF's behavior in recent years points towards that. If they wanted to be honest there would be no reason not to document those firmware blobs.

arguing that FSF is some crazy sect or a religion is certainly not constructive to improving what they do

i think that how you framed your concern in this last point is valid from a security point of view. as someone who values knowing security implications i support the argument that they should improve their work on security matters. in saying that, to me FSF is certainly no worse (i would think alot better) than closed source vendors, including ms, apple, intel, nvidia etc as far as making their users aware of security problems is concerned. i actually think that every device should come with a cigarete packet style label that says "might include backdoor inside", not just FSF products. in fact, maybe if only FSF did this, it might create an impression that only their products have this issue

See, the funny thing is that Apple's M1 devices are less backdoorable than the FSF's "Respects your Freedom" laptops. That's because unlike those obsolete laptops, Apple's designs actually firewall off all the blobs and coprocessors using IOMMUs, and those IOMMU configurations are introspectable by system software so it can confirm they are correct and not granting too much access. That means if you boot Linux on an M1, and you check the IOMMU configs (most of which are not locked, but those which are are readable), you can say "yup, this isn't backdoored". There is also no nested virtualization support on those machines, and the design of ARM virtualization makes it impossible to "hide" a secret backdoor hypervisor. There is also no ME or any other hyper-privileged software. On top of that, the fact that Apple uses code signing for their entire boot stack means that only they can theoretically (though as I said, in practice detectably) backdoor your laptop - that's much better than the RYF laptops, which have no security and therefore anyone in the supply chain can backdoor them. Oh yeah, and all the post-boot blobs on M1s are stored in the filesystem or readable Flash memories, so you can actually audit them, unlike all those microcontrollers with LPC access to all system RAM on the RYF machines. That's just nasty, the perfect design for an invisible backdoor.

So yes, the FSF is actually worse than closed source vendors because they are promoting ancient laptops with poor isolation and no security mitigations, while Apple has spent the past 15 years building a secure platform. You may not like some of their reasons (e.g. locking down iPhones)... but in the end it results in significantly better end-user security than a "Respects your Freedom" device. And you can put Linux on those Macs and run a fully open source kernel and userspace - not very different from those laptops in the end. Think about that.

Of course, I am very happy to talk at length about the design of these machines with everyone, and I want all the users of my software to be aware of these things (yes, there are a ton of blobs here - the amount of damage they can do is less than the blobs in the RYF laptops, but they still exist), as well as the things we don't know (e.g. some of the IOMMU configs grant full access to a few hardware streams; we don't know whether those streams are actually controllable by a coprocessor in such a way that it would make it backdoorable, but we'd like to find out and if it is, that would be a firmware bug to report to Apple). I believe that in order to make an informed decision, users need to have all the information.

>FSF is actually worse than closed source vendors because they are promoting ancient laptops with poor isolation and no security mitigations

but they are promoting such devices on ethical concerns, not on security concerns. they are not deceiving anyone

>Apple has spent the past 15 years building a secure platform. You may not like some of their reasons (e.g. locking down iPhones)... but in the end it results in significantly better end-user security than a "Respects your Freedom" device

you mentioned FSF fanboys before. there are way more Apple fanboys who are convinced that their Apple products respect their privacy and that their devices are impenetrable. what is worse, Apple markets itself based on this grotesque misperception!

if security and privacy is a vital concern for people, Apple devices are NOT products that should handle their security concerns! you promoting Apple as secure makes you guilty of the very thing you accuse FSF of actually

i would absolutely love it if there is a public non-profit organisation like FSF that is security/privacy focused - eg Secure Software Foundation - that would employ security experts to analyse and audit security and privacy of all software, free and non-free, and of course always open their findings immediately. moreover, i would definitely hope that such an organisation would be as autistic and unwavering toward open security and privacy as FSF is toward software freedom :)

the fact of the matter is, while you can support both free and secure software seperately, they are seperate matters. it is possible to come to a conflict of interest type scenario. secure-software and free-software, although often sharing the same concerns, are simply not the same thing

> if security and privacy is a vital concern for people, Apple devices are NOT products that should handle their security concerns! you promoting Apple as secure makes you guilty of the very thing you accuse FSF of actually

You're mixing up software and hardware. I have no strong opinion on the security of Apple's (macOS) software from a user perspective. It's a proprietary OS. It gets some things right and some things wrong. There have been privacy concerns (e.g. the CSAM mess). I use it for browsing the web sometimes, but I wouldn't make it my main OS.

But Apple deeply cares about platform security, and notoriously, iOS devices are some of the most secure consumer devices available. This isn't marketing bullshit - their designs are actually that good, which is something I can say as a security professional. You may or may not agree with their motivation, which ostensibly includes both customer security and keeping an iron grip on their iOS devices. But the end result is they have built excellent silicon designs with advanced security features and a very security-conscious architecture throughout. The same stuff that makes it hard to jailbreak iPhones. And so now that they stuck them in Macs and unlocked the bootloader, would I buy one? Of course. And put Linux on it. And so should you*, if you care about security. There really isn't anything else done nearly as well as these things, at least not at a performance level we'd consider decent in 2021.

Yes, it might surprise you coming from Apple, but it makes sense because they did this for their own benefit. It just so happens that their motives end up with a result that aligns with what I want. And so I'll take it, thanks.

I still won't use an iPhone, though.

* Okay, maybe wait until we're done porting things and it runs well.

fair enough. i value your opinion on the matters of hardware security and i am definitely not going to pretend i am an expert. i know you know your stuff. my point is that fighting for free software and fighting for security (software or hardware) can diverge

i think FSF fights against non-free software because it considers it an evil for a society. i have no problems them fighting this fight, and i dont see any other candidates able to fight that fight on their level. i think that people who care about free software should at least respect them

on the other hand, i think security and privacy is a seperate fight, extremely important. if you form an organisation that defends security and privacy as much as FSF defends free software, i will definitely support it and you

> only they can theoretically (though as I said, in practice detectably) backdoor your laptop

No, no no. This is wrong. You don't need a nested hypervisor to make an undetectable backdoor. If you you audit all network traffic from a separate device, most backdoors are detectable, because a backdoor wants to have some effect that goes outside your system and that is the obvious route. But there are a hundred ways to create a backdoor which is very hard to detect and of course the proprietary bootloader Mac bootloader is a perfectly good vector for them.

So the M1 firmware is meant to be updated, right? Proprietary updates are the means by which a company exercises unacceptable control. The next update to the network card firmware could check the signature of the OS and stop working.

> some of the IOMMU configs grant full access to a few hardware streams; we don't know whether those streams are actually controllable by a coprocessor in such a way that it would make it backdoorable

Wait, so its all good because its protected by IOMMU configs, except where it isn't..., and you just hope its a bug that the IOMMU config was too open? Seems more likely that this whole theory of yours has a whole in it, that some firmware does have access to change important data.

Think of a keyboard. Now, imagine one that just has a simple chip that is not updatable. Well, it could have a backdoor in it. But it isn't a concern for your software freedom. Now, someone devises a keyboard where you load a proprietary firmware in it every time it gets plugged in, and you are dependent on the vendor for updates, but somehow it has better security properties. Well, you may argue that that is more important than software freedom. Ok, but, then that vendor can then make whatever terms and conditions it wants on those updates, and that includes breaking your security. So, one day, the vendor says: run our proprietary updating software, is every user going to reject it because they realize the security implications? No. And the vendor says: our firmware updates are only distributable through MacOS, so every time you update, you are going to have to install MacOS, then reinstall GNU/Linux. Sounds like a good way to kill GNU/Linux for 99% of users who don't got time for that. Wait, isn't that the situation for M1 laptop users? Riiight.

> No, no no. This is wrong

Look, I'm not a fan of pulling on credentials, but I've literally spent the past year reverse engineering these devices. If you're going to tell me I'm wrong about my security analysis, I hope you've done your own.

> But there are a hundred ways to create a backdoor which is very hard to detect and of course the proprietary bootloader Mac bootloader is a perfectly good vector for them.

Not when you can literally flash these devices from scratch (DFU mode) using a public OS image from Apple. That guarantees any preinstalled backdoors go away, since it's a complete wipe (you can do this from a Linux machine, by the way - I just added support for the latest M1 devices and OS to idevicerestore a few days ago). All the runtime components that remain booted while the OS runs are not encrypted, and thus Apple can't hide a secret backdoor in them.

> The next update to the network card firmware could check the signature of the OS and stop working.

The network card is behind an IOMMU and sees exactly what the OS wants it to see. It has no way to check the signature of the OS.

This whole argument is moot anyway, because of course Apple could release a new OS/firmware version that removes the bootloader unlock tools. I've had this discussion a million times already. Apple spent a significant amount of time developing these tools and the infrastructure to allow these unlocks, and I do not believe they would ever do this, as it would be a massive 180 and incur a huge PR hit, nevermind expose them to legal action. If you believe otherwise, then don't buy these machines, or just never update the firmware once you get one. Also don't buy any Android phones, any x86 PCs with Boot Guard, etc., as they all suffer from the same hypothetical retroactive lockdown threat.

> Wait, so its all good because its protected by IOMMU configs, except where it isn't..., and you just hope its a bug that the IOMMU config was too open?

We are still reverse engineering these machines. It's not just the IOMMUs. There are other layers of address filtering. We don't know what those streams do, therefore we can't say whether they're evil or not. Given how carefully Apple has designed these things to prevent this, I have no doubt that if there's a path for one of these coprocessors to access all RAM, that's a bug, and if I can confirm that, that'll be an email to [email protected] with a 90 day disclosure deadline, and they'll fix it. It wouldn't be my first rodeo with Apple product security either. They're good, but they're human. They make mistakes.

But we can't say that right now because we literally don't know what's plugged into that port on the IOMMU. It could be a hardware block with an address filter or otherwise controlled by the main CPU anyway. Or it could be outright unused and a vestige of something they were doing on iOS. I can certainly tell you that the main IOMMU port used by the coprocessor subsystem in question does not have access to all RAM. They've been very careful to design the whole SoC like that. If there's a hole, it's a bug.

> Think of a keyboard. Now, imagine one that just has a simple chip that is not updatable. Well, it could have a backdoor in it. But it isn't a concern for your software freedom. Now, someone devises a keyboard where you load a proprietary firmware in it every time it gets plugged in, and you are dependent on the vendor for updates, but somehow it has better security properties.

You could just not apply the updates, and you'd be no worse off than with the non-updatable chip. The updatability gives you choice. It doesn't take anything away, certainly not any more of your freedom. In fact, most devices with the kind of little ROMs the FSF loves to ignore, like keyboards, would not use signed firmware if they had a RAM design instead. That means you absolutely gain freedom with the RAM version - the freedom to reverse engineer the proprietary firmware and write your own, or install an open version someone else has already made.

> Wait, isn't that the situation for M1 laptop users? Riiight.

I have a perfectly working installer that pulls the firmware updates from Apple's CDN and builds an OS container without installing macOS. You do need macOS for self-hosted system-level firmware updates, but only because we haven't built a process for Linux to invoke that updater yet. You can, however, already use DFU mode with another Linux machine running idevicerestore to apply these updates without wiping the whole system nor requiring a macOS install, if you really want to (though it's not the best method because it wipes some stuff that makes it not completely seamless, but it doesn't wipe your OS).

> so every time you update, you are going to have to install MacOS, then reinstall GNU/Linux.

Or you could just dual boot, which is how I expect 95% of our users to use the system. We recommend keeping a macOS install around at this point for various practical reasons. The machines natively support multi-boot and we take full advantage of that. Please learn more about the system architecture before making up FUD.

> Not when you can literally flash these devices from scratch (DFU mode) using a public OS image from Apple. That guarantees any preinstalled backdoors go away, since it's a complete wipe (you can do this from a Linux machine, by the way - I just added support for the latest M1 devices and OS to idevicerestore a few days ago). All the runtime components that remain booted while the OS runs are not encrypted, and thus Apple can't hide a secret backdoor in them.

You're saying that a backdoor can't be secret if it is in an unencrypted binary. That sounds wrong to me. Are you going to decompile and audit the entire OS to find a backdoor, I don't think so.

> I have a perfectly working installer that pulls the firmware updates from Apple's CDN and builds an OS container without installing macOS. You do need macOS for self-hosted system-level firmware updates, but only because we haven't built a process for Linux to invoke that updater yet.

Well, that is nice.

> You could just not apply the updates, and you'd be no worse off than with the non-updatable chip. The updatability gives you choice. It doesn't take anything away, certainly not any more of your freedom.

You "could". In practice, software vendors relies on the updates to abuse their users. For example intel microcode updates have a license that says: you agree not to reverse engineer it. Security updates for printers come with functionality to stop working with third party ink. Oh, you are a sophisticated user and handle it all. Fine. And of course, FSF certainly encourages reverse engineering: if you want to buy something for the purpose of reverse engineering, FSF does endorse that. For everyone else, think it's a perfectly fine position to simply say, we don't endorse opening yourself up to an abusive relationship.