Hacker News Reader

Comment by ignoramous | Hacker News Reader

rethinkdns dev here

> 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.

View on HN

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.

FWIW GrapheneOS does (it asks you before installing any app)

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.

Can you link to the documentation explaining how developers disable Internet permissions on iOS.

Unfortunately a race to the bottom is a bad thing, not an excuse

Or any other operating system...

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.

They also exist for Android, for that matter.

Depending on how blur you draw the line of os:

docker run --network none

For windows you go into the firewall settings and either set a deny rule for a specific executable or even set the default behavior to deny.

For linux there's a couple ways of setting up a process group that can't access your network.

I'm not very familiar with other OSes.

Why do you ask? Isolation between processes can be difficult on non-phone operating systems, but removing permissions tends to be quite easy.

My network security requirements have nothing to do with iOS. Can't we just collectively drop OS tribalism?

They have as much to do with iOS as the original commenters pet peeve has to do with the posted article.

How about you all slowly wean off this utterly dumb habit of ranting and raving about your pet problems in unrelated topics?

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).

still the same. Alphabet nor Apple have any real incentive to change this (commercial incentivization to maintain it notwithstanding).

Thats exactly the point that is being made, yes.

Google doesn't let you deny permissions for most of them.

As I understand it, apps that use the internet still need an entitlement, it's just that the Google Play store no longer shows that one in the list.

> As I understand it, apps that use the internet still need an entitlement, it's just that the Google Play store no longer shows that one in the list.

That's what it is, I think. The Play Store doesn't show it in the list of permissions anymore.

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.

Thank you, I missed the point of GP clearly. I use GrapheneOS and forgot you can't deny network access to an application in a "regular" Android.

It's just an example of an app that doesn't need internet access, yes flashlight is so useful it is built in to basically all phones now.

Netguard is an open-source program that helps fix this: https://netguard.me/

GrapheneOS does if you're willing to take the plunge.

Take the plunge to not do any banking on your phone.

It's an unfortunate limitation for a device I own to be handicapped this way.

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.

Do Android Auto and VoLTE / VoWiFi work on Graphene these days? I also remember Google Maps and Uber being extremely problematic

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.

Google Wallet is usable on GrapheneOS, but Google artificially restricts contactless payment functionality to Google-certified OSes.

It's not a real security check that they're doing, but rather just checking for certification, which is very unfortunate.

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.

[0]: https://grapheneos.org/articles/attestation-compatibility-gu...

Note that Android Auto has been supported in GrapheneOS for a while:

https://grapheneos.org/usage#android-auto

Ya kept wanting to try Android Auto but when they released I failed to find the toggle xD

Nowadays it's the Google's Find My Tag network which will be unsupported.

Android Auto is supported on GrapheneOS:

https://grapheneos.org/usage#android-auto

VoLTE and VoWiFi are supported if your carrier supports it.

Google Maps and Uber work fine, provided you install sandboxed Google Play.

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.

i hope you switched back, lol.

Your bank doesn't have a mobile website?

It does but have to use the app to deposit checks.

Go for a walk every day, and occasionally make your walk to an ATM?

You can also contact your bank and tell them that you want to be able to deposit checks via the Web site.

If enough people do this, and don't use the overly-proprietary app, the bank might listen.

>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.

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.

  who uses checks anymore, btw?

business organizations. the rest of your points are well said.

The nearest branch or ATM is 2+ hours driving. Desktop site doesn't do check deposits.

My banking apps worked for me on GrapheneOS once I installed Google Play services.

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.

Excluding phones, Linux desktop, and Windows which doesn’t have a better record in vulnerabilities, leaves out essentially MacOS!

Actually OTP hardware devices are a proper solution to this, but banks are mostly deprecating them, unfortunately.

and why do you think that is? *ponderingfaceemoji

banks and gov sites say it's because of security, but accept SMS. so we know what it's really about

I don't. Deliberately exposing people to risk for fun?

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.

I still hate it, but can't do much about it.

Using desktop and a phone as a second factor to confirm operations is relatively safe. At least compared to using only a phone.

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).

I've used GrapheneOS for years and I'm doing banking on my phone just fine.

The only 'banking' app I've had not work on GrapheneOS is Cash App, but then I just go to the website and use the web UI.

Is android.permission.INTERNET not a thing anymore? Unlike iOS, Android at least used to have this one.

I sometimes wish I could just configure that per-app as a user. Frustratingly, on iOS it's possible only for mobile data, but not for Wi-Fi – why!?

A possible answer is it’s not really a privacy setting but instead to save you from carrier data charges.

I agree that there should be an app firewall to the point I’m running an older phone w the checkm8 jailbreak to have a firewall.

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!

You can run WireGuard (as a proxy not a VPN; ie, TCP/UDP only) with Rethink DNS + Firewall, an app I co-develop: https://github.com/celzero/rethink-app

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.

On iOS it's also possible it's also possible to block Wi-fi data but only on iPhones sold in China: https://apple.stackexchange.com/a/312430

I'm on OxygenOS 12 and I have the option to disable mobile data and/or Wi-Fi for each app, not sure if other versions have that though.

That's what you get when you trust your device to commercial companies.

That's what you get when there are no practical alternatives.

Speaking of, did FairPhone get the whole "making a phone call" thing figured out yet?

That hypothetical Flashlight app, that uses location permission, would have never been approved in the first place.

https://support.google.com/googleplay/android-developer/answ...?

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)

Or... they can just use the builtin tile. This is such a bizarre offtopic theorycrafting fest based on decade old ideas.

Who said anything about location permission?

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 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.

Is that still available on recent One plus versions. I had that on my 5 and was appreciative.

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.

Reply on news.ycombinator.com