HybridStatAnim8

That is not true. AOSP can run all modern android apps, and google play APIs are provided as alternatives, but not replacements, for AOSP functionality.

Android and IOS encrypt your device. Most modern phones do, that is not specific to GrapheneOS and is an important, generic part of data safety that has been used for decades.

GrapheneOS offers a duress PIN/password, not button, that is solely up to the user to use as they see fit. The threat model for its use is on the user to determine, and the example you are referring to was a judgement that person made. That decision is independent of GrapheneOS.

Whether or not it was a blunder can only be known by the person who used it. Maybe it was a miscalculation, or maybe they were trying to hide something of importance, like protected contacts in an authoritarian country. We cannot know.

Duress PIN is for when the consequences of having the data are worse than erasing the data. This is very important for journalists or citizens of an authoritarian government. The judgements these people make are not a reflection of GrapheneOS.

GrapheneOS has ~500000+ users and climbing. It is getting rapid mainstream awareness and appeal and is partnered with a top 10 OEM.

I assume many people would use it due to SMS concerns and difficulty having people move to other platforms. I would personally use it as a fallback to Signal since my current fallback is SMS, which I dont like.

If the protocol is properly e2ee, it does not matter who backs it or hosts it. GrapheneOS would be in control of the client which is what matters in an e2ee system.

Yes, the GPLv2 license does not have the same restrictions GPLv3 does, it does not necessitate making the code it is bundled with GPLv2.

It is true, and if Ubuntu is shipping apps as a part of the OS with incompatible licenses, that is a crime.

The Refra gallery fork would replace the current ancient gallery app. That would be bundled with the OS. Doing the same with the fossify suite or similar would be illegal. These licenses do not treat apps or libraries differently. GPLv3 code forces the code that it is bundled with to also be GPLv3.

What? The Messages overhaul has been going on in the background for months. They announced it near the end of the port rather than the start. What is wrong with that? It has nothing to do with AI.

You can check github and see this development has been going on for awhile.

If you are referring to Heliboard as an AOSP board replacement, that cannot work, GrapheneOS cannot use GPLv3 projects.

If you mean it as a user installed app, please disregard.

Maybe, but there are better candidates GrapheneOS is more interested in.

They cannot. The license FUTO uses is not open source and is incompatible with being bundled with GrapheneOS.

The AOSP is fully open source. What you suggest is a significant step back in terms of privacy and security.

If you have used GrapheneOS, you know Messaging is positively ancient and bitrotting. The overhaul makes it look like the rest of the OS and uses standard material 3. Its not something to fear.

The point is to access an e2ee protocol bundled by default on many devices, and is cross-platform.

GrapheneOS does recommend using superior platforms like Signal, but that is 3rd party, and thus has adoptability issues in convincing people to use it. Just because better platforms exist does not mean RCS should be ignored.

The RCS spec has encryption in its documentation. I think the current spec version is 4.0?

GrapheneOS does not want to adopt RCS for public perception. It is still a better option than SMS/MMS and providing it is beneficial. GrapheneOS will still recommend using better platforms and protocols but RCS being bundled and cross platform are great reasons to implement it.

The main benefit of RCS is the fact it is available by default on other platforms like certified android and IOS. 3rd party messaging apps hit adoptability issues. A bundled, cross platform E2EE protocol is a huge step above SMS and MMS.

Many 3rd party platforms are still better though.

Their license is invalid due to being GPLv3. GPLv3 cannot be included in GrapheneOS as that would necessitate GrapheneOS give up their permissive licensing.

Refra Gallery is licensed as Apache 2.0, which is a permissive license GrapheneOS can bundle in the OS.

GrapheneOS is a privacy first project. Security is improved for the sake of privacy.

I think they mean "this is a terrible development" in the sense that this is terrible news/turn of events. They arent criticizing GrapheneOSs software development.

What problems are you referring to?

It is not petty to correct misinformation. You are downplaying the seriousness of the situation by painting it as some kind of drama. /e/OS objectively has poor privacy and security for numerous reasons, there was no "falling out", and GrapheneOS is not critiquing it based on emotion.

GrapheneOS is a privacy project first, does not come bundled with any google services, and only makes connections to 1st party services by default. /e/OS includes many google services with privileged OS integration. GrapheneOS is far more effective at the goal you state /e/OS has than /e/OS.

Refusing to work with organizations or individuals that are detrimental to privacy and security is not petty.

Murena does not provide private or secure products and has positioned itself to be against what GrapheneOS provides. A partnership with a company opposed to GrapheneOS and spreading misinformation about it would not be beneficial, and it is not petty to make the smart choice for the benefit of privacy and security.

That would not be viable because the hardware does not support it. It cannot be implemented in the OS because the OS can be turned off or exploited endlessly.

For GOS to consider it, it would likely need to be backed by the secure element.

Duress PIN is deemed acceptable to implement in the OS because it is expected that the user is the one to enter it, so it has not fallen into the hands of attackers who may bypass it. Once attackers have it, you are effectively gambling. Account for that in your threat model and do not let it get to that point.

At the time of writing, within ~12 months, in 2027, the 2027 Signature, Razr fold, and Razr flip will meet the hardware security requirements and should have official GrapheneOS support.

Motorola is currently porting GrapheneOS to their devices.

GrapheneOS does not offer a feature to wipe the device based on failed attempts.

That would be a bad idea. GrapheneOS operates under the assumption that every attacker has encyclopedic knowledge of GOS at all times. This is by far not an unreasonable assumption. GrapheneOS does not add features relying on ignorance that they exist.

The duress wipe feature shuts the device down to let RAM discharge, this is an important step to remove any components of decryption before they can be lifted.

Saying "and that is a fact" doesnt somehow make it a fact. Youre making stuff up. You will gain privacy by using GrapheneOS. The wifi and cellular hardware are not compromised.

GrapheneOS only supports devices that meet the baseline hardware security requirements. Pixels arent "poisoned" and there is no evidence to suggest any hardware backdoors exist, and quite a lot of evidence to show they dont exist.

GrapheneOS provides verification steps at the end of both installation methods to ensure your install is genuine.

This is not an issue with GrapheneOS, this is an issue with your configuration, which is trivial to solve.

All of those apps support using google services FCM for push notification delivery. I dont think Telegram has a fallback, and Signal and Whatsapp have power-intensive fallbacks. You may also need to reinstall these apps for them to detect google services (apps generally dont check for google services more than once on initial launch).