0 calls logged
3 of 24 screens reached
0 flows completed
- Pinning rejected the re-signed certificate chain
- Login never returned, the feed stayed blank
- Session abandoned at the third screen
Every QA tool ships a network tab. To fill it, they install a root certificate and push your traffic through a proxy. Your app notices, the flows you wanted to test stop working, and the tab is empty anyway. We went the other way.
Amazon Shopping, one exploratory run on a real device. No proxy, no certificate, no code change. The run finished, so there is something here to read.
The run generated 443 requests across 24 unique hosts, totalling 51.5 MB of transferred data. Traffic is dominated by m.media-amazon.com at 42.5 MB and www.amazon.com at 6.06 MB. All captured sessions used the CONNECT method, with zero recorded errors.
Extreme latency was detected on core and telemetry hosts, with msh.amazon.com averaging 46.5 s and unagi.amazon.com at 14.2 s. Both m.media-amazon.com and data.amazon.com are bandwidth heavy, exceeding 1 MB per host. Several ad system and telemetry endpoints, including c.amazon-adsystem.com and api.mshop.bdtelemetry.amazon, are slower than 20 s.
Largest network consumers captured during the run.
There is one way to look inside an encrypted call without shipping extra code into the app: sit in the middle and re-sign the traffic. Every serious mobile app is built to catch exactly that.
A root certificate goes into the device store so a proxy can terminate TLS and re-sign every response on the way back.
Pinned certificates, TLS fingerprints, and attestation compare what arrived against what shipped. It does not match.
Login, search, cart, payments. Anything pinned errors out or retries forever, and the rest of the app crawls behind it.
The session dies a few screens in. You open the network tab you came for and there is almost nothing in it.
A TLS connection tells you plenty from the outside. Which host it went to, how often, how many bytes moved, how long it took, and whether it failed. We collect that at the device level, with no certificate in the trust store, so the app runs untouched and the session finishes.
That is a real limit and we are not going to dress it up. If you need a decrypted payload, do it once in a lab on a build with pinning switched off. It is a terrible default for every run on every build, which is how most teams end up with a network page they stopped opening.
Ads, attribution, telemetry, crash reporting, session replay. Every SDK in the build gets the same network access your own code has, and it points wherever the vendor decides. A version bump moves a host. A vendor that changes hands moves the whole endpoint. Nobody sends you an email.
One dependency is enough. A hijacked release, a domain someone re-registered, an analytics vendor that quietly changed hands. Review passes, the binary looks the same, and the app starts calling a host that was not there last week. That host is the whole signal, and it takes one run to see it.
Screen off, app parked in the background, session long finished. Telemetry keeps beating, ad SDKs keep bidding, attribution keeps posting. A manual tester never sees that traffic and a script stops at the last assertion. We keep capturing, so the quiet calls land in the report next to everything else.
You filled in a data safety form and a policy that names your processors. The host list is what the device actually did. If a build starts shipping events to an exchange or a broker nobody signed off on, read it in a report on your own build, not in a letter from a regulator.
Same session, ordered by how much explaining they need.
Put your own app here and the list reads differently: an attribution SDK, an ad exchange, a crash reporter, a replay tool, and whatever the next release drags in. We diff it run over run and say what moved.
Point FlyTrap at a build and the report shows up on the first run. Nothing to install on the device, nothing to strip out before you ship.