Google's Data Safety labels are basically useless. So I built something that actually checks.
Quick background: Google lets developers self-report what their app collects on the Play Store. Sounds fine in theory.
Except Oxford studied this in 2022 and found a ton of apps collecting data they never disclosed. Mozilla checked again in 2023. Same result. This has been replicated four times now across peer-reviewed research. Nobody's really talking about it.
So I spent the last year building AppXpose an Android scanner that looks inside the APK instead of trusting what the developer wrote on the label.
What it actually does:
- Detects tracker SDKs embedded in apps (~140 signatures, community-sourced)
- Scores permissions based on context (a flashlight app asking for location is different from a maps app)
- Checks the signing certificate for anything suspicious
- Looks up the APK hash in MalwareBazaar
- Spits out a 0-100 risk score
Everything runs on-device. No APK gets uploaded anywhere.
Instagram for example scores 68/100 HIGH.
Full scan: https://appxpose.app/scans/instagram
2000+ installs so far, 4.6 stars. Free tier gets 5 scans/week, Pro is lifetime and GUARD adds background monitoring (alerts when an app quietly picks up new permissions).
Still early days. Curious what the IH crowd thinks — what would actually make you trust a tool like this?
https://appxpose.app
How it works + the research: https://appxpose.app/blog/app-stores-lie-what-studies-actually-say
It’s wild how we just take "Data Safety" labels at face value when they’re basically just an honor system! Having a tool that actually looks under the hood instead of just reading the marketing brochure is a huge win for privacy. Running the scans on-device is the ultimate trust builder it’s great that you aren't becoming the very thing you're trying to expose!
What’s the most innocent-looking app that completely failed your risk score during testing?
Honestly the most surprising one was a basic flashlight app. No reason in the world to need your location, contacts, or an analytics SDK: but there it was, three trackers deep. The innocent-looking ones are almost always worse because nobody expects it.
Social apps people already distrust. It's the utility apps that catch you off guard.
The "what would make you trust this" question is the right one to ask aloud. From my own indie work — I'm shipping a small Captio-style iOS memo app, one-tap-to-email, no folders, no cloud — the thing early users mention unprompted isn't a feature, it's the absence of one: no account, no analytics SDK, no background uploads. On a privacy-first tool the real trust signal isn't your scoring rubric, it's a public reproducibility log: "scan this APK with these tools, get this score, here's the diff if it changes." Your on-device-only design already does the hardest part — proving it deterministically would lock it in. Curious: how do you handle the day a popular app silently swaps a tracker SDK between versions and your score shifts? That moment is either your best PR or your worst.
That moment is exactly what GUARD is for. It runs daily in the background and alerts you when a tracker appears or disappears between updates. So when a popular app silently swaps an SDK, you know before most people even notice there was an update. It also alerts you when one of our apps is victim to a databreach and 3 more different alerts such as permission changes, Ownershhip change & Store removal.
If we catch something real and name it, that's the best case. If we flag something that turns out to be a false positive, that's the worst. Which is why the detection is signature-based and deterministic either the package path is there or it isn't. No fuzzy scoring on that part.
Interesting angle. A lot of trust systems break when disclosure is self-reported with no real verification. In markets like that, independent auditing often becomes more valuable than another layer of labels or promises.
The on-device approach is smart too, privacy tools usually need to earn trust in how they operate, not just what they claim.
Yeah, self-reported with no verification is just marketing with extra steps. On-device was a deliberate choice too. if you're building a privacy tool, you can't ask people to just trust you.
Exactly. Trust tools get judged twice, once on what they detect, and once on whether people trust the tool itself. If either side feels weak, adoption drops fast.
The strongest part here is not the scanner. It’s that you turned “privacy concern” into something inspectable.
Most privacy tools stop at vague warnings.
The useful shift is giving users something concrete enough to verify before trust gets outsourced to app store copy.
AppXpose feels strongest where it stops being a scanner and becomes a trust layer people can check before installing anything. That’s the part worth leaning into harder.
That's the use case I want to push harder. Most people only scan after something already feels wrong that's too late.
Exactly.
The real shift is whether users treat it like:
“scan this app for me”
or
“check if this is safe before I trust it”
Those are very different products.
One is a utility.
The other is a trust layer people build behavior around.
That’s probably the line worth pushing hardest.
The second one also drives way better retention. Someone who checks before installing comes back every time they download something new. That's a habit loop.
Honestly flipping that default is the hard part. Most people still open it reactively. Onboarding is where I need to push that framing harder.
Exactly.
Reactive use makes it a scanner.
Pre-install habit makes it infrastructure.
That shift is bigger than onboarding.
It changes what the product is in the user’s head.
If people open it after doubt, it behaves like a utility.
If they open it before trust, it becomes part of the install decision itself.
That’s the stronger habit.
The only thing I’d pressure-test is whether “AppXpose” reinforces that trust layer enough, or still frames it more like a scanner than a pre-trust product.
Honestly the name probably still frames it as a scanner. "Xpose" implies revealing something that's already there reactive by nature.
The product behavior is closer to infrastructure but the branding doesn't say that yet. We have already informations about 4000 apps + so I could just make this feature usable pre install. Users could get their information even before installing an app.
This is something that I was thinking about , but it got pushed in the back of my head. Glad that you brought this up! Will defnitely work on this!
That’s the real constraint then.
If the behavior is shifting toward pre-trust infrastructure, but the name still frames it as reactive scanning, the brand is teaching the wrong habit.
That usually becomes expensive fast.
Because now the product is trying to build:
“check before trust”
while the name is still teaching:
“inspect after doubt”
That mismatch is exactly where habit formation gets slower than it should.
Very useful
Oh. So, instagram is safe enough or also doing some malicious data collection?
Instagram is owned by META - its even worse. They collect everything. We have a few scan studies on the website you can check out: https://appxpose.app/scans/instagram
This is actually really interesting, especially since you're validating against real research instead of just assumptions.
The part that stands out to me is the trust gap — users are basically relying on self-reported data, which we already know isn’t reliable.
The scoring system (0–100) is a nice touch because it simplifies something that’s usually very technical.
One thing I’m curious about — how do you handle false positives or edge cases? For example, an app requesting permissions that seem suspicious but are actually required for a legitimate feature.
Also, do you see this more as a consumer tool or something developers/security teams would use?
I’m working on a marketplace product myself and dealing with a different kind of trust issue (users signing up but not taking action), so it’s interesting seeing how you’re tackling trust from a data/privacy angle.
False positives are actually something I thought about a lot. The permission scoring is context-aware. 45 Play Store categories. A flashlight app asking for location is very different from a maps app doing the same. That context changes the score.
Tracker detection itself is deterministic. Package path signatures. Either the SDK is in the APK or it isn't, no fuzzy matching.
Audience-wise it started as a consumer thing but the data is getting interesting for research too. 3000+ apps scanned, tracker co-occurrence patterns, permission anomalies. We'll see where that goes.
Your trust gap problem is real by the way. "This app has 12 trackers" doesn't make people act. "68/100 HIGH risk" does. Same data, different framing.
You can read full details on how it works:
https://appxpose.app/how-it-works
Self-report it's where Google have made a mistake ! There should be a third party like appXpose that scans if reports are actually right !
the big companies do all these fishy stuff on purpose . don't trust them ever believe me^^ Google and Meta are Data Giga Farms they know everything and they don't care about your privacy
love this! the self-reported label system has been broken forever. do you maintain the tracker list yourself or is it community sourced?
I seeded the base of the Tracker list with 87 Trackers. Our community found/added another 53 Trackers to it , so in total we are at 140 now, but the number is rising from time to time