> these issues should be addressed in the OS in order to protect all Android users regardless of which apps they use.
Android's paranoid networking has always had an exception for System and OEM apps (which include Google apps). Most such bugs fixes are unlikely to fix that core assumption. Some code refs: https://github.com/celzero/rethink-app/issues/224
> The leak during tunnel reconnects is harder for us to mitigate in our app. We are still looking for solutions.
Android supports seamless handover between two TUN devices (on reconfiguration). It is tricky to get it right, but implementable.
To be fair, it’s the application developer who requests the application’s permissions and it is possible to release an app without internet permission.
I agree that the OS should have a way to override the permission, but it’s not Android itself just giving out internet access by default. It’s more that it’s almost every developer’s default setting when building the app.
The best example of no internet permission in an app off the top of my head is Hacker’s Keyboard – and you can understand why the developer chose to avoid it.
Which flashlight app? As far as I know there is no official flashlight app (though recently there is a built in flashlight feature). How is Google responsible for a third party app that refuses to work without an internet access?
> Which flashlight app? As far as I know there is no official flashlight app (though recently there is a built in flashlight feature). How is Google responsible for a third party app that refuses to work without an internet access?
GP is saying that the Android permissions model requires giving Internet access to any app you install from the Play Store; there isn't a way for an app to request "zero permissions" (or rather, there is, but basic Internet access is a permission granted to all apps, even when zero additional entitlements are requested).
That said, this isn't unique to Android. At least as of a few years ago, iOS did more or less the same thing. (You can disable an app's access to the local network, but that's not the same thing as denying (or requiring an app to request) basic network connectivity).
The hypothetical flashlight app that was used as an example to demonstrate the problem of not being able to take away the permission to access the internet from an app.
This depends on the firmware used. I am writing this comment from an Oneplus device which allows blocking internet access on a per-app basis - on a stock firmware.
Not universally true, I use banking apps on my Pixel running the latest GrapheneOS. There is literally nothing I cannot do on my phone. I think it's possible that no US banks have apps that can be used as it seems a universal experience among Americans.
Uber, Google Maps, VoLTE, VoWiFi, and eSIM work. You may need to install the sandboxed Google Play Services from the Apps app.
Android Auto is completely disabled as an opinionated security measure.
Google Pay and some banking apps (ones that require Google's Play Integrity API) will not run. GrapheneOS doesn't attempt to spoof these APIs because they are moving towards cryptographic verification [0]. Most apps don't require this check but if they do you are out of luck unless you can get the app developers to trust GrapheneOS's keys.
I think they work if you install Google Play Services (as a sandboxed app). What doesn't work for me is contactless payments with Google Pay however Google Wallet itself works. But I think that is actually intended and for security reasons.
Using banking apps on a phone is dangerous because if your phone gets hacked (and Linux kernel has extremely large attack surface), the attacker gets access to both the app's session and SMS codes that are used to confirm operations. People who use banking apps must be crazy or don't care about their money.
I think I do. It costs money and people in general don't appreciate it. Also while "malware on phone stealing money" is technically possible, it doesn't happen (much?), and most people get scammed in easier and more effective ways (see crypto) instead.
Can give one anecdote: I've been using Graphene for about a year and all banking apps work just fine. In fact, I've never had as little issues with any other custom rom. It's quite crazy just how good Graphene is.
Not a custom ROM maker, though I did get lost trying to plan one for my old Xiaomi Mi A3 (laurel_sprout). Another guy did make a unofficial LOS for it though.
Custom ROMs nowadays require you to be scouring Qualcomm out of tree source repositories (or firmware dumps of equivalent phones, I think, in the case of Mediatek). It's impossible to guarantee quality with this conditions. Even if you just want to have a pristine kernel tree of the original firmware you may find, if it was ever released, it was squashed on the wrong source commit (again, laurel_sprout, though a random Github angel fixed it).
So Google's devices tend, thankfully, to have better sources. Additionally, GOS team is competent and, for now, sustained full-time by donations. Those three conditions are what allow GOS to be a very good ROM.
Do note: it has its quirks, specially with the new trimestral code dumps by Google where half-baked features are on the source (though disabled by feature flags).
there is (or at least can be) some risk tolerance within any so-called 'threat model.' but i absolutely take your point and agree with you.
nary the case but i suppose if i absolutely needed to access any finances from my mobile device, it certainly wouldn't be from one of said institution's own mobile apps, but via web browser.
> i suppose if i absolutely needed to access any finances from my mobile device, it certainly wouldn't be from one of said institution's own mobile apps, but via web browser.
I used to do home banking from my bank's website. Recently, they created a digital-only branch for customers who mostly do home banking and only rarely need to go in person to the bank. They asked their customers if they wanted to switch and offered services at the same or lower cost than before. I made the switch, but found out that unfortunately the new website lacks some functionalities that are only available from the mobile app. I guess they are assuming that most people would just use their phone anyway and didn't bother to reach feature parity between the website and the app, preferring the app.
crazy. it's remarkable to me that lawyers actually do explicitly, if not expressly, account for these kinds of technical decisions, ultimately made in surreptitious fashion by the business, when drafting usage terms. i.e., you would've (or, a lawyer determind, should've) been able to find notice of this change somewhere buried in the new service terms. i at least have faith in that much.
Minor conveniences like this are not worth the complete erosion of privacy, in my opinion. Just go to the nearest ATM to deposit checks (who uses checks anymore, btw?) and use the site for everything else. Not everyone even has a smartphone, and out of those that do, many prefer banking on their laptop over their phone anyway, which incentivizes banks to create feature-rich websites. If the mobile site isn't any good, usually the "desktop site" isn't too difficult to navigate on mobile, if you need to.
>Go for a walk every day, and occasionally make your walk to an ATM?
There are workarounds, but it sounds annoying and a burden. What if the closest bank branch is an hour on foot away? Or the OP lives in a rural place and it's half an hour drive? I don't have this problem since my bank works with graphene, but I would reconsider using it if most applications I use refused to load.
As I understand, it installs a pseudo-VPN and passes traffic through it. I remember using similar app (NoRoot Firewall), and it worked poorly and couldn't block everything I wanted.
GrapheneOS is totally different to having an app on stock android
> GrapheneOS adds a Network permission toggle for disallowing both direct and indirect access to any of the available networks. The device-local network (localhost) is also guarded by this permission, which is important for preventing apps from using it to communicate between profiles. Unlike a firewall-based implementation, the Network permission toggle prevents apps from using the network via APIs provided by the OS or other apps in the same profile as long as they're marked appropriately.
>The standard INTERNET permission used as the basis for the Network permission toggle is enhanced with a second layer of enforcement and proper support for granting/revoking it on a per-profile basis.
> To avoid breaking compatibility with Android apps, the added permission toggle is enabled by default. However, the OS app installation UI has been extended to show the toggle as part of the installation confirmation page so users can disable it when installing an app.
> when the Network permission is disabled, GrapheneOS pretends the network is down. It shows the network as down in various APIs, returns errors showing a network connectivity issue rather than a revoked permission and avoids running scheduled jobs depending on the network. This results in apps handling it as if the network is down rather than crashing or showing errors from trying to use the network and being unable to do it.
Nope. GrapheneOS is an AOSP fork (with not so many modifications) intended to be more secure.
It doesn't do it in a hacky way, these apps just don't get the internet permission. And it lets you install Play Services as a normal app (not a system app) so you choose what permissions that gets.
On Android there is NetGuard which poses as a (local, running on the phone) VPN and allows you to deny / allow traffic based on process and domain. Works great, no root needed.
Then you can't run another VPN right? Then raw through Verizon with their tracking headers and stuff for anything non-https unless you go through the series of opt outs that get periodically invalidated with a new opt out needed.
Just checked, there doesn't seem to be an option for it (though technically it should be possible, I think). Sorry to hear about Verizon - hopefully mobile will soon be a viable option for you. Good luck!
IIRC, there's separate permissions for web access and unrestricted internet access. The former is only apparent if you look for it on install, and isn't something you can disable on most ROMs.
Third party app firewalls exist for at least macOS and Linux distros. It’s likely built in to the system as well, but you’d have to wrangle the command to do it in the terminal.
Did they edit their post? I just see "They don't even allow disabling internet permissions on a flashlight app, the OS is run by an internet ad company so it makes sense."
If you're implying that you need location permission to turn internet access into a tracking problem, you're wrong.
Play Protect and the approval process are mostly make-work because you don't have control over internet permissions--because Google needs them everywhere for their ads business they have to put a lot of energy into this edifice.
This is about the continuous background location permission. In the past years they have cracked down on this, yes. But nothing forbids you from requesting the foreground approximate or fine location permissions.
So yes, this hypothetical flashlight app can request the permission. The user has to allow it in some way - approx or precise, one-time or always. But also nowadays the users sees when & what app is requesting these kind of permissions. It's a moot point.
(For background location there's an extensive form in the play store, you even have to send videos in many cases - for foreground, there's nothing)
> these issues should be addressed in the OS in order to protect all Android users regardless of which apps they use.
Android's paranoid networking has always had an exception for System and OEM apps (which include Google apps). Most such bugs fixes are unlikely to fix that core assumption. Some code refs: https://github.com/celzero/rethink-app/issues/224
> The leak during tunnel reconnects is harder for us to mitigate in our app. We are still looking for solutions.
Android supports seamless handover between two TUN devices (on reconfiguration). It is tricky to get it right, but implementable.