Zum Inhalt der Seite gehen

Als Antwort auf iodé

GrapheneOS decided to leave France because they would have to implement a backdoor for French authorities.
What about backdoors in #IodeOS as Iodé is a French company?
goingdark.social/@watchfulciti…


@GrapheneOS is being threatened by French authorities for refusing to add backdoors and they're dealing with coordinated attacks in French media right now. They're pulling out of France entirely, moving all their servers, and fighting off a wave of bullshit one-sided reporting that makes them look like they're helping criminals.

They need us to fight back. Support them however you can, whether that's a dollar, sharing their story, pushing back on the garbage news coverage when you see it, or just telling someone you know about what's happening. All of it matters because they're drowning in attacks from governments and media and bad actors who want them gone.

This is the only Android OS that actually makes me feel like privacy isn't just marketing. They fight for us now they need us to fight for them.

The EU is pushing Chat Control and creating an environment where governments feel empowered to threaten developers into compliance, and if we stay quiet we're letting it happen. Show up for them in whatever way you're able to.

#grapheneos #Privacy #NoBackdoors #encryption #security #chatControl


Als Antwort auf Plumeros ☮️

@plumeros
I am interested in that issue too.
I'm planing to get an IodeOS phone and i highly oppose the idea of "scan-on-device" / cliwnt scanning backdoors in Software.

Not only having a single App with such a backdoor in, but the base OS having one, is even worse...i didn't know this was law in france already.

Even if i am not in danger to be targeted in an legal investigation, does such a backdoor not pose a great risk to be hacked by criminals via that way too?

Als Antwort auf Uddelhexe

@Uddelhexe @plumeros You should readhttps://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private which also applies to iodéOS. There's linked content from Divested Computing, Mike Kuketz and Eylenburg there too which each directly cover iodéOS. /e/ and iodéOS both have extraordinarily poor privacy and security. They make it much easier for states to get into devices remotely or extract data with physical access compared to iPhones.
Als Antwort auf GrapheneOS

France's government has been one of the strongest supporters of encryption backdoors for many years. It's not specific to the current government but rather has broad political support in the country. France is one of the strongest supporters of Chat Control. Both /e/ and iodéOS are based in France. Both operating systems are a massive privacy and security downgrade from an iPhone. Both fail to provide bare minimum standard privacy and security patches/protections.
Dieser Beitrag wurde bearbeitet. (1 Woche her)
Als Antwort auf Coralie Renée

@globcoco @Uddelhexe @plumeros iPhones are far more secure than anything running LineageOS, iodéOS or /e/. An iPhone 17 provides much stronger protections than past generations due to hardware memory tagging which was only previously deployed in production for a lot of code by GrapheneOS (more than iOS). iPhones can be configured to have a higher level of security than they do by default via lockdown mode and other features. End result is definitely far better than any non-GrapheneOS option.
Als Antwort auf GrapheneOS

@globcoco @Uddelhexe @plumeros Pixels and iPhones are the only devices with high quality secure elements providing working disk encryption with a random 6 digit PIN or other typical lock method rather than 6 -8 random diceware words. This matters a lot to many people even if they don't realize it. Other Android devices either omit a secure element providing this or have a much lower quality implementation which gets bypassed by commercial exploit tools in practice. That's just one example.
Als Antwort auf GrapheneOS

@GrapheneOS @globcoco @Uddelhexe

iOS is closed source, so nobody will ever find any backdoors in the software, even if the hardware offers to implement a high level of security. Do I miss anything?

Als Antwort auf Plumeros ☮️

@plumeros @globcoco @Uddelhexe No, that's not how closed source and open source work at all. Closed source software is not a black box. Open source absolutely doesn't mean that all or most vulnerabilities get discovered. Linux kernel has many severe vulnerabilities being found on a regular basis which have existed for years and even decades. Most projects are not getting anything close to that much review. It certainly doesn't mean that an intentionally hidden subtle vulnerability will be found.
Als Antwort auf GrapheneOS

