Författarens poäng är väl snarare att projektet "Librem Purism" inte kommer skilja sig nämnvärt från andra Linuxdistributioner — jämfört med Windows så är det fortfarande en markant mindre mängd stängd kod.
Mikrokod inuti processorer och chipset går sällan att få fri. Det är inte optimalt, men samtidigt är det inte mycket att göra åt så som läget ligger, och på många sätt är det inte särdeles "viktigt" ur "fri mjukvara"-aspekten. Att mikrokod i regel är stängd är ofta en poäng som tas upp i syfte att försöka sänka FSF:s mål och rekommendationer, men det bygger på (minst) ett falskt dilemma: bara för att en sak inte kan sägas vara till 100 % ofelbart "fri" så betyder det inte att det är lönlöst att prata om "fri" mjuk- och hårdvara generellt.
FSF har mer information om sina tankar här. I korthet så handlar det om att kod i hårdvara som i sig inte är tänkt att kunna köra intern mjukvara efter att den levererats till kund i praktiken inte omfattas av de kriterier som FSF ställer för att kalla en produkt "fri". I användarens ögon är sådan hårdvara en "svart låda" som ändå inte går att påverka. Det tar sitt lilla tag att greppa detta koncept och varför det skulle göra någon skillnad, men det verkar som att en del av kritiken på `coreboot`-bloggposten du länkar rör sig i detta område. FSF har skrivit spaltmeter om detta genom åren då det är en vanlig (och inte trivial) fråga.
Bloggposten verkar också ha faktuellt fel i sin huvudpoäng gällande att "Librem Purism" är lönlöst för att de ändå måste köra signerad firmware — en del av poängen är att de inte behöver göra detta, vilket skulle kunna leda till att fri sådan kod kan köras på hårdvaran i framtiden. De säger inte att denna fria kod finns tillgänglig idag, men bara möjligheten att kunna köra sådan i framtiden är ett symboliskt steg framåt, vilket verkar vara det som FSF har lovordat.
Gällande det allmänna säkerhetshotet från stängd eller permanent inbäddad (dvs "ej påverkbar efter leverans"-) firmware så är det en aspekt som är känd, men svår att göra något åt idag. Om vi tittar på det hypotetiska exemplet i bloggen, om firmware som skulle samla och skicka Facebookinloggningsuppgifter via email, så är det inte lätt att dölja i ljuset av nätverkssniffers och annan mjukvara. Oannonserad liknande extern trafik hade troligen upptäckts.
Använder man stängd hårdvarukryptering så vore det en barnlek för en leverantör att lägga in en bakdörr om de verkligen ville (detsamma gäller för stängd mjukvarukryptering). Ska man titta på vilken attackyta som kvarstår för att någon skulle vilja använda bakdörrar i generell hårdvara för att attackera i övrigt "säkra" krypteringsimplementationer, så kanske den största reella (och användbara) möjligheten jag kan komma på vore att skriva firmware som internt lagrar krypteringsnycklar som användaren anger för att låsa upp lagringsmedia, som sedan kan fiskas fram via speciella instruktioner på plats. Det skulle i min föreställning kräva en relativt riktad attack mot exempelvis en viss mjukvara för att vara realiserbart, men det är inte en omöjlighet.
Huruvida det sistnämnda vore smidigare än andra metoder är svårt att säga: troligen inte. Kräver det ändå fysisk åtkomst så finns det nog generellt enklare vägar att använda ("gummislangsanalys", exempelvis).
