How app traffic is studied

Two kinds of post room

Picture a post room at the end of your street. One kind of post room only writes down the address on every envelope, the time, and how heavy it is. Another kind steams each envelope open, reads the letter and seals it again.

Studying app traffic works at those same two levels. Most of the time you can see the envelopes (who an app talks to, when and how much). Seeing the letters themselves (what the app actually sends) takes a special set-up, and phones deliberately make that set-up hard.

Level 1: what your phone already tells you

The easiest place to start needs no tools at all. On iPhone, the App Privacy Report lists, for each app, the internet domains it contacted over the last seven days, and when it used permissions such as location or the camera (checked October 2026). Android's Privacy dashboard shows when apps used permissions such as location, camera and microphone, but not which domains they contacted (checked October 2026).

Level 2: watching the envelopes on your network

Every device on your home Wi-Fi asks for domain names and opens connections through your router. A tool that logs those lookups (some routers have one, and home DNS filters do it too) shows which companies a TV or phone contacts, how often, and how much data moves. The module Packets, DNS and IP addresses explains how those lookups work; here we only need the result: a list of names, times and sizes.

This level never reads the contents. Modern apps encrypt their traffic with TLS, the same lock that protects web pages, so the letters stay sealed.

Level 3: opening the letters (interception)

For the proxy to read encrypted traffic, the device must trust the proxy's own certificate. You met certificates in Leg 4 (lesson 82): they are the ID cards servers show to prove who they are.

Phones push back against this on purpose, because the same trick would let a stranger read your traffic:

• Android 7 and later: apps built for Android 7 or newer ignore certificate authorities that the user installed, unless the app's developer opts in (checked October 2026). This is the biggest barrier of all: on a normal phone, most apps simply refuse the proxy.
• iPhone: a CA you install is not trusted for websites and apps until you also switch it on in a separate trust setting (checked October 2026).
• Certificate pinning: some apps go further and accept only one specific certificate for their own servers, whatever the phone's list says.

So researchers usually work with spare test phones, emulators (a phone simulated on a computer), or their own apps built in a debug mode that opts in to trusting the proxy. We will not cover getting around these protections. They exist to protect you, and the labs in this module use captured logs we provide instead.

The ground rules

• Only study devices and accounts that are yours, ideally a spare test phone with a fresh account.
• Never install a proxy or certificate on someone else's device, and never watch other people's traffic on a shared network.
• Remove the proxy's certificate when you finish, so the device goes back to its normal protection.

A common misconception

"If the capture does not show it, the app does not send it." A capture shows one session on one day. An app may wait and send a batch later, behave differently in another country, send data from its own servers instead of from the phone, or switch on a feature only for some users. A capture is strong evidence of what was sent, and weak evidence of what was not.