@GrapheneOS @plumeros @globcoco @Uddelhexe You keep repeating "closed source software is not a black box" but in most cases that simply isn't true. Proprietary software companies go to great lengths to impede attempts to reverse engineer their binaries. One of the reasons proprietary apps are so bloated is because their code has been processed by an obfuscator, which replaces simple instructions with long sequences of mathematically equivalent code that takes thousands more instructions.
Als Antwort auf Howard Chu @ Symas

@hyc @plumeros @globcoco @Uddelhexe The topic isn't obfuscated code but rather iOS compared to AOSP including the Linux kernel. iOS doesn't obfuscate the OS code and a large amount of public external research has been done on iOS. The overall system is closed source and the parts which are semi-open-source have the code released very late, but understanding the compiled code is hardly starting from scratch. You're responding as if this thread is about dealing with highly obfuscated software.
Als Antwort auf GrapheneOS

@GrapheneOS @plumeros @globcoco @Uddelhexe your generic statement "closed source software isn't a black box" is generally false. You could have just said "iOS isn't a black box".
Als Antwort auf Howard Chu @ Symas

@hyc @plumeros @globcoco @Uddelhexe You can read what we said as closed source software not inherently being a black box and reviewing what it does not being an insurmountable task orders of magnitudes harder than reviewing an open source project with the same level of depth. Source code can have very subtle intentional security holes and can take advantage of the medium to hide those. The topic was claims about backdoors in iOS vs. a similar scale open source OS.

underhanded-c.org/

Als Antwort auf Coralie Renée

@globcoco @plumeros @Uddelhexe No, it's very inaccurate and is a common misconception among people who aren't developers or security researchers about open source. It does not provide anything close to what you believe it does. You still highly trust the developers of software released as open source and even rare cases of extensive external review do not find all or most vulnerabilities in practice. Finding subtly hidden vulnerabilities would be even more difficult.

grapheneos.social/@GrapheneOS/…


@plumeros @globcoco @Uddelhexe No, that's not how closed source and open source work at all. Closed source software is not a black box. Open source absolutely doesn't mean that all or most vulnerabilities get discovered. Linux kernel has many severe vulnerabilities being found on a regular basis which have existed for years and even decades. Most projects are not getting anything close to that much review. It certainly doesn't mean that an intentionally hidden subtle vulnerability will be found.

Als Antwort auf GrapheneOS

@GrapheneOS @plumeros @Uddelhexe

True. I don't have the experience and knowledge.

Thank you for sharing what you know.

Much appreciated.

Which devices do you own? (Iphones, ipad, mac...?)

Als Antwort auf Coralie Renée

@globcoco @GrapheneOS @Uddelhexe

It's correct that open source doesn't guarantee that all vulnerabilities are found.
But OSS can be reviewed by anybody at anytime, the developers cannot control by whom.
Closed source is sometimes also reviewed. But who prevents closed source developers of removing backdoor code just before a review and add it immediately afterwards again? Who selects the reviewers? It's all in the hands of the closed source manufacturer.
So how can anyone trust closed source?

Als Antwort auf Plumeros ☮️

@plumeros @globcoco @Uddelhexe

> But OSS can be reviewed by anybody at anytime, the developers cannot control by whom.

Your belief that closed source software is a black box which cannot be externally reviewed is incorrect.

> But who prevents closed source developers of removing backdoor code just before a review and add it immediately afterwards again?

Closed vs. open source doesn't work the way you believe it does. Closed source software means not having sources, not lacking the code.

Als Antwort auf GrapheneOS

@GrapheneOS @globcoco @Uddelhexe
> Your belief that closed source software is a black box which cannot be externally reviewed is incorrect.

If the manufacturer allows it, it can be reviewed. If not, no way to review the source code. In this case only reverse engineering may help.

> Closed vs. open source doesn't work the way you believe it does. Closed source software means not having sources, not lacking the code.

I think that's no answer to the question.

Als Antwort auf Plumeros ☮️

@plumeros @globcoco @Uddelhexe

> If the manufacturer allows it, it can be reviewed. If not, no way to review the source code. In this case only reverse engineering may help.

