About CanITrustThat

Who runs CanITrustThat

CanITrustThat is run by CITT LLC, a US company. Filip Luchianenco runs it.

Filip is the named author of every teardown on this site. To reach him, email [email protected].

Why it exists

An app's store listing and privacy policy are the app maker's own account of what the app does with data. What the app contains is found in its code. What it sends is found in its network traffic.

Sometimes the app maker's account and the evidence differ. In our Mova AI Vacuum Cleaner teardown, the data label on Google Play was "No data collected." On the App Store, photos, videos and audio were listed. The captured traffic matched neither label.

We publish code excerpts and captured requests beside the findings they support. A reader can check the findings against that evidence instead of taking the app maker's word for it, or ours.

Who it is for

• Privacy researchers, journalists and lawyers who examine apps as part of their work.
• Companies that want an app checked before they use it.

Anyone can read the teardowns and the blog without an account. Accounts are for people 18 and over.

What we publish

We publish teardowns and blog posts. Scan results stay private.

Teardowns. One app, or one device and its app, tested in depth on real phones. Published so far: Reverse engineering and decrypting the Temu app on iOS and Android; Can we trust Mova AI Vacuum Cleaner?; Reverse engineering the Trump Accounts Android app (Robinhood wrapper).

The blog. News about app privacy: new laws, lawsuits, platform changes and security research.

How the work is done

Teardowns. Filip runs the app on test phones that give full access to the system. A certificate is a file a phone uses to decide which secure connections to trust. With his own certificate added to the phone, he can read the app's encrypted traffic, except on pinned connections (explained below). Where the question needs it, he also decompiles the app. Decompiling turns the installed app back into code a person can read. He then compares what the code contains with what the app sent. The devices and tools used are listed in each teardown's method section. For the Trump Accounts teardown, AI was also used to review the decompiled code; its method section gives the details.

Blog posts. CanITrustThat holds editorial responsibility for every blog post. Before a post is published, each claim in it is checked against the source it links to.

Scans in an account. Account holders can scan apps themselves. The app is downloaded from Google Play or the App Store, or the account holder uploads it. Android apps are decompiled. Apps from Apple's App Store are encrypted, so iOS apps downloaded from the App Store are first decrypted, then scanned.

• In a rule scan, the app's code and store listing are checked against a fixed set of 832 rules. The rules are sorted into 39 families, such as ad libraries, analytics and permissions. 478 of the rules are tagged with a law or an app store policy. Another 290 are helper rules: their results are used as evidence by other rules. For the same app file and the same rules, the findings are the same every time.
• Account holders can ask questions about an app's code. They can also run a Deep scan, an AI review of the app's decompiled code. The question and parts of the app's decompiled code are sent to Anthropic, whose AI models write the answers and the Deep scan findings. In the app, these are labelled as model answers and model findings.
• An answer about the app's code cites files in the decompiled app, often with a line number and quoted code. Before the answer is saved, each cited file, line and quote is looked up in the app's code. If a cited file or line does not exist, or the quoted code is not in the file, the answer is rejected. A passed check means the cited code exists. The reasoning in the answer is still AI output and can be wrong.
• Network captures run on Android phones, for Android apps. For a capture, the app is installed and used on a real Android phone while the phone's network traffic is recorded. A video of the screen and every request and response are kept. Values that identify the test phone, such as its advertising ID and location, are searched for in the recorded traffic. Requests sent before the app's consent screen (the screen that asks the user to agree to data use) was accepted are listed apart from those sent after.

Every scan an account starts is private, on every plan. A scan can be opened by the account that started it, by the other accounts on its team or project, and by CanITrustThat staff. A free rule scan can be opened only by the account that started it and by CanITrustThat staff. Which apps an account scans stays private too.

What the evidence can and cannot show

• What one version of an app contains is found by a scan of its code. Code that is present in an app may never run. Proof that the app sent data comes only from a capture of the running app, and that proof covers only the captured session.
• Some apps accept only their own certificate for some of their connections. This is called certificate pinning. Those connections stay encrypted and unread.
• AI output can be wrong. It is labelled as model output in the app, and it is a lead to check before anyone relies on it.

The full method and its limits are on the Methodology page.

How we earn money

Findings come from an app's code, store listing and privacy policy, and from its network traffic when we record it; we earn money from paid plans and commissioned work, we accept donations, and no payment changes a finding, a score, a label or a published page.

• Paid plans for account holders who scan apps.
• Commissioned work: investigations and custom packages a client pays us for.
• Donations.

How we treat visitors' data

• A security rule, called a Content Security Policy, is sent from the site to each visitor's browser. Under this rule, the browser loads scripts (code that runs in the page), fonts and images only from canitrustthat.com.
• Every request to the site is routed through Cloudflare, our network and security provider. Cloudflare receives each request, including the visitor's IP address (the network address of their connection).
• Our web server records each request in a log, including the IP address, to run the site and protect it from abuse.
• Page views and session recordings (a replay of the page layout, clicks and scrolling, with all text hidden) are sent to PostHog, a US analytics company, through our own server. Before they are sent on, the visitor's IP address and cookies are removed on our server. The page views and recordings sent to PostHog contain no email address or account ID.
• On public pages, the site sets one cookie, theme, and only when a visitor picks light or dark mode. When someone signs in to the app, a second cookie, citt_signed_in, is set for the whole site. Its value is 1, the same for every account.
• In the European Economic Area (the EU plus Norway, Iceland and Liechtenstein), the UK, and anywhere we cannot tell where the visitor is, page views and recordings are sent only after the visitor says yes.
• In most US states, Washington, DC, Australia, New Zealand, Japan and Singapore, page views and recordings are on by default. This is stated in a banner on the page, with a button to stop recording.
• Everywhere else, page views are on by default, and recordings start only after the visitor says yes.
• In recordings, all text and form fields are masked (hidden from the recording).
• Global Privacy Control and Do Not Track are privacy settings a browser can send to every site. When either one is turned on, page views and recordings stop being sent.
• Anyone can email [email protected] to ask for a copy of their personal data, a copy in a format they can take elsewhere, a correction or deletion, or to object to or limit how we use it. We answer within 30 days.

The full details are in the Privacy notice and on the Cookies page.

Corrections and replies

Anyone can report an error to [email protected]. Send the page address and what is wrong.

When we correct a teardown or a blog post, the corrected piece shows the date of the correction and what changed.

A company named in a teardown or a blog post can send a reply. We add the reply to the piece, with its date. So we can confirm who sent it, write from an email address at the company's own domain, or from the contact address on the app's store listing.

Contact

Email [email protected].

• An error on a page. Send the page address and what is wrong.
• A company's reply. Write from an email address at the company's own domain, or from the contact address on the app's store listing.
• Press and other questions. Email the same address.
• Commissioned work. Send a brief on Work with us, or email.

We are also on LinkedIn.