Skip to main content

in reply to iodé

in reply to 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?

in reply to 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.
in reply to 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.
This entry was edited (1 month ago)
in reply to 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.
in reply to 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.
in reply to 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?

in reply to 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.
in reply to 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.
in reply to 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.
in reply to 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".
in reply to 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/

in reply to Coralie Renée

in reply to 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...?)

in reply to 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?

in reply to 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.

in reply to 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.

in reply to 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.

in reply to 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.

in reply to 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.
in reply to 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.

in reply to 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.

in reply to 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.

in reply to 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.
in reply to 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.
in reply to 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.
in reply to 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.

in reply to 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.
in reply to 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.

in reply to 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.

in reply to 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.
in reply to 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?

in reply to iodé

GraphineOS gives an option to randomly change the MAC addresses to avoid proximity tracking.
Unknown parent

mastodon - Link to source
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.
in reply to 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?

in reply to 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.

in reply to 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?
in reply to 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.
in reply to 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.)