The 802.11ah offerings right now are a mess though. Mostly proprietary and just generally very buggy. I don't know of a single chip that can actually be used with up-to-date Linux. Do you? Be it Morse Micro, Newracom, Taixin or any other, they all suck in some aspect.
Hostapd people also do not seem interested in bringing in any 802.11ah support. So it's crap in that aspect as well. Drivers all fake 802.11n or the chipset offers some garbage AT-command interface and does all of the networking.
On the other hand MeshCore and Meshtastic have similarly terrible codebases as far as I've seen. At least they're somewhat usable though.
Honestly no clue why these software stacks are all this dangerously written, unstable and haven't improved in years.
Mesh networking is still mostly a playground for hobbyists and hacky, built-on-the-knee implementations. People love shipping a cool PoC, but as soon as the boring stuff starts - stabilization, drivers, edge cases - everyone bails to chase the next hype protocol. We’re left with mountains of half-baked C++ legacy that nobody dares to refactor because the whole house of cards would collapse iirc
Edit: does someone not realize that many (all?) the doctors and hospitals use to verify you is your name and date of birth (in the U.S. - although I suppose that's why since this breach happened elsewhere)?
Because the world is run by people who don't know anything, but have to pretend they know everything, so they can't ask those of us who have some idea about how IT security works.
They even do it on Google Play. No, I don't want to buy books in a language I can't read, suggest me ones that I can. It's been like that for a decade now I think. I guess it doesn't make them lose a noticeable amount of money.
> They "handle the business" while someone else does 99% of the actual work, then ask to split 50/50.
As a response, Micay decided to destroy the update signing keys for all the CopperheadOS devices out in the wild. Resulting in financial damages to Donaldson.
Hardly a level-headed response, even if you disagree about the financial share of something.
That is a perfectly level-headed response. Signing keys must be protected. In the event of a hostile takeover, where a malicious party seeks to compromise the privacy and security of your userbase, destroying the keys is a sensible decision. Failure to do so, and successful compromise of the keys, will let the malicious party push whatever update they want, and it will be accepted due to being signed correctly.
It was not a disagreement about shares, it was a hostile takeover. Someone who never owned the project sought to steal it.
Exactly. It was a bold and necessary move to defend the users and the project. Some users got bricked OSes, but had he handed over the keys it would have put those users at risk and would have destroyed the credibility of the project.
Also, and as from what I understood from the GOS response he was not an employee of the company and had the ownership of his OS, and CopperOS would have been able to use their own signing keys but they never did which is strange, so even legally it looks like a "level-headed" response.
> Hardly a level-headed response, even if you disagree about the financial share of something
According to the linked responses, the keys were not deleted because of disagreement over financial share, but over how the keys were to be used (in particular, in potentially dangerous security-wise ways), for which he did not want personal responsibility over (the keys belonged and used by him even before that project)
Phantom Secure is directly named as one of the parties Donaldson was dealing with, with others being suspected:
>Donaldson tried to make a deal with Phantom Secure, which ultimately didnt work out. Micay suspected other counterparties were linked to organized crime, but we cannot confirm those identities or ties on short notice. Donaldson began pursuing such deals before Micay left and continued afterward.
/e/OS (recipient of EU funding) and iodéOS are European projects that have not been singled out by the French government in smearing despite them having the similar self-professed goals to GrapheneOS. That they had any influence at all on the French government directly is speculated but not asserted.
CalyxOS/Techlore are blamed for being complicit in escalating the animosity and furore around what were initially low-key fallouts/disagreements. This led to GrapheneOS/Micay escalating to defend themselves which unchecked fuelled a spiral of influencer content, vile spamming of CSAM in GrapheneOS rooms (I can personally attest these were some of the biggest on Matrix at the time and led to the team giving up on Matrix moderation and self-protection capabilities), intense public speculation/accusations about Micay's character/mental health etc. which eventually resulted in the swatting attempts.
F-Droid project members have publicly aired their dislike of Daniel as a result of direct or indirect disagreements and did have a software quirk that caused an issue for GrapheneOS/possibly other custom OSes' users due to their added permission (which the two parties again disagreed on). Conspires is loaded wording.
But I do not think it is productive for me to dredge up posts and potentially cause more misunderstandings as a complete outsider for something that is directly affecting someone's life like this. They (Micay/GrapheneOS) have posted detailed contextual snippets and information about what has happened so please contact them directly for reference to the original posts and discuss if you really wish to find out more.
> ...Rossman being a Kiwifarms supporter.
>
> You can't believe someone who has constantly claimed things without receipts.
I had never actually visited Kiwifarms before today so I knew virtually nothing firsthand of what's actually going on there, other than hearing it repeatedly invoked in these discussions by supporters and detractors alike. A brief, cursory look turned up a dox thread thanking @larossmann for providing information.
It also turned up comments from some like, "Daniel Micay is a low-functioning cancer who should have been beaten and/or raped to death by a drunken father."
If anything, Micay appears to have been underselling things.
To be fair, it appears the project also has some supporters in that thread, and I'd have to delve further to figure out whether it's a 4chan-esque deliberate toxicity to keep the unwashed masses out, but it's not difficult to see how Micay isn't interested in dealing with Rossman. Rossman spends a lot of time knocking Micay online, but I'm not finding much in the way of even-handed coverage by Rossman from his considerable YouTube pulpit. Rossman also appears to be active on there recently. A few minutes of researching indicates a non-trivial possibility he has a role in all this and has zero desire to separate himself from it.
Many reasonable people would have zero interest engaging with someone like that, especially after they've donated money and then attached post-hoc strings to the donation.
I also saw firsthand Nick Merrill's chat behavior re: Daniel and GOS, and as one who used to contribute to both projects, I had zero qualms after that pulling all support from Calyx, which still makes me sad, as Nick at his finest was a pretty wonderful force for good. The same could be said of Rossman.
If this sort of thing doesn't at least somewhat moderate the consistent position you've held here every time GOS comes up, I don't see a way to assume good faith on your part in these threads. A number of people in these threads consistently adopt the form of making unsupported claims they could easily research before posting, and when presented with evidence to the contrary then move on to claim to be given unsatisfactory responses to their original questions and/or move the goalposts. When others eventually stop engaging, they claim the project supporters are unable to answer even their most basic questions (which have already been addressed numerous times, with citations).
It's against HN guidelines and its a pretty ignoble way to exist.
So why should we believe you over Micay, or are you willing to change your view after seeing evidence
The claims arent vague, they are quite specific in what happened. This wasnt spiteful and this wasnt disgruntled. It was the logical choice given the circumstances.
IMO its a lovely paradox that no one can argue against such a deletion. Either the party choosing deletion is reasonable so there are grounds for deletion or unreasonable and they are the grounds for deletion.
Hey! On a quick introductory note, I'm the community manager and the person who was interviewed. Please, read questions 17, 25 and 26 and our respective answers to them in the linked forum thread. In particular the following parts that I'm pasting here for convenience:
Question 17: Did your and Donaldson values begin to diverge? Was Donaldson more concerned with making money than you were?
Answer: [...] In 2018, matters between Micay and Donaldson came to a head over Donaldson’s desire to pursue business deals with criminal organizations, and his attempts to compromise the security of CopperheadOS, including by proposing license enforcement and remote updating systems that would allow third-parties to have access to users’ phones. As part of this process, Donaldson began to demand that Micay provide Donaldson with the “signing keys” - i.e. the credentials required to verify the authenticity of releases of CopperheadOS. Donaldson advised that, in order to secure certain new business, potential customers required access to the Keys.
The keys had been in continuous use by Micay, in his personal capacity, since before the incorporation of Copperhead. However, more importantly, any party with the keys could mark malicious software as “authentic”, and thereby infiltrate devices using CopperheadOS.
Micay was unwilling to participate in that kind of security breach. Since Donaldson had control over certain infrastructure for the open source project, he would be able to incorporate (or hire others to incorporate) the privacy-damaging features described above for all future releases of CopperheadOS. Micay therefore deleted the keys permanently and severed ties with Copperhead and Donaldson.
Question 25: Did things between you and Donaldson devolve when he approached you about a compliance audit? Did he tell you that he needed to know how the signing keys were stored?
From Wired:
We understand that Daniel's recollection was not that James wanted to know more information about how the signing keys were stored, but that he wanted direct access to them.
Question 26: Did you suspect his request was tied to a deal he was brokering with a large defense contractor? Did you believe this would put the entirety of CopperheadOS’ user base at risk?
Answer: Yes and yes.
The large defense contractor in question was Raytheon. The decision to destroy the signing keys was not based on a financial disagreement, but an existential one. Every single CopperheadOS user back then would have been compromised otherwise. It's of course a big deal given the implications, but it acted as a last resort for Daniel to stop a hostile takeover attempt fueled by greed, which he ultimately took because there was no other way out.
> We understand that Daniel's recollection was not that James wanted to know more information about how the signing keys were stored, but that he wanted direct access to them.
> Did you suspect his request was tied to a deal he was brokering with a large defense contractor? Did you believe this would put the entirety of CopperheadOS’ user base at risk?
They were compromised. Greed overtook the principles on which the project was founded and put the project at risk. They agreed from the start that Micay would own the project and hold the keys. They explicitly accepted those terms. Despite this, they tried a hostile takeover anyway.
Forking and building a separate build isnt dual signing, its just forking. You can do that right now with GrapheneOS and its build guide if you want.
Im not sure what you mean by the last part, GrapheneOS has been quite upfront with all of this from the start.
From a security-minded user perspective it makes sense to destroy keys when instead of a single entity I receive updates from I get another entity that is not equivalent, and half of my previous entity thinks that the other half is sus.
It wasnt intelligence agency compromise, it was a business partner compromise, who intended to violate the privacy and security of their users. Nothing about this is done out of spite. Im not sure where youre getting that from. You just seem to be attacking peoples character for making the right choice given the circumstances.
Yeah, that’s the issue. I don’t want people who behave immaturely, impulsively, or vindictively, having a key role in something as important as my phone os. I want stability, maturity, and thoughtfulness.
That is what CopperheadOS, and now GrapheneOS, provides. Its a level of "battle tested" that most OS and app devs never have the opportunity to have. Deleting the signing keys during a hostile takeover attempt rather than submitting to pressure or greed is an amazing quality that is rare to find.
It looks like a very mature action to me: It certainly avoided the compromission of an OS that aims to be secure after all. It is not some windows OS with encryption keys sent to the cloud, so if security is compromised I fully expect targeted devices to break.
So what exactly would you have done? Risk the key being taken over by a shady entity? Does the alternative really scream "mature, stable, and thoughtful" to you?
Understandable wishes, but you might have to put something from yourself into it if this is a pressing concern. Or you will be left to your own corporate devices.
The leadership is great. Persistent, patient and friendly.
They were able to improve. I don't think many of the often negative and ad-hominem critics would be able to endure such a pressure as they had in the past.
The GOS (GrapheneOS) lead had responded to criticisms like yours that he gladly retreats inside his tech role if others would take it upon them to refute the claims from rivals. So if you are that balanced, normal person, you could take that work out of his hands. Or help fund a full time PR person.
«In 2018, matters between Micay and Donaldson came to a head over Donaldson’s desire to pursue business deals with criminal organizations, and his attempts to compromise the security of CopperheadOS, including by proposing license enforcement and remote updating systems that would allow third-parties to have access to users’ phones. As part of this process, Donaldson began to demand that Micay provide Donaldson with the “signing keys” - i.e. the credentials required to verify the authenticity of releases of CopperheadOS. Donaldson advised that, in order to secure certain new business, potential customers required access to the Keys.»
Micay is rightfully paranoia, just having a GOS phone makes some government agencies quite mad. There are many ways a project like GOS could die, disinformation could certainly kill it. Other projects don't help the case if they throw mud at it. Rather, they should focus on their real technical shortcomings, but such articles aren't written somehow. https://eylenburg.github.io/android_comparison.htm
EDIT
> Should I make my own fork?
You could contact him to offer your help where he falls short.
Mental health and wellness issues in high tech research and development are everywhere. I would suggest that you focus on the product and what it can/cannot do for you.
Suggest away. It’s still a factor in my decision making, because if I can’t trust the developers to behave well, i can’t trust the product to continue to do what it says it can do for me.
Destroying the signing keys in the midst of a hostile takeover is the responsible thing to do. Its for the safety of their users. Thats a commendable trait to have.
Same, which is why I'm glad he deleted the signing key in this case. It was the only right play given the situation. I'd have done the same and I'd expect anyone with integrity to do likewise.
> if I can’t trust the developers to behave well, i can’t trust the product to continue to do what it says it can do for me.
So you'd be willing to give up Linux because Linus cannot stop verbally abusing people to this day? Because that's what I did. I decided that any project where the main dev(s) openly abuse people in public, is the line I draw.
I know that is an extremely controversial choice that many people will disagree with, but it's my choice to make and I don't regret it.
I trust you didn't mean it that way, but it's totally improper to go to speculations about mental health in response to discussions about communication styles and maturity.
While I appreciate the second line and think it's generally the right answer with FOSS projects, your speculation poisons the well.
> > Daniel Micay has a history of absolutely unhinged behavior online
That quotation is from another comment in this discussion. Sadly, it is the sort of personal attack on his mental state that has been commonplace here at HN and elsewhere for a long time. I caution all to avoid such commentary. My long experience in tech r&d has firmly convinced me that mental health and wellness challenges are widespread, and should not be weaponized. I hope that clarifies my comment for you.
Things aren't only bad if they're illegal. There's plenty of bad things one can do that are perfectly legal, and plenty of good things one can do that are totally illegal.
Micay owns the whole project. Ownership of the project was not exchanged or divided, part of the explicit terms of the agreement were that Micay would hold the keys and ownership of the project just as they always have.
Thats a characteristic all modern OSs and modern apps have. You need to trust the key holders, always. Some people make their own builds for this reason. Depends on the threat model.
> Something along the lines of "you know regardless of whether or not you're factually correct, these public attacks on other people companies are really bad for your image"
Sometimes they aren't even factually correct and get a bit upset about it when called out.
Anyways, I have gotten the same impression and these seem like red flags to me as well.
Which is why I'd take everything in that response with a mountain of salt (and I'd pay attention to what they're not saying).
Yes, I don't like when anybody spreads falsehoods about any important free software. Do you?
However your example is unrelated. Their arguments were rather reasonable and informative in the discussion you linked to. So I don't complain about that anymore.
You have been saying this sort of stuff on the Qubes forum and a bunch of other places for awhile now.
Hardware kill switches are nice-to-have, but they are significantly less important than the OS actually protecting the mic. With your Librem/PinePhone, you cannot even reasonably expect your calls with end-to-end encrypted apps like Signal and Element to be protected. Any app with access to the PulseAudio socket (which happens to be anything that you want to have audio playback with) can snoop on your mic at any moment in time. This does not even require an OS compromise.
This has been pointed out to you repeatedly and yet you choose to ignore it, and instead you just do character assassination whenever a post regarding GrapheneOS or Daniel Micay shows up because what Micay says goes against your favorite ideological products...
> Any app with access to the PulseAudio socket (which happens to be anything that you want to have audio playback with) can snoop on your mic at any moment in time.
I said multiple times that I exclusively run trusted apps on the phone. I use Qubes for untrusted staff. Do you understand that threat models can vary?
> Hardware kill switches are nice-to-have, but they are significantly less important than the OS actually protecting the mic.
I never said they were more important. I only said they could reliably protect in sensitive cases.
> instead you just do character assassination
I choose to dispute false information. I don't care about any personalities. And I would be happy to be proven wrong, too.
> I said multiple times that I exclusively run trusted apps on the phone. I use Qubes for untrusted staff. Do you understand that threat models can vary?
By that logic, you might as well just not have the killswitch at all. Everything is magically "trusted", right?
Yes, I do understand that threat models can vary. Please give an example of a threat model where it makes more sense to use a phone which cannot protect any private calls over a functioning phone that has real protection.
If you are going to say "oh, when you never talk on the phone at all" then you might as well just remove the mic. It's not hard.
As usual, there is nothing that GrapheneOS or Micay says regarding the Librem or Pinephone that is inaccurate. You are just saying stuff that doesn't even remotely make any sense. Perhaps you are being deliberately disingenuous. Perhaps you are just so blinded by an ideology that you cannot see that what you say is just nonsense. I wouldn't know.
> I choose to dispute false information. I don't care about any personalities.
> Their microphone kill switch also doesn't prevent audio recording
It doesn't prevent audio recording in the super paranoid "oh, the whole phone has been compromised" scenario because it is bypassable via the sensors.
In fact, it doesn't even protect the phone in normal operation, because apps with device=all can access the sensors without the whole phone being compromised.
It doesn't prevent audio recording with any normal usage either because the OS is incapable of protecting private conversations thanks to the PulseAudio socket. "Exploiting" this is significantly easier than any of the stuff involving the sensors.
And what good is the phone when 3 switches are off? You think that people buy a phone with a "mic killswitch" expects to have to turn off practically everything including internet to make sure that their mics aren't snooped on?
Does that really sound like a functioning "killswitch"?
On a long enough timeline he'll probably cite this comment chain as proof you were unable to respond to his concerns, like everyone else who's ever tried.
Oh he's already done that when I explained to him how stuff like PureBoot has circular logic and doesn't actually work on Qubes forum already.
Unfortunately he will just ignore every single counter argument ever made and blindly believe these companies because their marketing material has "freedom" and "FOSS" in it.
On Qubes forum, you had replies from far more knowledgeable people than me. You never could answer to them. You only talk about the lack of security of Pureboot and never showed the code breaking it. "Talk is cheap, show me the code".
I did reply to them plenty of times. Here you go doing the exact same thing again - ignoring 100% of what's being said, then claiming "no one can respond".
> You only talk about the lack of security of Pureboot and never showed the code breaking it.
If you think a piece of code is needed to understand why it's a joke, then I don't even understand what is wrong with you. LMAO. The whole thing is conceptually botched, and they pretty much admitted as much.
1. Boot block performs measurements of itself, its settings and everything down the chain for attestation.
2. There's nothing protecting the boot block.
3. A malicious boot block can lie about measurements.
4. If the goal is to defend against an attacker who tampers with the BIOS chip - then it fails at doing so miserably because an attacker can just use a boot block that lies about the measurements.
Seriously, what good is showing you the code if you don't even conceptually understand how the thing works?
You know, there is a famous saying: A farmer does not need to know how to lay eggs to know whether an egg is good or bad. In our case, the egg is already rotten from the get-go. This is not a "Ohhh something has such bad code I can attack it using XYZ method, wait and see!" situation. This is a situation where "Your logic doesn't even make any sense to begin with."
Perhaps, just perhaps, you can benefit from just spending 5 minutes thinking a bit about how the whole thing actually works at a very high level and read what I said above.
Thank you for your kind advice, but I prefer to trust a developer of Heads and many Qubes contributors instead of a loud Internet commenter criticizing everything and everyone.
Everything Micay said in that linked thread was and remains correct. You again fail to address what was incorrect in his comment. Going on to later ask people "what is correct about it?" is rhetorically disingenuous at best.
But as you consistently slide any adjacent topic you can into a discussion about the Librem 5 (no matter how tortured a segue), let's go with that and revisit it.
I looked at your puri.sm link, and it mostly served to lower my estimation of the Librem 5's kill switch system. You can't disable the sensors in a trustworthy way without disengaging every kill switch at the same time, entering it into their Lockdown Mode. At that point it's just a still insufficiently air-gapped, highly underpowered Linux device which remains poorly secured against other side-channel attacks. The speaker which, by everything I could find, is still functional, the OS remains poorly secured against software attacks, it lacks proper hardware security, and so on.
It fails in terms of human factors, too. Joe Consumer thinks flipping off the mic switch prevents audio recording, but it doesn't in multiple regards. Even putting it into Lockdown Mode doesn't disable the speaker, which can be used to record audio despite your insistence that the device is fully secured when all switches off. Speakers can also be used to exfil data over short distances, demonstrated to work through walls.
Poor misinformed Joe Consumer is also still left with the same issues the other commenter has already identified in terms of the difficulty of securing any Linux computer.
But that's okay, because you only run trusted software. Until one of those trusted pieces of software include a compromised library, which happens often. You are, at that point, relying on the OS and its relationship to its hardware, which, flawed switch system aside, is highly insufficient. The device offers very little protection at that point. You know all this because you run Qubes OS, but hand-wave that away by appealing to trusted software as soon as the Librem 5 becomes the subject.
If I was modeling threats around protecting sensitive files on the device, not falling victim to attacks that could record audio and/or exfil data or otherwise leak, I'd still go with GrapheneOS on a Pixel 8 or later.
The Librem 5 wins for anyone who just wants a phone which runs Linux (which is a great thing and I wish we had more options which did that), but the security theater of that device is just goofy from top to bottom, as are its more vocal and less reasoned supporters. If one's threat model is, one sometimes wants to be able to turn off all radios and sensors, leaving the speaker functioning, with an otherwise poorly secured device, then, great. It's the device for you. But it's a threat model which will be practically beneficial to very few people, if any.
If your holy grail is having the radios off without other hardware or software considerations, great, you've found the phone for you. It's a brilliantly marketed device for well meaning but poorly informed people with underdeveloped threat models, and, I guess, for someone in your situation who's happy to make all of the above compromises to be able to physically disconnect radios.
Do you always enter Lockdown Mode before typing anything sensitive, due to the attack vector they highlighted about deriving typed data via sensor data? ('No, because I only run trusted software.' See above.) You literally can't disable the sensors without disabling all radios. They acknowledge that sensors are an attack vector worth addressing, yet don't put sensors on a discrete circuit. Like I said, great marketing. Otherwise pretty goofy.
Would I complain if the upcoming Motorola GrapheneOS phone had physical hardware switches? Sure, I'd take an additional layer of containment if all of the fundamentals are addressed properly.
But your argument is like bolting the world's best seat belts onto a motorcycle, and never missing an opportunity to tell the world about your belts, wonderful though they truly are.
Not entirely sure if the chip they are using (WM8962) can be reconfigured as a mic or not... it probably can't. But yes, the speaker is still active even when the mic is toggle off.
Everything else is pretty much the argument though - who buys a phone with a microphone killswitch so good that for it to actually function you must also flip the other killswitches to kill both wifi and cellular connection? A microphone killswitch so impeccable that in order for you to not be snooped on you also have to give up texting and browsing the internet. Truely impressive stuff.
Man, if this entirely thread of people calling out how ridiculous the implementation is and the killswitch not actually working in practice isn't enough to convince you, nothing ever will.
I don't even feel like arguing against the absurdity of your arguments anymore. This is my last attempt at dumping it down a notch:
A "microphone killswitch" is supposed to protect the user against having their convos being snooped on when it's toggled and still be able to use the phone in a meaningful manner. A "microphone killswitch" that doesn't really function on its own and requires turning the entire device into a brick is non-fuctional for all practical purposes.
I might as well just invent a "microphone killswitch" that requires people to pull out the battery to make sure that they are not snooped on at that point.
> A "microphone killswitch" is supposed to protect the user against having their convos being snooped on when it's toggled and still be able to use the phone in a meaningful manner
LOL, it's hard to imagine a more ridiculous and self-contradicting statement than this.
1. It's just physically impossible to defend from tracking, when the phone has networking connections on. Not even on all-mighty GrapheneOS.
2. I am using a phone with the kill switches off in a meaningful manner all the time. It is a full computer running a desktop OS and can run any apps, including listening to music from a microSD card, reading saved text/pdf files, showing presentations with original LibreOffice, programming in any language with standard tools, and so on.
3. Even though the phone in the lockdown mode (with all three kill switches off) has no connections, if I'm ever in emergency and need some help, I can turn the phone functionality back on and call for the help I need. Obviously, privacy in such case would be secondary after health.
4. Unlike for GrapheneOS, there is no way to hack my kill switches for any money. I can be 100% certain that they work as intended, even if a state actor is against me. Yes, everything else might be compromised in such case but not the tracking and listening to me when I need true location and microphone privacy.
>> Their microphone kill switch also doesn't prevent audio recording
More dangerous advice. The microphone kill switch prevents audio recording via the mic, not via the sensors or speaker. A Librem 5 user needing to secure against audio attacks would need to switch all kill switches off, not just the mic one (by Librem 5's own estimation), but would still be vulnerable to the speaker.
The effect of your participation in threads about projects you claim to care about is harmful. Please do better.
Librem 5 speakers cannot be used for recording, according to the developers. Yes, all kill switches protect you from the sensors.
This is indeed a misunderstanding, again. Reliable protection is possible - this is all I wanted to say. Not everybody means "all sensors" when they say "microphone". I took the phrase literally.
> Their entire post regarding pinephones is accurate.
I never mentioned Pinephones, although I do believe that the attack on them is still too harsh. Their security is about as good as the one for Linux. And it's not exactly "atrocious". Especially if you only use software from the official repositories. Let's agree that it should be improved though. (I prefer Qubes OS myself.)
> Hardware kill switches need to be correctly implemented.
Are you saying they aren't for Librem 5?
> A kill switch cutting off mics and not sensors or speakers is incomplete and privacy theater.
I explained in the link above that cutting all sensors is exactly what happens if you choose it.
> Not to mention kill switches assume the device is already compromised
This is not accurate. Kill switches imply that even if the device is compromised (which you can never 100% verify, even on GrapheneOS), your location etc is still private, when you need it.
I find the whole OVH web control panel atrocious. It's so buggy I couldn't even have my account deleted, not even after contacting their customer support (they just told me to fix it myself using their APIs...).
> Since you can't really quantify these properties (as opposed to: the problem is either solved or not)
I think we could quantify these properties, just not entirely.
One could take a long-term project and analyze how often or which approaches resulted in a refactor. In the same way, we could also quantify designs that resulted in vulnerabilities (that we know of) the most often.
It even wouldn't be impossible to create artificial scenarios. Projects that have an increasing number of requirements, see how many code changes are required, how many bugs result from that. Again, quantifiable to some extent. Probably better than datasets totally lacking something like that.
There probably isn't a public dataset on this, but it wouldn't be impossible.
I would suspect that some of the slowdown that the author encountered does occur with even a dozen or so add-ons. Why else would Firefox bother you about resetting your profile if you haven't returned in a while?
Hostapd people also do not seem interested in bringing in any 802.11ah support. So it's crap in that aspect as well. Drivers all fake 802.11n or the chipset offers some garbage AT-command interface and does all of the networking.
On the other hand MeshCore and Meshtastic have similarly terrible codebases as far as I've seen. At least they're somewhat usable though.
Honestly no clue why these software stacks are all this dangerously written, unstable and haven't improved in years.
reply