Comment by iancarroll
7 hours ago
A bit skeptical of how this article is written as it seems to be mostly written by AI. Out of curiosity, I downloaded the app and it doesn't request location permissions anywhere, despite the claims in the article.
I've noticed Claude Code is happy to decompile APKs for you but isn't very good at doing reachability analysis or figuring out complex control flows. It will treat completely dead code as important as a commonly invoked function.
The permissions snippet they show also doesn't include location, and you can't request location at runtime at all without declaring it there.
I'd verify all this stuff for myself, but Play won't install it in my phone so I can't really get the APK. Maybe because I use Graphene...? but I don't know all the ways they can restrict it, maybe it's something else (though for a pixel 9a it's rather strange if it's hardware based).
--- EDIT ---
To be specific / add what I can check, this is what my Play Store "about -> permissions" is showing:
which appears fairly normal, and does not include location, and I think Play includes runtime location requests there. Maybe there's a version-rollout happening, or device-type targeting?
> it doesn't request location permissions anywhere, despite the claims in the article
The article does not claim the app requests the location. It claims it can do it with a single JS call.
It can request with a JS call. It can't passively collect it without you approving first. The article is written like calling that JS function will turn on location tracking without consent.
He explicitly says he can't determine it, but that the location tracking as configured will turn on once the user grants consent. All true statements.
How would you have written it differently
4 replies →
> The article does not claim the app requests the location. It claims it can do it with a single JS call.
so can ... any other code anywhere on a mobile device? That is how API work...
You need to state the permissions you *may* request/use in AndroidManifest.xml. This data can then be displayed to users pre-installation.
From the (limited) article, it doesn't seem they do this: https://thereallo.dev/blog/decompiling-the-white-house-app#p...
----
EDIT: I'm mistaken. From the Play Store[0] it has access to
* approximate location (network-based)
* precise location (GPS and network-based)
[0] https://play.google.com/store/apps/details?id=gov.whitehouse...
This seems to disagree with:
> The location permissions aren't declared in the AndroidManifest but requested at runtime
*shrug*, someone should dig deeper. It looks like the article may not match reality.
2 replies →
what version are you on?
from the iphone app store: version 47.0.1 - minor bug fixes - 34 minutes ago
while the parent posted 18 minutes ago
they may have patched the location stuff as part of the “minor bug fixes”?
I have the iOS version from yesterday, haven't updated the app yet.
No location permission request prompting encountered. In system settings, where each app requesting location data is listed, it isn't present either.
how do you know it didn't lie during the decompilation?
It doesn't have to lie: unfortunately libraries that are essentially a full application themselves (complete with their own permissions) are not uncommon on mobile.
So it could come across a manifest that includes location permissions and some code that would (if enabled) send location, but it might do a bad job properly tracing