How AppXpose
actually works.
Privacy claims are easy to make and hard to verify. This page documents the full pipeline: every step, every scoring factor, every data source, and every thing we don't touch. If something here is wrong, email mahere@appxpose.app and we will fix it.
Wie AppXpose
wirklich funktioniert.
Datenschutz-Versprechen sind leicht gemacht und schwer zu verifizieren. Diese Seite dokumentiert die komplette Pipeline: jeden Schritt, jeden Scoring-Faktor, jede Datenquelle und alles, was wir nicht anfassen. Wenn hier etwas falsch ist, schreib an mahere@appxpose.app und wir korrigieren es.
You pick an app
AppXpose lists every app installed on your device via the Android PackageManager API. You tap one. Nothing happens until you do.
We unpack the APK locally
The PackageManager hands us the installed APK file path. We read its DEX bytecode and AndroidManifest in-process on Dispatchers.IO. Bytes never leave the phone.
Pattern-match against known tracker signatures
Class names and package paths are compared against a curated signature set (sourced from Exodus Privacy, our own additions, and community-discovered patterns). Transitive dependencies from parent SDKs are deduplicated so the count reflects actual distinct trackers. This is deterministic pattern matching, not AI. See II. Detection methodology below.
Score deterministically, then AI-analyze
The local results are sent (HMAC-signed, no personal data) to our Cloudflare edge. A deterministic pre-score is calculated from multiple risk factors. Then an LLM generates the final score breakdown, the developer profile, the paywall analysis, and the natural-language explanations. See III. Risk scoring model.
You see a score and a story
Not just a number. What was found, why it matters, who made the app, where the data goes, and what changed since the last scan. You can save the report, share it, or vote on it for the community.
Everything lands in the App Library
Every scan result is stored in a local database — risk scores, tracker lists, permission audits, all timestamped. The App Library lets you browse, search, and compare your installed apps in one place. Filter by risk level, sort by last scan date, spot which apps got worse over time. It turns individual scans into a structured record of what is running on your device.
Du wählst eine App
AppXpose listet jede auf deinem Gerät installierte App über die Android PackageManager API. Du tippst eine an. Vorher passiert nichts.
Wir entpacken die APK lokal
Der PackageManager liefert uns den Dateipfad der installierten APK. Wir lesen den DEX-Bytecode und das AndroidManifest im selben Prozess auf Dispatchers.IO. Die Bytes verlassen dein Handy nie.
Abgleich mit bekannten Tracker-Signaturen
Klassennamen und Paket-Pfade werden gegen ein kuratiertes Signatur-Set geprüft (Quelle: Exodus Privacy, eigene Ergänzungen und community-entdeckte Patterns). Transitive Dependencies von Parent-SDKs werden dedupliziert, sodass die Zählung tatsächlich eigenständige Tracker widerspiegelt. Das ist deterministisches Pattern Matching, keine KI. Siehe II. Erkennungs-Methodik unten.
Erst deterministisch scoren, dann KI-Analyse
Die lokalen Ergebnisse gehen (HMAC-signiert, keine persönlichen Daten) an unsere Cloudflare Edge. Ein deterministischer Pre-Score wird aus mehreren Risikofaktoren berechnet. Dann erzeugt ein LLM das finale Score-Breakdown, das Entwickler-Profil, die Paywall-Analyse und die natürlichsprachlichen Erklärungen. Siehe III. Risk-Scoring-Modell.
Du bekommst einen Score und eine Geschichte
Nicht nur eine Zahl. Was gefunden wurde, warum es zählt, wer die App gemacht hat, wohin die Daten fließen und was sich seit dem letzten Scan geändert hat. Du kannst den Report speichern, teilen oder für die Community abstimmen.
Alles landet in der App-Bibliothek
Jedes Scan-Ergebnis wird in einer lokalen Datenbank gespeichert — Risikobewertungen, Tracker-Listen, Berechtigungs-Audits, alles mit Zeitstempel. Die App-Bibliothek lässt dich deine installierten Apps an einem Ort durchsuchen, finden und vergleichen. Filtere nach Risikostufe, sortiere nach letztem Scan-Datum, erkenne welche Apps sich über die Zeit verschlechtert haben. Sie verwandelt einzelne Scans in ein strukturiertes Protokoll dessen, was auf deinem Gerät läuft.
How we find trackers in bytecode.
Tracker detection in AppXpose is deterministic pattern matching, not AI. The LLM never decides whether a tracker is present. A signature either matches or it doesn't.
Signature sources
Match types
- →Package path prefix: e.g.
com.facebook.appevents,com.adjust.sdk. If a class in the DEX starts with this path, it's a match. Each signature is compiled to a regex at app start. - →Prefix deduplication: when a parent SDK (e.g.
com.google.android.gms.ads) matches, sub-packages likecom.google.android.gms.ads.doubleclickare not counted separately. Known transitive dependencies (e.g. Firebase Analytics bundled by AdMob) are suppressed when the parent is confirmed present. - →Suspicious class detection: classes that look like SDKs but don't match any known signature are flagged and sent to the server for community-driven discovery (see below).
Community tracker discovery
Every scan contributes to growing the signature database. When the DEX scanner finds classes that look like third-party SDKs but don't match any known signature, they are reported anonymously to the server. Once the same unknown class prefix appears in 3 or more distinct packages from different devices, it is auto-confirmed as a new tracker signature. Confirmed signatures sync daily to all devices via a background worker — no app update required. This means the detection engine gets better with every scan the community runs.
Note: estimated tracker information provided in the AI analysis section uses LLM knowledge and is always marked as "(estimated)". Only DEX-verified trackers are reported without a caveat.
Wie wir Tracker im Bytecode finden.
Die Tracker-Erkennung in AppXpose ist deterministisches Pattern Matching, keine KI. Das LLM entscheidet nie, ob ein Tracker vorhanden ist. Eine Signatur trifft entweder zu oder nicht.
Signatur-Quellen
Match-Typen
- →Paket-Pfad-Präfix: z. B.
com.facebook.appevents,com.adjust.sdk. Wenn eine Klasse im DEX mit diesem Pfad beginnt, ist das ein Match. Jede Signatur wird beim App-Start zu einem Regex kompiliert. - →Präfix-Deduplizierung: wenn ein Parent-SDK (z. B.
com.google.android.gms.ads) matched, werden Sub-Packages wiecom.google.android.gms.ads.doubleclicknicht separat gezählt. Bekannte transitive Dependencies (z. B. Firebase Analytics, das durch AdMob reinkommt) werden unterdrückt, wenn der Parent bestätigt ist. - →Erkennung verdächtiger Klassen: Klassen, die wie SDKs aussehen, aber keine bekannte Signatur matchen, werden gemeldet und an den Server zur community-basierten Entdeckung gesendet (siehe unten).
Community-Tracker-Entdeckung
Jeder Scan trägt zum Wachstum der Signatur-Datenbank bei. Wenn der DEX-Scanner Klassen findet, die wie Third-Party-SDKs aussehen, aber keine bekannte Signatur matchen, werden sie anonym an den Server gemeldet. Sobald derselbe unbekannte Klassen-Präfix in 3 oder mehr verschiedenen Paketen von verschiedenen Geräten auftaucht, wird er automatisch als neue Tracker-Signatur bestätigt. Bestätigte Signaturen werden täglich über einen Background-Worker an alle Geräte synchronisiert — kein App-Update nötig. Das bedeutet: die Detection-Engine wird mit jedem Scan der Community besser.
Hinweis: Geschätzte Tracker-Informationen in der KI-Analyse nutzen LLM-Wissen und sind immer mit „(geschätzt)" markiert. Nur DEX-verifizierte Tracker werden ohne Einschränkung gemeldet.
Two-phase scoring: deterministic, then AI.
Phase 1: Deterministic pre-score
Before the LLM sees any data, a deterministic scoring function runs on the server. It evaluates multiple risk signals including permission analysis (context-aware across 45 Play Store categories), update history, installation source, APK integrity, breach history, tracker presence, signing certificate verification, and known-malware database matches. Positive signals (clean history, no trackers, recent updates) reduce the score.
The pre-score produces a baseline from 0 to 100. Risk levels: LOW (0-29), MEDIUM (30-59), HIGH (60-79), CRITICAL (80-100). The exact weights and thresholds are part of our proprietary scoring engine and will be open-sourced with the detection engine.
Context-aware scoring
Permissions that are normal for one category are suspicious in another. A weather app asking for location scores differently than a flashlight asking for the same thing. Our scoring engine maps expected permissions across 45 Play Store categories and adjusts risk accordingly. This mapping is continuously refined by a data-driven baseline that learns from real scan data.
Phase 2: AI-assisted analysis
The pre-score and all raw data (permissions, trackers, breach status, app metadata) are sent to an LLM which generates the user-facing breakdown. The LLM produces six category scores visible in the app:
- Known Data Collection Practices
- Parent Company & Geopolitical Risk
- Estimated Trackers & Ad Networks
- Encryption & Data Transit
- Update Frequency & Patch Responsiveness
- Regulatory Compliance & Transparency
The LLM also generates: the developer profile (company, server locations, GDPR posture), the paywall and monetization analysis, the data-sharing probability estimates, and the natural-language explanations next to every finding. All AI-estimated data is explicitly marked as "(estimated)" in the app.
Zwei-Phasen-Scoring: erst deterministisch, dann KI.
Phase 1: Deterministischer Pre-Score
Bevor das LLM überhaupt Daten sieht, läuft eine deterministische Scoring-Funktion auf dem Server. Sie bewertet mehrere Risiko-Signale: Berechtigungs-Analyse (kontext-abhängig über 45 Play-Store-Kategorien), Update-Historie, Installationsquelle, APK-Integrität, Breach-Historie, Tracker-Präsenz, Signing-Zertifikats-Verifikation und Abgleich gegen Known-Malware-Datenbanken. Positive Signale (saubere Historie, keine Tracker, aktuelle Updates) reduzieren den Score.
Der Pre-Score erzeugt eine Baseline von 0 bis 100. Risiko-Stufen: LOW (0-29), MEDIUM (30-59), HIGH (60-79), CRITICAL (80-100). Die genauen Gewichtungen und Schwellenwerte sind Teil unserer proprietären Scoring-Engine und werden mit der Detection-Engine Open Source gehen.
Kontext-abhängiges Scoring
Berechtigungen, die in einer Kategorie normal sind, sind in einer anderen verdächtig. Eine Wetter-App, die nach Standort fragt, wird anders bewertet als eine Taschenlampe, die dasselbe verlangt. Unsere Scoring-Engine mappt erwartete Berechtigungen über 45 Play-Store-Kategorien und passt das Risiko entsprechend an. Dieses Mapping wird kontinuierlich durch eine datengetriebene Baseline verfeinert, die aus echten Scan-Daten lernt.
Phase 2: KI-gestützte Analyse
Der Pre-Score und alle Rohdaten (Berechtigungen, Tracker, Breach-Status, App-Metadaten) gehen an ein LLM, das das nutzerseitige Breakdown erzeugt. Das LLM produziert sechs Kategorie-Scores, die in der App sichtbar sind:
- Bekannte Datensammel-Praktiken
- Mutterkonzern & geopolitisches Risiko
- Geschätzte Tracker & Werbenetzwerke
- Verschlüsselung & Datenübertragung
- Update-Frequenz & Patch-Verhalten
- Regulatorische Compliance & Transparenz
Das LLM erzeugt zusätzlich: das Entwickler-Profil (Firma, Server-Standorte, DSGVO-Lage), die Paywall- und Monetarisierungs-Analyse, die Wahrscheinlichkeits-Schätzungen für Daten-Weitergabe und die natürlichsprachlichen Erklärungen neben jedem Befund. Alle KI-geschätzten Daten sind in der App explizit mit „(geschätzt)" markiert.
AI generates
- → Risk score breakdown (6 categories)
- → Paywall and monetization analysis
- → Developer profile (company, servers, GDPR)
- → Data-sharing probability estimates
- → Natural-language explanations
- → All marked "(estimated)" where applicable
AI does not
- → Detect trackers (that's pattern matching)
- → Check breaches (that's HIBP)
- → List permissions (that's the Android API)
- → Read your apps' content or data
- → Access your device outside the scan
- → Make the final tracker count (DEX does)
KI erzeugt
- → Risk-Score-Breakdown (6 Kategorien)
- → Paywall- und Monetarisierungs-Analyse
- → Entwickler-Profil (Firma, Server, DSGVO)
- → Wahrscheinlichkeits-Schätzungen zur Daten-Weitergabe
- → Natürlichsprachliche Erklärungen
- → Alles mit „(geschätzt)" markiert, wo zutreffend
KI macht nicht
- → Tracker erkennen (das ist Pattern Matching)
- → Breaches prüfen (das ist HIBP)
- → Berechtigungen auflisten (das ist die Android-API)
- → Inhalte oder Daten deiner Apps lesen
- → Außerhalb des Scans auf dein Gerät zugreifen
- → Die finale Tracker-Zahl bestimmen (das macht DEX)
We never collect
- Email addresses or accounts
- Google Advertising ID (AppXpose itself never reads it; AdMob may read it for free users who voluntarily watch a rewarded ad)
- IMEI, phone number, SIM data
- Location, contacts, photos
- App content or messages
- Persistent identifiers across reinstalls
We do collect
- Device fingerprint hash (rotates on reinstall)
- Quota counter (5 scans/week free tier)
- Anonymous community votes (no author identity)
- Scan raw data for ML training (package name, permissions, tracker matches, suspicious classes — no personal data, used to improve detection accuracy)
- APK signing certificate hashes (for CertNet trust-on-first-use verification)
Wir erfassen nie
- E-Mail-Adressen oder Accounts
- Google Advertising ID (AppXpose selbst liest sie nie; AdMob kann sie für Free-Nutzer lesen, die freiwillig eine Rewarded Ad anschauen)
- IMEI, Telefonnummer, SIM-Daten
- Standort, Kontakte, Fotos
- App-Inhalte oder Nachrichten
- Persistente Kennungen über Neuinstallationen hinweg
Wir erfassen sehr wohl
- Geräte-Fingerprint-Hash (rotiert bei Neuinstallation)
- Quota-Zähler (5 Scans/Woche im Free-Tier)
- Anonyme Community-Stimmen (keine Autor-Identität)
- Scan-Rohdaten für ML-Training (Paketname, Berechtigungen, Tracker-Matches, verdächtige Klassen — keine persönlichen Daten, dient der Verbesserung der Erkennungsgenauigkeit)
- APK-Signing-Zertifikat-Hashes (für CertNet Trust-on-First-Use-Verifikation)
Everything between phone and edge is HTTPS plus HMAC-SHA256. The HMAC key is a server-side secret that can be rotated independently of app updates, with a grace period where old and new keys are accepted simultaneously. The "device fingerprint" is a one-way hash of stable hardware characteristics. It cannot be reversed into a person, and it resets on reinstall or factory reset.
Alles zwischen Handy und Edge läuft über HTTPS plus HMAC-SHA256. Der HMAC-Key ist ein serverseitiges Secret, das unabhängig von App-Updates rotiert werden kann — mit einer Grace Period, in der alter und neuer Key gleichzeitig akzeptiert werden. Der „Geräte-Fingerprint" ist ein Einweg-Hash stabiler Hardware-Merkmale. Er lässt sich nicht zu einer Person zurückrechnen und wird bei Neuinstallation oder Werksreset zurückgesetzt.
Closed source. Here's why, and what changes when.
AppXpose is a solo project that is still in heavy development. The scan pipeline was rewritten multiple times in the last months as new detection approaches surfaced. Publishing the code today would mean publishing a moving target that breaks by next week. That is not useful to anyone.
The plan: once the detection engine's interfaces stabilize (the signature format, the scoring model inputs, the pipeline boundaries), the engine will be opened. Not the whole app, but the part that matters: the component that reads bytecode and decides what a tracker is. That is the part the community should be able to audit, challenge, and improve.
In the meantime, this page documents everything the code does and how. The code is closed. The methodology is not. If you find a gap in this documentation, email us and we will close it.
Closed Source. Hier ist warum, und wann sich das ändert.
AppXpose ist ein Solo-Projekt, das noch in heftiger Entwicklung steckt. Die Scan-Pipeline wurde in den letzten Monaten mehrfach umgeschrieben, sobald neue Erkennungs-Ansätze aufgetaucht sind. Den Code heute zu veröffentlichen, hieße ein bewegliches Ziel zu veröffentlichen, das nächste Woche kaputt ist. Das ist für niemanden nützlich.
Der Plan: sobald die Schnittstellen der Detection-Engine stabil sind (das Signatur-Format, die Eingaben des Scoring-Modells, die Pipeline-Grenzen), wird die Engine geöffnet. Nicht die ganze App, sondern der Teil, der zählt: die Komponente, die Bytecode liest und entscheidet, was ein Tracker ist. Das ist der Teil, den die Community auditieren, hinterfragen und verbessern können sollte.
Bis dahin dokumentiert diese Seite alles, was der Code tut, und wie. Der Code ist geschlossen. Die Methodik nicht. Wenn du eine Lücke in dieser Dokumentation findest, schreib uns, und wir schließen sie.
Found something we missed?
Security claims should be falsifiable. If you see a gap in this methodology, a factor we are not accounting for, or a claim that does not match reality, tell us. We will fix it and credit you in the next release notes.
mahere@appxpose.appWas übersehen?
Sicherheits-Behauptungen sollten widerlegbar sein. Wenn du eine Lücke in dieser Methodik siehst, einen Faktor, den wir nicht berücksichtigen, oder eine Aussage, die nicht der Realität entspricht, sag uns Bescheid. Wir korrigieren es und erwähnen dich in den nächsten Release Notes.
mahere@appxpose.app