I Read The Privacy Policy So You Don't Have To — It's Worse Than You Think

I read through a company’s privacy policy expecting the usual legal language, but I found terms that seem far more invasive than I expected, including broad data collection and unclear sharing practices. I need help figuring out what these clauses really mean, whether my concerns are valid, and what steps I should take to protect my personal information. This post covers privacy policy red flags, data collection concerns, and user privacy risks.

If the policy says they collect browsing behavior, location, device IDs, contacts, purchases, and ‘partners’ data,’ take it at face value. Companies write these docs to protect themselves, not you.

What to do next.

  1. Pull the exact lines.
    Quote the parts on collection, sharing, retention, and ad partners. Short excerpts work best.

  2. Compare old vs new policy.
    Use the Wayback Machine or changelog tools. If the wording got broader, note it.

  3. Check your rights.
    If you live in California, look at CCPA rights. If you live in the EU, look at GDPR access, deletion, and objection rights.

  4. Test the settings.
    See if opt-out links work. Many are weak or burried.

  5. Limit exposure.
    Turn off ad ID, revoke app permissions, delete old data, use email aliases, and remove phone access.

  6. Name the red flags.
    ‘Affiliates,’ ‘service providers,’ ‘business partners,’ and ‘improve services’ often hide broad sharing.

  7. File requests.
    Ask for data access and deletion. Save screenshots and dates.

If you post the exact clauses, people here can tear them apart line by line.

Honestly, I’d add one thing to what @stellacadente said: don’t assume “creepy” automatically means illegal. A lot of privacy policies are written absurdly broad on purpose so they can vacuum up data later without rewriting the doc. That’s bad, but it also means the policy may describe their maximum permission set, not always their day to day behavior.

So I’d split this into 2 buckets:

  1. What they say they can do
  2. What the product actually does

That second part matters. Check network traffic if you can, or at least app permissions, cookie banners, SDK disclosures, app store privacy labels, and browser requests. Sometimes the app is worse than the policy. Sometimes the policy is worse than the app. Either way, that gap is the story.

Also, watch for “sell, share, disclose, transfer” being treated as differnet things. Companies love hiding behind definitions. “We do not sell personal data” can still mean “we share it for targeted ads.”

If you’re planning to post about it publicly, be careful with wording. Say “the policy states” and “appears to allow,” not “they are illegally spying on everyone” unless you can prove it. Keeps the focus on the receipts and avoids them wriggling out on technicalites.

One place I slightly differ from @stellacadente: sometimes the policy itself is the product story, even if the app is not currently doing every creepy thing listed. If they’ve reserved the right to combine precise location, browsing behavior, purchase history, device IDs, and “trusted partners” data, that tells you how they think about users.

What I’d focus on next is structure:

  • Data collected
  • Data inferred
  • Data bought from others
  • Who gets it
  • How long they keep it
  • Whether deletion is real or full of carve-outs

Big red flags:

  • “May collect” everywhere
  • “Affiliates, partners, service providers” with no list
  • Retention tied to “business needs”
  • Policy changes without direct notice
  • Arbitration or class action waiver buried nearby

Pros of the policy review approach:

  • It gives receipts
  • It shows future risk, not just current behavior

Cons:

  • Policies are often intentionally overbroad
  • Readers can confuse permission with proof of active abuse

If you post this, quote exact lines and translate them into plain English side by side. That usually lands harder than outrage.