7 ms·

> All the existing apps are on Android and iOS. Graphene lets you run them. We have waydroid for that. > You can't have a bank account on a Linux phone* becau

> All the existing apps are on Android and iOS. Graphene lets you run them. We have waydroid for that. > You can't have a bank account on a Linux phone* because they won't let you, but you can on Android including on Graphene. Unless of course it uses those stupid integrity apis to block anything that isn't stock.

pteraspidomorph 2mo ago
Graphene passes basic integrity, so most of them work. There is a list here: https://privsec.dev/posts/android/banking-applications-compatibility-with-grapheneos/ https://privsec.dev/posts/android/banking-applications-compa...
- __MatrixMan__ 2mo ago
  If your bank requires you to use a device that is pre-compromised by Apple or Google, get a different bank.
  - deleted 2mo ago
    [deleted]
  - inigyou 2mo ago
    [flagged]
    - fsflover 2mo ago
      This is false, https://news.ycombinator.com/item?id=49363246 https://news.ycombinator.com/item?id=49363246
    - grapheneos 2mo ago
      Most European banking apps work on GrapheneOS. Many support tap-to-pay on GrapheneOS which is unique to Europe. Curve Pay is a financial service supporting tap-to-pay on GrapheneOS in the European Economic Area and UK. PayPal has tap-to-pay and permits using it with GrapheneOS but it's only available in parts of Europe. It's the rest of the world where tap-to-pay on GrapheneOS is an unsolved problem but that can and will improve.
imkac 2mo ago
Porting traditional Linux desktop distributions to Android devices is meaningless, all you get is more instability, more unsafe and more trouble. Waydroid is a bad implementation on security and compatibility, just running Android in VM is better.
- yjftsjthsd-h 2mo ago
  > Waydroid is a bad implementation on security and compatibility, just running Android in VM is better. What security problems does waydroid have that a VM wouldn't?
  - grapheneos 2mo ago
    Waydroid disables most of the Android privacy and security model through not having functional SELinux. SELinux is not simply an additional layer of security on Android but rather deeply integrated into the OS. The app sandbox and isolation throughout the OS are heavily built on SELinux. It also heavily depends on it for kernel attack surface reduction combined with internal kernel hardening via exploit protections. Waydroid uses an outdated fork of LineageOS running with namespaces and a compatibility layer on top of a much less private and secure base OS without similar kernel or userspace security protections. Running up-to-date AOSP in a virtual machine would at least be able to preserve the internal Android privacy and security model for apps to protect apps from each other and the OS from apps. It would also contain the overall OS within it too. Using the much less private and secure OS as the host OS with full access is quite backwards from a privacy and security perspective but would be a huge improvement. AOSP is much more private and secure than traditional desktop Linux distributions. Moving to that software stack is inherently going to be moving much further away from competing with the privacy and security of iOS. The direction taken by GrapheneOS is to start from AOSP and greatly improve the privacy and security it provides to compete with and exceed the industry standard privacy and security provided by iPhones. That requires more than only software. Hardware and firmware security are very important too. Software security also increasingly depends on hardware-based security features such as hardware memory tagging, hardware control flow integrity protections, hardware-based virtualization and much more. Keeping user data safe from access via encryption also depends on hardware security features for the vast majority of users not using a very strong passphrase. People take it for granted that they're going to have secure data via disk encryption with a random 6 digit PIN but that's not the case without a good secure element and OS integration with it. The approach used by desktop operating systems with TPMs is awful and makes security worse in a lot of ways rather than better. It's not at all the same thing, similarly to how what the desktop world calls secure boot is not a serious or complete implementation of it and doesn't provide nearly any useful security properties to end users unlike iOS or AOSP.