No, you have common misconceptions about open source held by people who aren't developers or security researchers. Closed source does not mean the code isn't available for anyone to review. It's not a black box and the code can still be reviewed.

> I think that's no answer to the question.

It's what the issue is here.

Als Antwort auf GrapheneOS

@plumeros @globcoco @Uddelhexe

> Who selects the reviewers? It's all in the hands of the closed source manufacturer.

No, that's not how it works. Closed source software still has the compiled code available for review, which is often the best format for finding a subtle backdoor which can be inserted as part of the toolchain or through very subtle approaches. Source code is usually the best form of the code to look for accidental vulnerabilities but a backdoor is a much different thing.

Als Antwort auf GrapheneOS

@plumeros @globcoco @Uddelhexe Closed source software is not a black box and the code can be reviewed, contrary to common misconceptions. When you're talking about backdoors which can be inserted as part of compiling it, that's often the form which is needed for reviewing it. Even with reproducible builds + open source, the source code can be written in a way which deliberately masks a vulnerability in subtle ways. You're talking about backdoors where it's deliberately done and hidden.
Als Antwort auf GrapheneOS

@GrapheneOS @globcoco @Uddelhexe

> You're talking about backdoors where it's deliberately done and hidden.

I meansoftware quality in general and backdoors in particular.

> Closed source software still has the compiled code available for review, ...

Following this logic OSS wouldn't make any sense then, as users have always the binary code for execution and for review.

Als Antwort auf Plumeros ☮️

@plumeros @globcoco @Uddelhexe

> Following this logic OSS wouldn't make any sense then, as users have always the binary code for execution and for review.

It doesn't make it not make sense. Source code is the preferred and easiest format for modifying the code and open source provides permission to do it. That doesn't change that what you're saying about closed source software is inaccurate. Finding backdoors is also far different than looking for accidental vulnerabilities.

Als Antwort auf GrapheneOS

@GrapheneOS @globcoco @Uddelhexe
> Even with reproducible builds + open source, the source code can be written in a way which deliberately masks a vulnerability in subtle ways.

This is what happened Easter 2024 with zx library in ssh.

Als Antwort auf Plumeros ☮️

@plumeros @globcoco @Uddelhexe If the xz backdoor had been written better without a severe performance issue, then it wouldn't have been caught in the way that it was. It was caught because of horrible performance causing issues on a server which a Microsoft engineer investigated. No one spotted it based on the source code despite being present there.
Als Antwort auf GrapheneOS

@GrapheneOS @plumeros @globcoco @Uddelhexe the compiled output of proprietary code is often obfuscated to prevent reverse engineering. E.g. Adobe binaries are intentionally obfuscated. Saying closed source code can still be reviewed drastically misrepresents the difference in difficulty.
Als Antwort auf Howard Chu @ Symas

@hyc @plumeros @globcoco @Uddelhexe The topic isn't obfuscated code but rather iOS compared to AOSP including the Linux kernel. iOS doesn't obfuscate the OS code and a large amount of public external research has been done on iOS. The overall system is closed source and the parts which are semi-open-source have the code released very late, but understanding the compiled code is hardly starting from scratch. You're responding as if this thread is about dealing with highly obfuscated software.
Als Antwort auf econads

@econads @plumeros @globcoco @Uddelhexe

> and without the sources to compile yourself, how can you be sure they match?

If you're reviewing the compiled code, you don't need to verify anything matches. That's only relevant to reviewing source code and needing to verify the compiled code matches via reproducible builds which are often not supported.

Als Antwort auf GrapheneOS

@GrapheneOS @globcoco @plumeros @Uddelhexe it's the absolute basic of security, not a guarantee. It's the auditability. If something is closed source you can't check whatever claims it wants to make.
Als Antwort auf econads

@econads @globcoco @plumeros @Uddelhexe

> it's the absolute basic of security, not a guarantee. It's the auditability. If something is closed source you can't check whatever claims it wants to make.

