GrapheneOS has an OEM partnership with Motorola where they're working on improving their devices to meet our requirements because we won't lower our standards for updates and security features. A lot of work needs to be done for each supported device. There's a massive amount of work bringing the security-oriented, production-quality hardware memory tagging integration from Tensor to Snapdragon. We're working with Motorola and Qualcomm on it. If we simply ported it to many insecure devices we'd need have the time to work on features like this or the power to get an OEM and SoC vendor to work with us on it.
GrapheneOS has Contact Scopes and Storage Scopes for pretending all of the contacts, media and storage permissions are granted with the app unable to access any additional user data without the user explicitly adding it on a case-by-case basis. Unlike the recent iOS feature, apps can't see the Contacts permission group isn't granted and it supports giving less data than the whole contact too. It also supports labels for groups of contacts shared between apps.
Mock Location is a standard Android feature. We're working on a per-app Location Scopes replacement. We're also working on Camera Scopes and Microphone Scopes. We plan to continue down that road covering less major permissions too.
Sandboxed Google Play already works near perfectly with close to 100% app compatibility. It's only apps disallowing using a non-stock OS via the Play Integrity API or to a lesser extent certain other methods which aren't compatible. McDonalds is a major example. X forbids password login but you can use Vanadium to login with a passkey and then use that in the app. ~10% of banking apps do it but not most. We've convinced multiple banks to permit GrapheneOS, and that's going to become MUCH easier now.
This is very useful context. Especially around Contact Scopes etc. It's never made sense to me that iOS shares if the user is choosing to not share their contacts.
Apple seems to basically do privacy-related things to an 80% level but not bothering with getting it totally correct. This makes business sense because the extra 20% is way more difficult, but it's great to see GrapheneOS going all the way.
> We've convinced multiple banks to permit GrapheneOS, and that's going to become MUCH easier now.
I did not know that. That is very interesting.
On that topic, an honest question: what is the killer feature of banking apps that everyone is so hot on? Are we talking like retail banking or money transmitters? I am not using any bespoke banking apps, and I don't feel like I'm missing out, but maybe I just don't know what I'm missing.
What does detract from my GrapheneOS experience is the keyboard. It's just ok. I need swipe typing though, and I haven't found anything even close to gboard glide.
We are talking about banking and pseudo-banking apps with the following typical features:
* A wallet for QR-code based payments backed by a national standard for their content and by the money in your bank account;
* A software implementation of an NFC-enabled credit or debit card, or sometimes with a magnetic strip emulation in addition to that;
* An interface to transfer money to other bank accounts in the same country or abroad, or to convert between local and foreign currency if you have a foreign currency bank account;
* A way to pay common utility bills - in some cases, by scanning the QR code on the bill;
* A way to manage banking and investment accounts - e.g., if you want an extra savings account in Japanese yen with a new debit card attached to it, tap a few times and it's there;
* A chat with bank representatives - for example, to provide supporting documents by photographing them, without ever visiting the bank;
* A second factor (as in 2FA) to approve money transfers initiated from the desktop web browser, meeting the bank standards where TOTP can't meet them (e.g., due to the legal requirement to say what transaction the code is for).
The real problem is that many banks are deprecating their browser-based interfaces and are turning app-only.
> The real problem is that many banks are deprecating their browser-based interfaces and are turning app-only.
What bank does that? If my bank did that, I would find a new bank immediately. That is not OK.
Speaking about the Philippines here.
First, how about Philippine National Bank? Compare snapshots of their front page, https://www.pnb.com.ph/, on web.archive.org, and see that they have completely removed the link to their Internet Banking system. Only Mobile Banking remains.
See also https://web.archive.org/web/20220605084957/https://portal.pn...
Also, Metrobank threatens to make it impossible to log into their online banking website without the mobile app installed. This is already officially the case for their corporate banking, but it's just TOTP with a non-extractable (on a non-rooted phone) seed and some anti-root checks under the hood.
Finally, the following mobile wallets and "digital banks" are app-only: GCash, Maya, GoTyme Bank. The first two are the only ways to pay for water here, other than going to a kiosk where someone else would use their GCash account to process your payment.
> On that topic, an honest question: what is the killer feature of banking apps that everyone is so hot on? Are we talking like retail banking or money transmitters? I am not using any bespoke banking apps, and I don't feel like I'm missing out, but maybe I just don't know what I'm missing.
For me, the killer "feature" is that I need to generate an auth code on my bank's app to be able to log in to my account and make transfers via my browser (or I can use the app directly). In other words, it's considerably more difficult to actually do (retail) banking without my bank's app.
Got it. That makes more sense, i.e., that you're essentially required to use it rather than getting something in addition.
My bank's killer feature is that they're app-first and web-first because they only have one physical branch in San Antonio. They were one of the first banks in the nation to allow you to electronically represent checks for deposit, and they did that first through their web app and then later through their mobile app.
For the keyboard I recently discovered HeliBoard. You have to add a gboard's library to enable glide typing, but so far I really like it.
https://f-droid.org/packages/helium314.keyboard/
Woah. I've been looking around for months. That's huge. Thanks.
What, exactly, is sandboxed Google play prevented from accessing? Can I feed it a fake location or disable location access? Is it prevented from running in the background 24/7? Can I force it and just it through a VPN? Or is it just blocked from accessing apps and files that aren't in the sandbox? There are many such questions and all could be considered "sandbox".
Sandboxed Google Play receives no special access at all, so you can deny it all permissions if you want, but you should grant network (and maybe notifications) permission for it to actually function.
https://grapheneos.org/features#sandboxed-google-play
Well that's a bit misleading answer. Some apps refuse to work if G services are disabled, so they clearly communicate with them. It would be nice to know what exactly G learned about the phone through those "sandboxed" apps.
It's an Android service. But unlike on regular Android where Google play services have hard-coded special permissions, on Graphene it is an ordinary android service with all the same strict rules applying to it, as to any other service you could write.
So an application of course can use other android services if it declared that, that's why it can see whether it's running or not. But you are in full control whether google play services is installed, and what it can use.
Of course this may break certain apps (Google maps location sharing will probably not work with the location permission denied for play services), which may or may not degrade gracefully.
I denied the contacts permission to the Play Services. It just shows a notification when it tries to access them, which is actually not common at all.