If you’ve ever downloaded a “simple” app that somehow wanted your location, contacts, photo library, microphone,
and (just for fun) your first pet’s middle namecongrats. You’ve met the modern data-hungry mobile ecosystem.
China’s regulators (and regulator-adjacent watchdogs) have also met it, sighed deeply, and started publishing
lists.
In the latest round of “please stop doing that,” Chinese authorities flagged a batch of 70 mobile apps
for alleged violations tied to the Personal Information Protection Law (PIPL) and urged swift remediation.
The message is blunt: fix your data practices, or you may get benchedsometimes literally delisted from app stores.
What Happened: The “70 Apps” Wake-Up Call
China’s app compliance spot-checks aren’t a one-time event; they’re more like a recurring series with new episodes,
familiar plot twists, and the occasional surprise cameo from an app you didn’t know existed.
In this case, a national-level testing and notification mechanism flagged 70 apps for conduct associated with
illegal or improper collection and use of personal information, and called on operators to remediate within the
stated deadline and expectations.
While public notices don’t always read like a thriller, they do carry consequences. Apps that fail to correct issues
after follow-up testing can face escalationranging from public naming to removal from distribution channels.
In plain English: you don’t want to be the app that gets told, “We asked nicely.”
PIPL in 5 Minutes: The Privacy Law China Actually Uses
China’s PIPL (effective since 2021) is the country’s flagship personal data law. If you’re used to thinking in GDPR
terms, you’ll recognize a lot of the same privacy principles: transparency, purpose limitation, data minimization,
individual rights, and higher standards for sensitive data. The big difference is how these ideas get enforced in
the mobile app world: regulators (and related institutions) often focus on the user experience of privacywhat the
app shows, asks, blocks, and quietly does in the background.
Key PIPL ideas apps get wrong (a lot)
- Clear notice: Users should be told what’s collected, why, and how it’s usedwithout needing a scavenger hunt.
- Valid consent: Consent should be informed, explicit, and tied to a real choice (not “agree or uninstall”).
- Data minimization: Collect what’s necessary for the servicenot what’s “nice to have” for analytics.
- Sensitive personal information: Data like biometrics, precise location, and minors’ data gets stricter handling rules.
- User rights: Users should be able to access, correct, delete, withdraw consent, and close accounts without obstacle courses.
What “PIPL Violations” Usually Look Like Inside Apps
When a notice says “illegal collection and use,” it often points to patterns regulators see repeatedly. Even without
naming every app or every finding, the typical issues fall into a few buckets that are painfully relatable if you’ve
ever tapped “Deny” and watched the app respond with a dramatic fainting spell.
1) Privacy notices that exist… theoretically
A classic: the privacy policy is missing, incomplete, hard to access, or not shown at the moment it matters
(like first launch). Some enforcement summaries focus on apps that fail to pop up a clear reminder to read
collection/use rules, or bury key disclosures behind multiple clicks.
2) Consent that isn’t really consent
Consent becomes questionable when the user isn’t given a meaningful option. Common problem areas include:
collecting personal information before consent, forcing broad permission grants, or designing “agree” flows that
feel less like a choice and more like a toll gate.
3) Over-collection and permission sprawl
Over-collection often shows up as: “We asked for your contacts to help you find friends,” but the feature is
optional, and the app runs fine without it. Or “We need location,” when the app’s core function doesn’t actually
depend on precise location. If your flashlight app wants your microphone, you’re not innovatingyou’re auditioning
for a compliance bulletin.
4) Sensitive data handled casually
Sensitive personal information needs stricter protection and often a higher standard of consent. This can include
precise location, biometrics, financial account details, health information, and data about minors. Notices sometimes
highlight problems like processing sensitive or minors’ information without proper safeguards or without clearly
enabling rights and controls.
5) “You can withdraw consent”… in theory
Another repeat offender: apps that do not provide a practical path to withdraw consent, delete personal information,
or cancel accounts. If closing an account requires emailing a PDF, waiting three business days, and solving a riddle
from a chatbot named “AccountClosureBot3000,” regulators may call that “obstructing user rights.”
6) Weak security basics
Some notices also touch on security shortcomingslike storing data without encryption or failing to protect
personal information appropriately. PIPL doesn’t treat security as a “bonus feature.” If you collect personal data,
you inherit responsibility for protecting it.
Why China Keeps Running App Rectification Campaigns
China’s privacy enforcement around apps is often campaign-like: identify problems, publish notices, set a
rectification window, then re-test and escalate if needed. This approach does two things at once:
it pressures individual apps to fix issues quickly, and it broadcasts expectations to the entire market.
It also reflects a multi-agency ecosystem. While the Cyberspace Administration of China (CAC) is central in the
broader data governance framework, app-focused enforcement activity frequently involves other authorities and
institutions tied to telecom and cybersecurity oversight. For companies, the practical takeaway is simple:
compliance isn’t a single-regulator conversationit’s a whole group chat.
Specific Examples of What “Fix It” Means
“Remediation” sounds abstract until you translate it into product requirements. Here are realistic examples of changes
privacy teams and app developers typically make after a noticewithout needing to rebuild the whole app from scratch.
Example A: First-launch pop-up done right
- Show a short, plain-language summary: what data is collected and why.
- Link to the full policy in the same screen (not hidden in Settings).
- Offer real choices: “Agree,” “Manage settings,” and when possible “Continue with limited features.”
- Log consent decisions and allow users to revisit them.
Example B: Permission requests that match the moment
Instead of requesting every permission at install, apps move to “just-in-time” permission prompts.
If a user taps “Upload photo,” then you ask for photo permissions. If they never use the feature, you never ask.
This reduces both legal risk and user annoyancean underrated compliance win.
Example C: Withdraw consent and delete data without friction
Provide an in-app toggle to withdraw consent for non-essential processing (like personalized ads).
Add an account deletion flow that is (1) findable, (2) completes within a stated timeframe, and (3) doesn’t require
contacting support unless there’s a verified security reason.
Example D: Clean up third-party SDK sprawl
Many apps rely on SDKs for analytics, ads, login, crash reporting, and personalization. Compliance teams often:
- Inventory every SDK and what data it touches.
- Disable SDK calls until the user provides the relevant consent.
- Disclose SDK partners and purposes in the privacy notice.
- Swap risky SDKs for lower-data alternatives.
If You Operate an App in China: A Practical Remediation Checklist
If your app is on a notice listor you want to avoid ever being on onehere’s a field-tested approach that respects
both legal requirements and engineering reality.
1) Map your data like you actually mean it
Build a data inventory: what you collect, when, from where (device sensors, user input, SDKs), where it goes,
and who can access it. If you can’t draw the data flow, you can’t control it.
2) Minimize before you “lawyer up”
Reduce collection first. Data minimization is the fastest risk reducer: fewer data categories, fewer purposes,
fewer retention periods, fewer problems.
3) Fix the UX of privacy
Regulators care about what users experience:
first-launch notice, permission prompts, settings, and account deletion. Make privacy controls easy to find and
easy to understand. “Transparent” isn’t a vibe; it’s a design requirement.
4) Treat sensitive and minors’ data as a separate track
Identify sensitive personal information and apply stricter safeguards:
specific consent where required, tighter access controls, and clearer disclosures. If minors are part of your user base,
make sure age-related protections are real and enforceable, not just decorative text.
5) Verify security basics
Check encryption for data in transit and (where appropriate) at rest, tighten access, reduce logging of personal data,
and ensure incident handling processes exist beyond a shared document named “BreachPlan_FINAL_v7_FINALFINAL.”
6) Document remediation as if someone will ask
Because someone might. Keep records of changes: what you fixed, when you fixed it, and how you verified the fix.
If you’re asked to submit a rectification report, you’ll want evidencenot optimism.
How This Compares to U.S. Privacy Expectations
U.S. privacy law is more fragmented, but the practical compliance pressure is similar: don’t surprise users,
don’t collect more than you need, and don’t make it impossible to opt out or delete.
Regulators in the U.S. often focus on deception (what you promised vs. what you did) and unfairness (harmful practices
users can’t reasonably avoid). State laws add rights like access, deletion, and opt-outs for targeted advertising.
The difference is that China’s app enforcement tends to be more centralized and notice-driven, with public bulletins
and short remediation windows. For global companies, that means the “privacy bar” isn’t just legalit’s operational:
you need processes that can move quickly when scrutiny lands.
What to Watch Next
- More frequent notices: Regular batches of non-compliant apps and SDKs are likely to continue.
- Stronger audit expectations: Compliance audits and documentation may become more standardized.
- SDK governance: Third-party components will remain a major risk area because they can collect data silently.
- Minors and sensitive data: Expect tougher attention to high-risk data categories and user rights.
Conclusion: The Real Lesson Behind the List
The headline number70 appsisn’t just a statistic. It’s a reminder that in China’s mobile ecosystem, privacy compliance
is judged by what an app actually does, what it clearly tells users, and how easily users can say “no.”
If your product is built on trust (and most are, whether they admit it or not), then “remediation” is not a PR exercise.
It’s product work: tighten collection, clarify consent, protect sensitive data, and make user rights usable.
Experiences From the Trenches: What Teams Typically Run Into During PIPL Remediation (Approx. )
When companies go through a PIPL remediation sprintespecially after being flaggedwhat surprises them isn’t the law.
It’s the app. More specifically: how many small, invisible product decisions add up to big compliance exposure.
In post-notice cleanups, teams often discover that the “app” isn’t a single product. It’s a bundle of SDKs, background
calls, A/B experiments, and legacy features nobody fully owns anymore.
A common experience is the “permission pile-up.” Product teams may have added permissions over timelocation for a one-off
promotion, contacts for a referral experiment, storage access for a feature that was later removed. The app still asks
for everything because the code never got cleaned up. During remediation, engineers and privacy reviewers end up asking
a surprisingly powerful question: “What breaks if we delete this?” Very often, the answer is “nothing,” which is both
relieving and mildly embarrassing.
Another frequent lesson is that privacy compliance lives in UI details. Teams might have a privacy policy in Settings,
but the notice expects users to be prompted appropriatelyoften at first launchand to be shown key rules in a way that
people can actually read. The remediation work becomes part legal, part design: rewriting disclosures in plain language,
adding “Manage settings” options, and making sure “Decline” doesn’t trigger a tantrum screen. When teams do it well,
something funny happens: users complain less. Compliance improvements can feel like UX upgrades because, honestly, they are.
SDK governance is usually where remediation projects get real. Teams often find that analytics or ad SDKs collect device
identifiers or behavioral signals before consent is captured. Fixing this isn’t just toggling a setting; it can require
reorganizing the app’s initialization sequence so SDKs load only after the correct consent choice is recorded. Many teams
also learn to negotiate harder with vendors: “What exactly do you collect, and can we limit it?” If the vendor can’t answer
clearly, the vendor becomes the problem.
Finally, account deletion and consent withdrawal flows tend to be the make-or-break moment. Companies sometimes assume
“support can handle it,” but remediation pushes those rights into the product itself: one or two taps, clear confirmation,
and an outcome users can verify. Teams that get this right often come away with a lasting habit: privacy features are not
emergency patchesthey’re part of the core roadmap. The fastest way to avoid being on the next list is to build controls
that stay correct even when the app keeps evolving.