Comment by privacyishuman
5 days ago
There's five banking apps that support it specifically listed here [1]. I guess the dozen is not listed somewhere. Roblox, Hyundai, and Kia are also apps that officially support GrapheneOS. We should note that not all that are supporting it are using attestation.
I find all the people complaining about this to be rather insane. This is a completely open source linux distro getting official support from banks, some of the most legacy companies of all. This is good news. If companies are open-minded enough to support GrapheneOS, they're gonna be much more likely to also officially support other secure operating systems that are open source.
These are banking apps that weren't previously possible to be used on GrapheneOS. We're going from zero to one, not a step back.
[1] https://github.com/PrivSec-dev/banking-apps-compat-report/is...
GrapheneOS isn't a Linux distro it's an AOSP distro
I’d just like to interject for a moment. What you’re referring to as “Android,” is in fact Android/Linux, or as I’ve recently taken to calling it, Android plus Linux kernel.
Linux is not an operating system unto itself, but rather a kernel—a core component that manages hardware resources. Android uses the Linux kernel, but replaces the traditional GNU userland with its own runtime, libraries, and system framework.
Many users run Linux-based systems every day without realizing it. Through a peculiar turn of events, the Linux kernel combined with Android’s userspace is often simply called “Android,” and many of its users are not aware that it is built on Linux at its core.
There really is Linux in Android, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs you run. The kernel is an essential part of the system, but useless by itself; it can only function in the context of a complete operating system.
Android is normally used in combination with the Linux kernel: the whole system is basically Android/Linux, a Linux-based operating system with a distinct userspace, not a GNU/Linux system like traditional desktop distributions.
GrapheneOS and AOSP are Linux distributions. Linux is not glibc, systemd, GNU coreutils, GCC and GNOME. Linux doesn't have a specific libc, init system, command-line utilities, compiler toolchain, graphical environment or other userspace components. There are many Linux distributions beyond Android not using those components. There's no standard Linux userspace and a distribution using OpenRC, musl, Clang/LLVM, uutils coreutils and other software isn't somehow not Linux. Linux distribution doesn't mean systemd/GNU/Linux.
GrapheneOS and AOSP do use the userspace components developed with the Linux kernel such as iproute2. GNU components aren't part of Linux or the broader Linux project. Those don't even use a compatible license. It isn't legal to use the Linux kernel source code as a reference for writing glibc code since GPLv2-only does not permit the additional restrictions of GPLv3.
It's very difficult to convince these apps to officially support a single alternative to Apple and Google Mobile Services devices. Once they're convinced to it and have committed to it, it's much easier to convince them to support more alternatives. Many of these apps are required to check device and app integrity by government regulations or industry standards. The EU has defined multiple standards requiring it. Multiple of the EU standards have at least initially explicitly referred to the Apple App Attest API and Google Play Integrity API as ways to verify device and app integrity. People were unable to convince them not to do it. We convinced them to remove references to specific Apple and Google APIs from several standards. We were unable to convince them to define any actual requirements or especially to require permitting any OS or hardware meeting those requirements. We tried very hard to convince them to do that and were unsuccessful.
GrapheneOS has heavily pushed back against using attestation to permit only specific software and hardware for running apps and using services. We've convinced dozens of apps to stop doing it altogether. We haven't had much success convincing banking apps to stop using the Play Integrity API to enforce Google certification, but we have convinced at least around 6 companies published at least around 12 apps to use the Android key attestation API to permit GrapheneOS. Those apps can now also easily add other operating systems supporting verified boot too. They're now aware of this being a choice and are considering how to handle it instead of simply going along with the typical approach of permitting only Google certified hardware running the stock OS.
We defined a signed JSON format for distributing verified boot key hashes for use with the Android key attestation API. This can be implemented by other operating systems implementing verified boot, a mandatory app sandbox and support for passing the signing key hashes and version of an app using it to the standard hardware keystores. It can be implemented beyond Android-based operating systems.
Unless people can convince the EU and other regulators to move in the opposite direction, this is where things are headed for access to many important government, banking and other services. We've tried our best to convince the EU and others to stop heading down this path and to start forbidding apps and services from doing this instead. They've continued heading down this path and we're working hard to keep apps working and to roll back the gradual loss in compatibility with banking apps gradually adopting the Play Integrity API. We need our community to help heavily pressure apps using it to stop or provide an alternative. We're gradually having success due to our growing userbase and influence. Perhaps one day we can convince the EU and many countries around the world to forbid using attestation to limit which OS or hardware can be used but right now they're doing the opposite.