Methodology
A scan starts from the build the app's store distributes, identified by its SHA-256. The Deep scan's model reads its decompiled code, manifest and resources, and every finding records its file. The trust checks, the label and the score on an app page are computed from the Deep scan's findings.
What a scan checks
The trust checks
Secure by Design
Whether the code of the build contains security issues rated high or above, such as a component any other app can start or a credential stored without protection.
Data Minimization
Which analytics, advertising and attribution SDKs the build contains, set against what the app's function needs.
Manifest Mismatch
Whether each data flow in the code (a data category collected, a recipient, an identifier, tracking) appears in the store listing's privacy statements and the privacy manifest. A build with no data flow has nothing to declare and passes, whatever those statements contain.
User Control
Whether the code contains a way to export the data an account has accumulated and a way to delete the account. An app with no account of its own that keeps its data on the device passes.
Truly Local
For an app that describes itself as offline or on-device: whether the code references network libraries or remote hosts.
When it applies
Child-Safe
For an app directed at children: whether the build contains advertising or analytics SDKs and permissions that children's apps leave out.
When it applies
Score and label
0 to 100
Computed from the findings of the latest public scan, category by category. Every app page shows the score beside its label.TRUSTED
This app cleared every trust check that applied to it, with no red flags.TRUSTish
This app did not meet one of the trust checks that applied to it, with no red flags.unTRUSTED
This app did not meet two or more trust checks, has a critical issue in one, or has a red flag.NOT ASSESSED
This app has an open trust check or a verdict held for review.
Rescan policy
A public page changes when a public scan completes. A rescan starts when the store listing shows a new version, when a signed-in person requests a free rescan, or on the scheduled rescan of every public app.
Each update keeps the previous scan as a dated entry under "Changes since the previous scan". A page older than 90 days shows a notice with the scan date. Each page is rewritten by its next scan, which applies the current rules and wording, and names the rule pack it was produced under.
Right of reply
A developer replies to a page, or reports a factual error, by email to [email protected] from an address at the app's own domain or the contact address of its store listing.
A reply is published beside the page as written, with its date. A reported error opens a review of the match; a correction is dated and listed on the publishing policy. Findings change with rescans and rule corrections, and replies are published beside them.
What a static scan reads
Static analysis: the decompiled code, manifest and resources of this build, read file by file. Network traffic at run time is established by a capture of the running app.
A static scan establishes what the code, the manifest and the resources of one build contain. A transmission is established by a capture of the running app, and a page that states one cites the capture. Code loaded at run time and strings decrypted at run time are read in an investigation on rooted Android and jailbroken iOS devices.
A rule set is possibly non-compliant when the build contains a trace (such as an ad SDK initialised at startup, or a read of the advertising ID) that makes the rule set likely non-compliant if a condition outside the build is true: the user's region, the captured traffic or the privacy policy text. The status statement names the trace and the evidence still needed.
Rule families in the rule catalogue
Every rule is versioned and pinned by its hash, and a match records the file and line it was found in. The rule pack has 21 families.
SDKs
- Advertising SDKs: Ad networks and mediation adapters present in the code.
- Ad fraud: Code and hosts of known ad-fraud operations.
- Analytics: Analytics and crash-reporting SDKs.
- Attribution: Install-attribution and deep-link SDKs.
- Data brokers: SDKs of companies that trade in location and device data.
- Data sale: SDKs whose documented purpose is the sale of user data.
- Residential proxy SDKs: SDKs that turn a device into an exit node for third-party traffic.
- Session replay: SDKs that record screens and interactions.
Build and manifest
- Keys and secret files: API keys, account ids and credential files present in the build.
- Known-vulnerable libraries: Library versions with published CVEs and Play security notices, on Android and iOS.
- Obfuscation: Packers, string encryption and encrypted native libraries.
- Consent: Consent frameworks and the order in which SDKs start.
- Children: Declared, signalled and inferred child audiences, the SDKs, identifiers and data practices found in such apps, and the age mechanisms they lack.
- Store declarations: The store listing's privacy statements compared with the code.
- Network posture: Cleartext traffic settings and network security configuration.
- Permissions: Sensitive and special permissions the manifest requests.
- Manifest and debug flags: Exported components, debug and backup flags.
- VPN and web views: VPN services and web view settings.
- Surveillance apps: Hosts, packages and strings that researcher reports tie to named surveillance and monitoring tools.
- Banking trojans and botnets: Hosts, packages and strings that reports tie to banking trojans, droppers and botnets.
- Carrier billing: Hosts and code paths of reported carrier-billing subscription operations.
Independence
Every score is computed from the app's code and nothing else. Researchers, commissioned work and donations fund the site; the apps we rate pay nothing.
Which scans become public pages, and the three grounds on which a page is removed, are set out in the publishing policy.