grapheneos 2mo ago
GrapheneOS primarily exists to greatly improve privacy and security compared to the Android Open Source Project (AOSP). AOSP provides far better privacy and security than a traditional desktop Linux distribution. It has a strong mandatory app sandbox, an increasingly good permission model moving more and more towards case-by-case consent, broad use of memory safe languages throughout the OS and app ecosystem, strong MAC/MLS policies developed as part of the whole OS, modern exploit protections, verified boot with downgrade protection for the whole OS and far more. GrapheneOS starts from the already good privacy and security of AOSP and greatly improves upon it. We greatly improve the permission model, exploit protections and much more but we depend on starting from a foundation that's already decent. Moving to a far less private and secure desktop software stack is going in the opposite direction from GrapheneOS. GrapheneOS doesn't exist to simply provide an alternative to mainstream operating systems but rather to offer much better privacy and security. We wouldn't be doing that if we were forking a desktop Linux environment and doing similar work for it. It would be nowhere close to the privacy and security of simply using an iPhone. That's a major part of why GrapheneOS is based on AOSP rather than it solely being about compatibility. Desktop distributions are incredibly far behind on privacy/security and lack any clear path to achieving the same things. Every year, Android makes backwards incompatible privacy and security improvements as part of a new target SDK version. Android retains compatibility with legacy apps, but apps distributed through the Play Store (and other app stores to an extent) are required to move to the new target API level within around a year. This results in apps being forced to conform to a gradually improving privacy and security model. There's no such thing for desktop Linux apps but rather apps choose how much they want to participate in nascent sandboxing efforts. GrapheneOS has near perfect compatibility apps from the Play Store via our sandboxed Google Play compatibility layer with the exception of banking and government apps. 90% of banking apps currently work on GrapheneOS because it greatly succeeds all of their security requirements and is only wrongly banned by a subset of those apps. These apps are gradually adding more anti-tampering and attestation checks for the hardware and OS, so maintaining compatibility has required us to gradually add more functionality working around it. We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it. A growing number of apps are choosing to stop banning using GrapheneOS due to pressure from our expanding userbase. Waydroid uses namespaces and a compatibility layer to run an outdated fork of LineageOS. It's far from providing full functionality and compatibility with apps and nowhere close to the compatibility provided by GrapheneOS. More importantly from our perspective, Waydroid disables most of Android's standard privacy and security model through not supporting SELinux and other core parts of the security model. Android doesn't simply use SELinux as an additional layer of security with targeted policies but rather it's deeply integrated into the OS. It uses very strong whole system policies to implement the app sandbox, drastically reduced kernel attack surface and a lot more. Namespaces for the overall userspace environment are not a replacement for the app sandbox, kernel protections, verified boot and the rest of the security model.
freedomben 2mo ago
I haven't tried using Wade Droid on a phone, but on a fedora desktop it is a little bit rough. It takes a lot of finagling to get anything that requires Google services running, and that is a surprisingly huge amount of apps that people want

pteraspidomorph 2mo ago

Graphene passes basic integrity, so most of them work. There is a list here: https://privsec.dev/posts/android/banking-applications-compatibility-with-grapheneos/ https://privsec.dev/posts/android/banking-applications-compa...

__MatrixMan__ 2mo ago
If your bank requires you to use a device that is pre-compromised by Apple or Google, get a different bank.
- deleted 2mo ago
  [deleted]
- inigyou 2mo ago
  [flagged]
  - fsflover 2mo ago
    This is false, https://news.ycombinator.com/item?id=49363246 https://news.ycombinator.com/item?id=49363246
  - grapheneos 2mo ago
    Most European banking apps work on GrapheneOS. Many support tap-to-pay on GrapheneOS which is unique to Europe. Curve Pay is a financial service supporting tap-to-pay on GrapheneOS in the European Economic Area and UK. PayPal has tap-to-pay and permits using it with GrapheneOS but it's only available in parts of Europe. It's the rest of the world where tap-to-pay on GrapheneOS is an unsolved problem but that can and will improve.

imkac 2mo ago

Porting traditional Linux desktop distributions to Android devices is meaningless, all you get is more instability, more unsafe and more trouble. Waydroid is a bad implementation on security and compatibility, just running Android in VM is better.

