First, let me say that Daniel is a truly gifted security focused developer, and that I have used GrapheneOS before - it’s excellent for security, however, it is still android. His ever improving hardened malloc implementation is also very nice.
That said, if I were to build android for my L5, I’d use GrapheneOS.
The real issue here is that he seems triggered for some reason by semantics when he fails to see the L5’s potential, even for his own project. Google etc don’t ship firmware source for their phone SoC and basebands, either. At best you may get some leaked source code for them.
The component level firmware and security updates can later be added through LVFS/fwupd, if I’m not mistaken…this will bring parity with the botnet devices while also giving us the benefit of the killswitches (and real linux if you don’t build android yourself).
One also has to consider what they expect the L5 to be - another cell phone, or is it a full fledged linux machine that is also able to make calls…I see it as the latter.
There is nothing at all wrong with using GrapheneOS on whatever Smartphone you might get, but so long as the wifi chip is on,it can be pinged to your location whatever the software might be and so long as you see the 3G, 4G or LTE logo and the bars that other chip that broadcasts the signal to the local cell towers still tells anybody who wants to search you out as to where you are.
Data may be safe in GrapheneOS, but you can be tracked like a shark, whale or a bird who has been tagged. Your every move is known, how frequently you went to a local mall or a girlfriend’s flat can be catalogued. That is some security!
If I were a woman, or maybe even a man with a stalker, I would be quite satisfied? Not!
I wouldn’t be so confident about data safety when you have blackbox cpu (baseband) sharing your memory - any keys could be read, any data buffers, anything.
Data isn’t even safe. The baseband modem has DMA to the system memory, can even write to it to inject malicious code. No secure malloc function can fix that, since the first target is going to be the secure malloc function itself.
In practice, as long as the number of users are low, it may be the case that no one targets this particular version of android, since the payout isn’t worth the effort. On the other hand, people who choose to try to hide what they are doing are automatically of interest to certain groups for whom profit is not a motive and costs are not their own.
Yeah, I think he’s just been through so much shittyness that he struck first as a protective move expecting some shittyness from Purism. Like I said, it’s just sad to see because I haven’t seen anything but Purism wanting to cooperate with other projects with like values. Personally, I can forgive him for the misdirected harmful comments because I myself have been there (not with a tech project but I’m embarrassed to say I’ve had issues with misandry. I just hope he realises not every similar project is out to get him a hell of a lot quicker than it took me to realise not every man is out to get me.)
Are you sure he is talking about Purism/Librem 5 in those tweets? As far as I can see the tweets do not say that explicitly, it’s something we’re supposed to read between the lines?
At some point he reveals the L5 as an object of discussion. One may reasonably assume that prior comments, were they to be rationally linked, were associated with the L5 as well. My favorite part of the infosec industry is how, to really emphasize a point, emotion will be brought into the narrative. For that extra oomph! The real discussion here is normative vs positive. And if it’s positive, is quarantining the ARM SoC as Purism essentially did the right strategy? A fantastic debate undermined by lack of argumentative and emotional discipline. Examples are:
“There are several projects very deliberately misrepresenting this, misleading users and putting them at risk by not providing the updates.” - Unstated basis for accusations of deception and no proof of intentionality provided.
“Privacy and security have been hijacked for marketing by not just companies but also open source projects. You cannot believe what you read on these topics from most companies, projects or the media. The industry is full of scammers, dishonesty and ignorance.” - And we can trust the author on what basis? This pushes into the “accusations of being a spy” dilemma.
" On a day to day basis, I encounter an endless torrent of misinformation and bogus marketing claims. I expect nothing less from tech giants and security companies but it’s really sad seeing the same from open source projects and non-profit orgs." - Similar retort as above. Not rational. Not reasoned. Lack of established basis. Emotional.
That being said, we can find some items in here that I think really merit exploration:
“Full security updates covering all components are incredibly important. Being able to update firmware/microcode rather than replacing hardware over and over again is not a negative. Verified boot, keystore HSMs and other hardware-based security features are also important things.” - This is good. And deserves more exploration.
“Preventing users from installing firmware updates is also hardly freedom, and yet that’s apparently what passes for it these days. Hiding the fact that the hardware and firmware is proprietary with no way to update it doesn’t make things better in any way but rather much worse.” - This mildly technical but delves into the real question of perception and the perception of security.
regular updates of proprietary firmware that has RAM access
no updates of proprietary firmware that has NO RAM access
I’d always choose the latter.
It is misleading to say that a lack of updates via OS mechanisms is a lack of freedom. You are free to update the components, although it might be inconvenient.
It’s the case already for the coreboot update script.
Besides, Purism is in discussion with the FSF about this.
Sandboxing
The Librem 5 has a HSM (smart card), there are plans for secure boot.
Wayland provides some isolation that Xorg doesn’t have.
Flatpak (PureOS Store) provides sandboxing.
A lot of the criticism has no base.
The rest can be summarized with
“OMG, they are not perfect on day one, how dare they1!1!!!11!!!”
Full security updates while online and only while online are bad. Take the ryzenfall security issues. I am reasonably confident that AMD is not sticking bad things in their firmware, intentionally (board manufacturers is another matter…). But if your computer gets compromised by a rootkit, you must replace the motherboard. Why? Because you have no way to verify that the UEFI has not been compromised. I mean, if you have a flash reader/writer, you can verify it, if you have what the original image is supposed to be, or reflash it while you’ve got it hooked up. I’d far rather the UEFI be out of reach of the running system. A
As a good compromise, a write-protect (physical) switch would be ideal. Lets you modify the component in place, but only when you want to.
I like how some people want to reach a distant goal by not even starting to move in the right direction. Waiting for the invention of teleportation? Good luck with that.
@lperkins2 You reminded of an idea for a Purism product that I wish for.
I wish there was a USB key to store boot firmware that had a physical switch that prevented writes. All the ones that I have found are a soft-disable. The key just tells the OS “please do not write to me”. Writes can still happen anyway.
And not just for the bios either, disable writes to 3.5" disketts by a switch, same for (non-micro) sd cards. Maybe it’s something we can get purism to consider in the future.
In the meantime, as someone with access to a chip flasher, I’m quite happy to have the chips not writable from the OS.
