What Data News Apps Collect About You

What data news apps collect is knowable from two published documents: the Google Play Data safety section and the privacy policy. Google's Data safety documentation defines collection as anything transmitted off the device, third-party SDKs included, and Android's developer documentation notes that since a late-2021 Google Play services update the advertising ID returns zeros once you opt out.

Key takeaways

• Two documents answer the question before you install: the Play Data safety card is a declaration about the current build, the privacy policy a permission for future ones; believe whichever admits more.
• Google's Data safety documentation counts data sent off the device by third-party libraries as collected by the app, and says the developer alone is responsible for the declaration.
• Six data groups cover a news app in practice — identity, device and network, reading, permissions, money, diagnostics — and none of them is required to show a headline.
• Since a late-2021 Google Play services update, an app that reads the advertising ID after you opt out of ads personalization receives a string of zeros (Android developer documentation).
• GetMyNews holds no identity at all; its Play card declares app activity and the advertising identifier, both shared with Google for advertising, because a banner and a full-screen ad about every 20 stories pay for it.

Between the two you can reconstruct the inventory without trusting a single line of marketing copy. Apps are shy about inventories and fluent about atmosphere. "We care about your privacy" is atmosphere. "We collect product interaction data and device identifiers and share them with advertising partners" is an inventory. This piece is about reading the second kind of sentence — not about paywalls, offline reading, or how a feed is ranked.

What can a news app know, and what must it know?

Capacity, practice and necessity are three different quantities, and the gap between the last two is the entire subject.

What it can know is everything the operating system will hand over, everything you type, and everything you do inside the app: address, location, advertising identifier, reading history, device model.

What it usually knows is shorter and still serious: an identity of some kind, a stream of taps, a device fingerprint, and whatever the ad network requires.

What it must know to show you a headline is close to nothing. A public feed is a text file on a newsroom's server, and a phone can request that file without saying who is holding it. If a data type is not required for fetching a feed, opening a page, or keeping a save list on the handset, it is there for the company rather than for you.

Which data types belong on the checklist?

Six groups cover what data news apps collect in practice. Work through them against any app, using the store card and the policy side by side.

Group	Typical entries	Needed to show a headline
Identity	Email, name, phone, social login	No
Device and network	Advertising ID, model, OS version, IP	No
Reading	Opens, skips, saves, dwell time, searches	Only on the device
Permissions	Location, contacts, photos, microphone	No
Money	Purchases, subscription status	Only if you pay
Diagnostics	Crash reports, "analytics"	Debatable, and often a cover

Two entries deserve a note. The advertising identifier exists specifically for cross-app advertising, and Google's guidance on user data identifiers describes it as a user-resettable identifier appropriate for ads use cases — one that, since a Google Play services update in late 2021, returns "a string of zeros" to any app that requests it after you opt out. And "analytics" is frequently the heading under which reading history travels, which is why the word deserves a search of the policy rather than a nod.

The reading row is the interesting one. The same events that constitute a dossier on a server are, on a handset, exactly the input a local ranking model needs. The data type is identical. What differs is whether a company receives a copy — the distinction worked through in why a reader does not need an account.

What does the Play Data safety section actually declare?

It declares, per data type, whether the developer collects it, whether it is shared with third parties, whether it is optional, and what it is used for. Google's documentation for the form defines collection as data transmitted off the device — including by third-party libraries — and sharing as transfer to another company, and it puts the burden squarely on the publisher: "You alone are responsible for making complete and accurate declarations in your app's store listing on Google Play." Where Google finds a discrepancy, it says it "may take appropriate action, including enforcement action".

That makes the card the most useful document in the pair. It is short, it is structured, and it is enforceable as a representation to consumers. It is also the one place where an ad-funded app cannot describe itself as collecting nothing, because the ad SDK's own collection has to be declared by the app that embeds it. For a free reader, the card is usually the shortest honest statement of what data news apps collect on its behalf.

How does the store listing differ from the privacy policy?

The listing is a declaration about the current build; the policy is a permission for future ones. They fail in different directions, and reading them together is what makes the exercise work.

The card is a snapshot: these types, this sharing, these purposes. The policy is written by lawyers to preserve room — "we may collect", "including but not limited to", "service providers who assist us" — so it will not tell you what the app did this morning. It will tell you what the company has reserved the right to do, and the Federal Trade Commission treats that document as binding: its guidance to businesses is to "reread your privacy policy to make sure you're honoring the promises you've pledged".

The overlap is the usable truth. If both mention email, the app collects email. If the policy mentions reading history and the card does not, treat the history as collected. Believe the document that admits more, every time.

What does GetMyNews hold?

The same checklist, answered against our own build rather than in the abstract.

Identity. None. No account, no email field, no password, no social login. There is no GetMyNews server that could store one: the phone fetches 92 public RSS feeds from 37 US newsrooms directly, so newsrooms see an ordinary request and we are not in the path.

Reading. Opens, skips and saves stay on the handset as a weights file in the app's own storage. "My news" and "To read" are local lists. Uninstalling removes all of it, and so does "Erase everything and start over" in Settings.

Permissions. The app requests two: internet access, and the Android advertising ID permission that AdMob requires. Overlay, external storage and vibration permissions are explicitly blocked in the build and verified absent from the merged manifest. Location, contacts, photos and the microphone are never requested.

Money and ads. Free, funded by a banner plus one full-screen ad about every 20 stories through Google AdMob. That is why the Play card is not blank and should not be: it declares app activity (interactions) and device or other IDs (the advertising identifier) as both collected and shared with Google for advertising. Both rows are optional, Google's consent form is shown before the first full-screen ad rather than at launch, and declining gives non-personalized ads without gating a single feature. There is no account to delete, and the erasure routes — Settings, uninstall, and resetting the advertising ID in Android — are set out at your data.

GetMyNews is Android-only, on Google Play, and the Data safety card is the check on every sentence above. If the card and this page ever diverge, believe the card.

How do you test the claims in three minutes?

Four tests, none of them technical, and they work on any reader.

1. The absence test. Watch the onboarding. No address, no friends list, no permission sheet for things a headline does not need. Collection-heavy apps are noisy at the door.
2. The deletion test. Ask what you would have to write to anyone to finish the job after uninstalling. "Nothing" means the data was local. A form means you already know what was held.
3. The money test. Find the sentence that explains how a free app is paid for. If you cannot find it, assume the payment is you.
4. The airplane-mode test. Turn the network off after a fetch. Your settings and saved list should still be there; new stories should not. That split is what a locally-stored reader looks like with the network pulled out from under it.

Run all four and you will know what data news apps collect from you in practice, rather than in principle. If you already signed up somewhere, the checklist still earns its keep: it tells you exactly what to name in a deletion request — reading history, device identifiers and partner copies, not merely "my account" — and the wider cleanup is in what to switch off on Android. Then pick a reader that does not require you to do this again, using the one-minute account check.

FAQ

Which document wins when the store label and the policy disagree?

Neither wins outright; believe whichever admits more. The Play card is enforceable as a declaration to Google and is specific about collection, sharing and purpose. The privacy policy is broader by design and reserves rights the current build may not use. If the card lists a data type the policy omits, the type is collected. If the policy describes a server-side profile the card does not, assume the profile exists.

Does airplane mode prove where a news app stores your data?

It proves where your settings and saved list are stored, which is most of what people want to know. With the network off after a fetch, locally-stored preferences survive and a spinner over your own settings means a round-trip was required. It does not prove the absence of uploads while online, because an app can hold data locally and copy it to a server as well.