One npm install can put three telemetry SDKs behind your Data Safety declaration

An M6 finding does not start with an exploit. The dev.to walkthrough of the item says the usual sources of personal data are already well protected: the app sandbox, network communication with the server, the app's logs and backups, with URL query parameters and clipboard content less protected but still hard to reach ^[13]. Getting at that data, by the same account, means breaching security at another level first ^[13]. The severe business rating sits on the platform declarations. Apple's Privacy Manifest requirement and Google Play's Data Safety form both have to match what the app actually does, the post says ^[8].

React Native's dependency depth lands straight on that requirement. One `npm install` can pull in three native SDKs, each sending its own telemetry ^[6]. Filling in the form then means enumerating the outbound calls of code nobody on the team wrote. For that risk to transfer to a specific app, two things have to hold: the bundled SDKs are sending telemetry at their default configuration, and the declaration was written from the app's own source. The walkthrough asserts the pattern without measuring how often it does.

The JavaScript side adds a second path. The post names the `console.log` habit, crash reporting integrations and dev tooling as the reasons PII leaks easily there ^[7]. It then lists what an app holds when it "doesn't collect PII": the IP address in server logs on every request, device identifiers including IDFA, Android ID and install ID, usage logs, crash metadata, timestamps, language and locale, and network carrier ^[9]. Seven categories, before anyone writes a line of collection code ^[16]. Combined, the post argues, they are usually enough to identify one person, which by definition makes them PII ^[10], and it counts crash report metadata among the PII that applies to most apps ^[18].

The mapping is the part I would take into a review. The post writes M6 as the other items multiplied by personal data: M5 and M9 for insecure storage and communication, M3 and M1 for access with broken authentication and authorization, M2, M4 and M8 for insider attacks on the sandbox ^[11]. That is seven of the nine other items ^[15]. M6 adds no control of its own; it re-scores the ones a team already has with personal data in scope. Its one original question, in the post's words, is "Why are you collecting this data at all?", and it says that if the answer is "because we might need it," the violation already exists ^[4]. M5 tells you to encrypt the data, M9 to store it securely ^[12].

The fine exposure is where the record is thin. Code can work perfectly, nothing crashes, no system goes down, and a company can still face millions in fines, the post says ^[14]. It does not name a regulation, an enforcement case, or an amount ^[21]. The seven-field list is checkable in a way the rating is not: each item either appears in a release build's outbound traffic or it does not. I would run that capture before signing the next Data Safety form.