yjftsjthsd-h 2mo ago
> Waydroid is a bad implementation on security and compatibility, just running Android in VM is better. What security problems does waydroid have that a VM wouldn't?
- grapheneos 2mo ago
  Waydroid disables most of the Android privacy and security model through not having functional SELinux. SELinux is not simply an additional layer of security on Android but rather deeply integrated into the OS. The app sandbox and isolation throughout the OS are heavily built on SELinux. It also heavily depends on it for kernel attack surface reduction combined with internal kernel hardening via exploit protections. Waydroid uses an outdated fork of LineageOS running with namespaces and a compatibility layer on top of a much less private and secure base OS without similar kernel or userspace security protections. Running up-to-date AOSP in a virtual machine would at least be able to preserve the internal Android privacy and security model for apps to protect apps from each other and the OS from apps. It would also contain the overall OS within it too. Using the much less private and secure OS as the host OS with full access is quite backwards from a privacy and security perspective but would be a huge improvement. AOSP is much more private and secure than traditional desktop Linux distributions. Moving to that software stack is inherently going to be moving much further away from competing with the privacy and security of iOS. The direction taken by GrapheneOS is to start from AOSP and greatly improve the privacy and security it provides to compete with and exceed the industry standard privacy and security provided by iPhones. That requires more than only software. Hardware and firmware security are very important too. Software security also increasingly depends on hardware-based security features such as hardware memory tagging, hardware control flow integrity protections, hardware-based virtualization and much more. Keeping user data safe from access via encryption also depends on hardware security features for the vast majority of users not using a very strong passphrase. People take it for granted that they're going to have secure data via disk encryption with a random 6 digit PIN but that's not the case without a good secure element and OS integration with it. The approach used by desktop operating systems with TPMs is awful and makes security worse in a lot of ways rather than better. It's not at all the same thing, similarly to how what the desktop world calls secure boot is not a serious or complete implementation of it and doesn't provide nearly any useful security properties to end users unlike iOS or AOSP.

grapheneos 2mo ago

GrapheneOS primarily exists to greatly improve privacy and security compared to the Android Open Source Project (AOSP). AOSP provides far better privacy and security than a traditional desktop Linux distribution. It has a strong mandatory app sandbox, an increasingly good permission model moving more and more towards case-by-case consent, broad use of memory safe languages throughout the OS and app ecosystem, strong MAC/MLS policies developed as part of the whole OS, modern exploit protections, verified boot with downgrade protection for the whole OS and far more. GrapheneOS starts from the already good privacy and security of AOSP and greatly improves upon it. We greatly improve the permission model, exploit protections and much more but we depend on starting from a foundation that's already decent. Moving to a far less private and secure desktop software stack is going in the opposite direction from GrapheneOS. GrapheneOS doesn't exist to simply provide an alternative to mainstream operating systems but rather to offer much better privacy and security. We wouldn't be doing that if we were forking a desktop Linux environment and doing similar work for it. It would be nowhere close to the privacy and security of simply using an iPhone. That's a major part of why GrapheneOS is based on AOSP rather than it solely being about compatibility. Desktop distributions are incredibly far behind on privacy/security and lack any clear path to achieving the same things. Every year, Android makes backwards incompatible privacy and security improvements as part of a new target SDK version. Android retains compatibility with legacy apps, but apps distributed through the Play Store (and other app stores to an extent) are required to move to the new target API level within around a year. This results in apps being forced to conform to a gradually improving privacy and security model. There's no such thing for desktop Linux apps but rather apps choose how much they want to participate in nascent sandboxing efforts. GrapheneOS has near perfect compatibility apps from the Play Store via our sandboxed Google Play compatibility layer with the exception of banking and government apps. 90% of banking apps currently work on GrapheneOS because it greatly succeeds all of their security requirements and is only wrongly banned by a subset of those apps. These apps are gradually adding more anti-tampering and attestation checks for the hardware and OS, so maintaining compatibility has required us to gradually add more functionality working around it. We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it. A growing number of apps are choosing to stop banning using GrapheneOS due to pressure from our expanding userbase. Waydroid uses namespaces and a compatibility layer to run an outdated fork of LineageOS. It's far from providing full functionality and compatibility with apps and nowhere close to the compatibility provided by GrapheneOS. More importantly from our perspective, Waydroid disables most of Android's standard privacy and security model through not supporting SELinux and other core parts of the security model. Android doesn't simply use SELinux as an additional layer of security with targeted policies but rather it's deeply integrated into the OS. It uses very strong whole system policies to implement the app sandbox, drastically reduced kernel attack surface and a lot more. Namespaces for the overall userspace environment are not a replacement for the app sandbox, kernel protections, verified boot and the rest of the security model.

freedomben 2mo ago

I haven't tried using Wade Droid on a phone, but on a fedora desktop it is a little bit rough. It takes a lot of finagling to get anything that requires Google services running, and that is a surprisingly huge amount of apps that people want