Privacy & Compliance · Study deck

Mobile Privacy Leak Detection

A review can sound complete while still omitting the step that proves a fix.

Privacy Priya is your guide for this deck.

mobileprivleak

After studying this chapter

Learning objectives

You will be able to:

trace a data source to every network sink it actually reaches
inspect encrypted and hidden traffic paths for undisclosed data sinks
compare what an app sends against what its privacy declaration claims
Explain: A review can sound complete while still omitting the step that proves a fix.

Major section

Does the App Send Only What We Think?

A review can sound complete while still omitting the step that proves a fix.

The discipline matters because intentions are not evidence.
That order identifies two distinct review questions: what the library receives and what fields the product permits it to send.

SDK data-path review from an app event through a wrapper and field filter to an endpoint, with a disabled path and review evidence.

Major section

Trace a Source to Every Sink

The practical method is to take one sensitive source at a time and follow it to every sink, gathering evidence as you go.

Work on a test device or emulator, signed into a test account, so that anything you capture is your own.
The output is a short record per finding: the path the data took, the fix, and a test that fails if the leak returns.
A single source can flow through an SDK call, a network request, a local cache, a log line, and a crash report.

Major section

Inspection, Encryption, and Hidden Sinks

The deeper layer explains how runtime inspection actually reveals data flows, why encryption is not the same as privacy, and where leaks hide besides the network.

TLS protects data from the network in between, but it does nothing about who receives the data at the other end.
Encryption is necessary to stop eavesdropping, and finding sensitive data in plaintext is an obvious failure, but the absence of plaintext is not proof of good behavior.
The real test is what data leaves and to whom.

Major section

Catch an SDK Leak at the Field Boundary

A weather app records a screen event, but an analytics SDK quietly attaches the phone’s advertising identifier and precise coordinates before transmission.

The evidence record should show the actual request body, destination, trigger, and build state.
Each labelled hop is a place where the mobile privacy payload can grow or escape inspection.

Deck summary

Key takeaways

A review can sound complete while still omitting the step that proves a fix.

The practical method is to take one sensitive source at a time and follow it to every sink, gathering evidence as you go.
The deeper layer explains how runtime inspection actually reveals data flows, why encryption is not the same as privacy, and where leaks hide besides the network.
A weather app records a screen event, but an analytics SDK quietly attaches the phone’s advertising identifier and precise coordinates before transmission.

Retrieval practice

Recall check 1 of 4

Privacy Priya says: answer from memory, then check your reasoning.

Q1An app claims that location never leaves the phone. What evidence should a reviewer collect?

ARead only the app store description.

BCheck only that TLS is enabled.

CInspect only the main app server.

DTrace location from the sensor API to every network sink and capture what actually leaves.

Show answer

Answer: D A source-to-sink trace can reveal an unexpected recipient even over encrypted transport.

Retrieval practice

Recall check 2 of 4

Privacy Priya says: answer from memory, then check your reasoning.

Q2During review you find the app sends precise location to a third-party domain, but the connection is encrypted with TLS. Is this a privacy leak?

AYes; encryption hides data from the network, not the recipient

BNo; because the connection is encrypted, no privacy issue exists

CNo; location is never sensitive once it is sent over the internet

DYes, but only if the TLS certificate happens to be invalid

Show answer

Answer: A A flow can be fully encrypted and still be a leak, because the issue is who receives the data and whether it was disclosed and needed.

Retrieval practice

Recall check 3 of 4

Privacy Priya says: answer from memory, then check your reasoning.

Q3You changed the code so an analytics SDK should no longer receive device location. What best confirms the leak is actually fixed?

AThe code review approval of the change is sufficient confirmation

BA fresh capture with no location flow plus a regression test

CSeeing that the feature still works in the app proves the leak is gone

DDeleting the old network capture so the leak is no longer recorded

Show answer

Answer: B Observed behavior on a new capture confirms the fix, and a regression test stops the leak from quietly returning.

Retrieval practice

Recall check 4 of 4

Privacy Priya says: answer from memory, then check your reasoning.

Q4To inspect your own app's encrypted traffic during a privacy review, what setup is appropriate, and what does it tell you?

AIntercept other users' live traffic on a shared network to compare behavior

BAssume TLS makes inspection impossible, so skip runtime review entirely

CTurn off encryption in production so traffic is easy to read

DUse a controlled test device and trusted proxy for your own app payloads

Show answer

Answer: D Inspecting your own app on a controlled test device lets you read the actual payloads, which is what reveals hidden flows.

Print reference

Answers

Answer key.

D · A source-to-sink trace can reveal an unexpected recipient even over encrypted transport.
A · A flow can be fully encrypted and still be a leak, because the issue is who receives the data and whether it was disclosed and needed.
B · Observed behavior on a new capture confirms the fix, and a regression test stops the leak from quietly returning.
D · Inspecting your own app on a controlled test device lets you read the actual payloads, which is what reveals hidden flows.