Having access to the source code does not provide the ability to avoid trusting the developers in practice. If it did, widely used projects like the Linux kernel would not have a massive stream of severe vulnerabilities being found which have been present for years and even decades in plain sight.

Als Antwort auf GrapheneOS

@econads @globcoco @plumeros @Uddelhexe The vast majority of open source projects get little to no external review. Nearly none receive in-depth privacy or security review. In general, people trust open source projects because source code is available and someone could audit the sources rather than because anyone is doing it.

The claim that only sources can be reviewed is incorrect and resembles dubious claims that open source is less secure due to attackers being able to find bugs more easily.

Als Antwort auf GrapheneOS

@econads @globcoco @plumeros @Uddelhexe Claiming that compiled code is infeasible or substantially harder to review to find vulnerabilities is effectively an endorsement of security through obscurity. You're implying attackers can find vulnerabilities in open source software much more easily. Most open source software does not receive external privacy or security review so it'd be an asymmetric advantage for attackers. Closed source software is NOT the black box you believe it is though.
Als Antwort auf GrapheneOS

@GrapheneOS @globcoco @plumeros @Uddelhexe wow 4 replies to replay what you already said. And I already said that open source doesn't guarantee security, it actually has to be audited and the rest yes. I can tell you from 18 years in the industry that companies are not completely trustworthy either (audience gasp), and most closed source software doesn't have internal audits either.

But why is closed source not a black box?

Unbekannter Ursprungsbeitrag

mastodon - Link zum Originalbeitrag
GrapheneOS
@pinpin @globcoco @Uddelhexe @plumeros Fairphones have atrocious privacy and security regardless of OS choice. See discuss.grapheneos.org/d/24134…. Fairphone 4 has an end-of-life 4.19 kernel and the Fairphone 5 kernel is end-of-life this month. They do not provide the long term support they claim in their marketing. They lag far behind on OS updates, do not properly update the kernel/drivers/firmware and lag behind on bare minimum AOSP security backports to older releases too.
Als Antwort auf GrapheneOS

@GrapheneOS @pinpin @globcoco @Uddelhexe

> Pixel with GrapheneOS
I like the intention of GrapheneOS to make a secure and privacy friendly OS.

But how much sense does it make to buy google HW for a de-googled OS?

Als Antwort auf GrapheneOS

@pinpin @globcoco @Uddelhexe @plumeros GrapheneOS is a production quality OS. GrapheneOS does not have issues with stability and does not require more maintenance. It doesn't sound like you've used it.

GrapheneOS is not a "custom ROM" and that isn't accurate terminology. It's not terminology we've ever used and we correct it when people incorrectly refer to it that way.

There are official parts and repair kits available for the devices we support for quite a long time.

Als Antwort auf Plumeros ☮️

@plumeros @pinpin @globcoco @Uddelhexe We use the only available reasonably secure hardware with proper alternate OS support. There isn't another option to use yet. The purpose of GrapheneOS is providing a highly private and secure OS. It's not about avoiding 1 particular company which has better privacy and security practices than their OEM partners. Each of their OEM partners follows their rules and includes the same deep privileged Google app/service integration so why does that matter?
Als Antwort auf GrapheneOS

@plumeros @pinpin @globcoco @Uddelhexe Our hardware requirements are listed at grapheneos.org/faq#future-devi…. There aren't any non-Pixel devices providing all of the hardware-based security features listed there and nothing else meets the requirements for updates either. We're working with a major OEM towards a subset of their devices meeting their requirements. Non-Pixel Android devices do not provide reasonable security. They cannot provide basic protection against widely used commercial exploits.
Als Antwort auf GrapheneOS

@GrapheneOS I did read that you use Matrix and Signal. Matrix is decentralized, so is it more secure than Signal? Which has better features for groups and group calls? And how was it about group encryption? Because I'm remembering that big groups was not encrypted right? If smaller Groups are encrypted, then I guess Matrix is more secure than Signal? Is the metadata issue still there? (Sorry for my questions, I ask because I'm comparing Signal vs Matrix for a long time switch with my contacts.)