If it would run a open source firmware or be open source hardware, it would be nice. But they are using a non-OSI/non-FSF license, so it is not open source.

I would argue that it depends a lot on what kind of beginner you have. If you have someone that only uses basic desktop PC functions, like browser, email and maybe stuff like video, photos and documents. You can set it up once, and then have a system that updates itself reliably and has minimal maintenance overhead and isn’t easy to break.

In my experience that system is more robust and gets updated than a generic Debian system.

Of course there are downsides, and those include issues caused by apps running inside flatpak, like system themes are disrespected, opening files in one app, doesn’t respect the xdg-mime settings for the file type and open them in unexpected apps, printer does not work… But those are just bugs, and they need to get reported and fixed.

Well, good to know.

I was thinking more about the way of Android security models, and that it would make sense for GOS to restrict available storefronts to stay consistent with their way to implement them. But good to know that it will not automatically happen just by updating the google services.

And I would also think that people would likely complain if they where to implement it in a different way.

Well… The Android security model, as it is implemented in stock android and GOS, is about top down control, the full trust is given to the system vendors, not the end users. No rooting for instance. From this perspective not allowing installation of apps that cannot be blocked by the system vendor, fits well with that model.

TBH, I am not a fan of that security model. And this is my critique of GOS. It doesn’t allow the user full access to their device, so that they can check and control what each application is storing or sending to third-party servers. Instead it is on full security and allows apps to store and transfer information to which the user has no access to.

But the system vendor/developers would have that access, because they control the whole base system.

The focus of the Android security model and in turn of GOS is on security, at the cost of privacy or freedom.

TBH I would actually expect GrapheneOS not to disable these checks. GrapheneOS devs pride themselves to have the best implementation of the official Android security model, and enforcing signature checks is likely part of that…

They might add additional certificates I guess, to allow their own apps, and maybe a selected few others.

Once it passes inspection, the F-Droid build service compiles and packages the app to make it ready for distribution. The package is then signed either with F-Droid’s cryptographic key, or, if the build is reproducible, enables distribution using the original developer’s private key. In this way, users can trust that any app distributed through F-Droid is the one that was built from the specified source code and has not been tampered with.

https://f-droid.org/en/2025/09/29/google-developer-registration-decree.html

The issue there AFAIK is that some app builds aren’t fully reproducible, because if they were the developer signature would still apply and be used. In the reproducible case the security of the build infra wouldn’t matter, because the same app would be produced the same regardless were they are build.

Without reproducible builds, you cannot really trust the software anyway, because the Dev could hook some hidden code only for the released binary app and sign that.

Na… The likelyhood of installing some bad or fake app from google play store is much higher than on fdroid.

The ‘availability’ is misleading. If they offer OpenVPN or Wireguard then there are available pretty much anywhere.