@jcs The definition of openness used by Librem 5 is that a fully closed source device with closed source firmware and software would be open and freedom respecting as long as none of the firmware/software can be updated.

Purism prevents updating firmware for the SoC and calls it open even though the SoC is fully closed source hardware and does have closed source firmware, which just can’t be updated. They don’t count secondary components like radios. 99.999% closed source hardware isn’t open.

@jcs Librem 5 has atrocious privacy and security due to using a bunch of low security and outdated components, which are not open and do not have open firmware. Many components including the radios lack proper security updates. Purism does not provide the firmware updates through their OS and has set up a bunch of it in a way where it can’t be updated. They even went out of the way to move things to a locked down secondary processor to block updates. They claim if you can’t update it, it’s open.

@jcs Librem 5 has a fully closed source SoC, which means System on a Chip as opposed to a traditional desktop where the components would be part of a motherboard. The board schematics are for a basic PCB. It’s a nearly entirely closed source device in terms of where the actual complexity is. The SoC is the core component providing nearly all the base functionality. The SSD, memory, touchscreen, battery, Wi-Fi, Bluetooth, cellular, etc. are all closed source, as are various other chips, etc.

@informapirata @informatica It would not be the end of F-Droid, it would only require them to stop incorrectly using package names (application ids) not belonging to them. F-Droid doing that already causes issues and we’ve reported it as an issue many times for several years. Simply doing domain-based verification without ID verification similar to Let’s Encrypt would have caused problems for them too unless developers authorized the usage explicitly.

See our post at https://discuss.grapheneos.org/d/26966-f-droids-delevoper-statements-about-googles-registration/3.

@andreabont @informapirata @morrolinux @gnulinuxitalia We only recommend that apps already using the Play Integrity API and unwilling to remove it move to using this instead. This enables them to support arbitrary other devices and operating systems. Other attestation roots can be supported along with arbitrary alternate operating systems via allowing their verified boot keys. That’s much better than the Play Integrity API. We’d prefer if apps didn’t check the device/OS but they insist on it.

@pietro395 @tecnologia It won’t impact GrapheneOS negatively. The restrictions don’t apply to it and we’ve already dealt with the relevant aspects for sandboxed Google Play. Google Play already has Play Protect scanning and blocking app installs so we expect this to simply be an extension of it. It’s a total non-issue for GrapheneOS users. Google Play is not part of GrapheneOS. For people who install Sandboxed Google Play, they’re regular sandboxed apps and can’t block installing anything.

@shiva @informatica @informapirata We don’t think these are good recommendations for users who care about privacy and security. There’s a lot more to privacy than simply avoiding Google apps/services.

We recommend https://eylenburg.github.io/android/_comparison.htm for a high quality comparison between Android-based operating systems. The other OSes listed there do not keep up with privacy/security patches which is the bare minimum. CalyxOS updates have also recently been discontinued as a whole (https://calyxos.org/news/2025/08/01/a-letter-to-our-community/).

deleted by creator

@_Riccardo_ @sposadelvento @tecnologia They don’t want to define security standards and through that rule out using 50% of devices due to blatant security flaws. Instead, they want to provide the semblance of security through outsourcing everything to Apple and Google.

@_Riccardo_ @sposadelvento @simonestalfieri @tecnologia It’s not surprising for Samsung to lock the rest of their devices instead of only many of them. They were already not providing any serious alternate OS support. They made it difficult to support their devices and prevented doing it securely. They were only enabling hobbyist tier support for their devices due to how they crippled them.

We don’t expect any actual issues for GrapheneOS due to this radio-related regulation in the EU.

@_Riccardo_ @sposadelvento @simonestalfieri @tecnologia GrapheneOS does not cause any issues with respecting radio regulations. This directive applies equally to devices like desktops and laptops. It does not force blocking installing another operating systems. News media is reporting this inaccurately. Samsung never allowed installing GrapheneOS on their devices due to either fully locking them or crippling them when another OS is installed including not allowing using basic security features.

@sposadelvento @_Riccardo_ @tecnologia Practically, they’re going to give an inherent advantage to devices licensing Google Mobile Services by permitting them as a default. It would still be possible to permit other devices and operating systems. They’re choosing to do things in an extraordinarily anti-competitive way where alternatives are completely locked out of using the relevant apps rather than just a mildly anti-competitive approach where non-Google options need to deal with more.

@sposadelvento @_Riccardo_ @tecnologia It’s a problem because apps adopting this are mainly doing things how Google documents it without even considering the existence of GrapheneOS. For their digital ID and age verification standards, the EU should be defining actual security requirements based on their needs and then only enforcing those with it open to any devices or operating systems. They really shouldn’t give any special advantage to ones licensing Google Mobile Services.

@sposadelvento @_Riccardo_ @tecnologia Apps using the hardware attestation API can choose to trust more attestation roots than the Google ones and can also choose to support alternate operating systems via their verified boot key fingerprints. We document how to use it to support GrapheneOS when verifying device/OS/app integrity. This is more secure than the approach of using the Play Integrity API and there are no downsides for apps. The hard part is convincing them to do any extra work at all.

@_Riccardo_ @sposadelvento @tecnologia GrapheneOS is used with a locked bootloader. It not only has full support for verified boot and hardware-based attestation but significantly improves the security of these systems:

https://grapheneos.org/features#anti-persistence

@lka1988 @pineapplelover

You can see from https://eylenburg.github.io/android_comparison.htm that we have no limitations on call recording while others do. The fact that it’s manual means users are taking responsibility for it each time. It’s little different than recording a call with a tape recorder on speaker phone. If we did it automatically, then users would not be making a conscious decision to enable it case-by-case. That would be a problem, and not an acceptable way to do it without an extra explicit opt-in.

@lka1988 @pineapplelover

GrapheneOS does add call recording to our fork of AOSP Dialer. Unlike most alternate operating systems including LineageOS, we don’t limit the regions where it’s available. The fact that users are choosing to use it for specific calls means users are taking responsibility for the legality of recording that specific call and informing the other person of it. Automatic call recording would need more complexity to make it practical for people to comply with recording laws.

@lka1988 @pineapplelover

Why do you want to have a slow, legacy and hard to debug implementation of domain-based filtering instead of managing it with an app?

Domain-based filtering is also very limited in what it can since it’s trivially bypassed by apps or web sites using IPs or doing their own DNS resolution, which is fairly widely adopted. For example, WhatsApp will still work with the domains blocked. In practice, you’ll also only be filtering domains not used for useful functionality.

@lka1988 @pineapplelover

> System-wide hosts-based adblocking

That’s not a good way to do it.

> DNS/always-on VPN is not a reasonable solution

You don’t need to use a DNS service or VPN service to filter remotely. You can filter locally via the VPN service feature, including while using a VPN if you want.

You should follow our advice and do it with an app like RethinkDNS providing support for both local filtering and optionally using WireGuard VPNs at the same time including chained VPNs.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims and sets the maximum supported versions for Play services and the Play Store.