A monthly privacy check: audit period-app traffic, not promises

A privacy label is a starting point, not an audit result. For people who rely on period and women’s health trackers, the practical question is narrower: what network traffic does the app generate during defined actions, and can those actions work with the device offline?

No verified release or pricing change is established in the facts available for this month’s digest. The useful category signal is the gap between a product’s stated architecture and evidence a practitioner can reproduce. PinkyBloom describes itself as a free tracker with no account and says processing happens on-device and the app works offline. Those are product claims, not findings from an independent traffic test. This method can help readers assess claims without treating a single capture as a security certification.

Set up a controlled test

Use a spare or reset device if possible. Record the operating system version, app version, install source, date and time, and network setup. Avoid entering real health information. Use a test profile with a few sample logs, or limit the test to opening the app and navigating through ordinary screens.

Capture traffic at a point that can identify the test device, such as a dedicated access point or a router’s device-level logs. A capture can show connection attempts, destinations, timing and data volume. With ordinary encrypted connections, it generally cannot show the contents of the transmitted data. Do not describe an encrypted connection to a server as proof that cycle information was sent; the capture alone does not establish that.

Start with a baseline. Leave the device idle on the network for a fixed period before opening the app. Note any traffic. Then open the app and perform one action at a time: view existing entries, add a sample log, close the app, and reopen it. Mark each action’s time. Repeat each test so that a stray operating-system connection is less likely to be mistaken for app activity.

Test offline behavior separately

Enable airplane mode, then check that Wi-Fi and cellular data are actually off. Some devices allow Wi-Fi to be switched back on while airplane mode remains enabled. Open the app and repeat the same actions. Record what works, what fails and whether the app displays an error. This establishes whether those particular tasks work without a network connection. It does not show what the app does when connectivity returns.

Run a second test with normal connectivity restored. Capture the period before opening the app, the same sequence of actions, and a short period after closing it. That distinction matters: an offline test cannot reveal possible transfers that occur later, after reconnection. A health app network test should include both the offline window and the connected window.

Interpret a zero-data-transfer check carefully

A zero-packet result is meaningful only when the scope is clear. State whether the capture covers all traffic from the device or traffic attributed to the app, how long it ran, which features were used, and whether the device had other apps running. A device-level capture can include operating-system services and unrelated background activity. An app-level network monitor may help with attribution, but its coverage depends on the operating system and test method.

Likewise, a capture showing no traffic during one short session does not establish that an app never communicates. Repeat the test after a cold start, after a longer idle period, and after a network interruption. If the app supports optional sharing or other connected functions, test those separately and do not mix them with a basic local-use test.

Some auditors use an HTTPS inspection proxy to examine decrypted requests. That may require installing a trusted certificate, and an app may reject the proxy or use protections that prevent inspection. A failed interception is not evidence of zero traffic. Report what the method could and could not see; do not treat packet counts, destination names or encrypted payloads as interchangeable evidence.

Write up the result, not a verdict

A useful note includes the device and app versions, test dates, network conditions, exact actions, capture scope and observed endpoints or packet counts. Separate direct observations from interpretation. For example: “No device-attributed packets were observed during these five minutes of offline logging” is bounded. “The app never sends data” is not supported by that test.

Network inspection also has limits. It does not establish how data is stored on the device, whether device backups include it, or what happens during a different feature flow. Practitioners building a private tracking setup may also want to keep records separated when tools do not explicitly support transferring them; the case for maintaining two separate records covers that boundary.

For builders, the lesson is straightforward: make privacy claims testable, document the scope, and repeat the test when app behavior changes. For users, an audit is strongest when it names the limits. Offline use, a quiet capture and a product’s privacy statement are related evidence, but none alone proves the whole privacy story.