How to Read an App Privacy Policy in Ten Minutes
A privacy policy is not written to be read. It is written to be defensible. That is why it opens with a paragraph about how much your privacy matters and closes with an address in a city you will never visit, and why the two sentences that actually decide what happens to your journal are buried on the fourth screen between a definition of cookies and a note about children under thirteen.
You do not have to read all of it. Almost every consequence in a journaling app's policy is carried by six clauses. Find those six, read them slowly, and you can skim the rest without losing anything.
Open the policy in a browser rather than the in-app viewer, so you have a working find function. Then run the searches below in order.
1. Third-party sharing
Search for: share, third part, service provider, affiliate, partner, processor
Every policy shares something with someone. Hosting, crash reporting, and payment processing are real needs and no honest app pretends otherwise. What you are reading for is the boundary of the sharing.
The good version names categories and ties each one to a purpose: a hosting provider to store data, a payment processor to handle billing, and nothing else. The bad version is a list of purposes with no ceiling — "with partners to improve and personalize our services" — because personalize is a word that expands quietly.
Two specific things to look for. First, whether affiliate is defined. If affiliates means any company under common ownership, and ownership can change, the sharing boundary can move without the policy changing a word. Second, whether the sharing is described as covering "your content" or only "usage data." A policy that carefully limits its analytics sharing and stays silent about your entries has not limited anything.
2. Sale
Search for: sell, sale, rent, monetary or other valuable consideration
This is the one clause worth reading twice. Under several US state privacy laws, "sale" has a broader legal meaning than money changing hands for a spreadsheet of names; it can include disclosures made for other valuable consideration, which is why so many policies now include a sentence like "we do not sell your personal information as defined by applicable law." That qualifier is doing work. It may be perfectly honest, or it may mean the company does something it believes falls outside the statutory definition.
What you want is a flat sentence with no definitional escape hatch: we do not sell your data, and we do not share it for advertising. Anything hedged deserves a follow-up email before you trust it with a decade of your interior life.
3. Retention and deletion
Search for: retain, retention, delete, deletion, as long as necessary, backup
Three separate questions hide here, and policies often answer only the first.
- How long is data kept while you use the app? "As long as necessary to provide the service" is standard and fine on its own.
- What happens when you delete an entry? Immediately, or on a schedule, or never in a real sense?
- What happens when you delete your account? Look for a stated window — thirty days, ninety days — and for how backups are handled. Backups legitimately lag behind deletions; a policy that acknowledges the lag and bounds it is being more honest than one that promises instant erasure everywhere.
Read the deletion clause alongside a separate question the policy usually will not answer: can you get your archive out, in a format that opens without this company? Export and deletion are the two ends of the same freedom. An app that makes leaving easy has less need for you to trust its retention language at all.
4. Advertising and analytics
Search for: advertis, interest-based, personalized ads, analytics, SDK, identifier
The sentence to hunt for is not "we show ads." It is whether the app embeds third-party advertising or analytics SDKs, because an SDK is code from another company running inside the app, and the policy is describing a data flow that the developer does not fully control.
Note the difference between aggregate product analytics — how many people opened the app this week — and event-level analytics tied to a device identifier. The first tells a developer whether a feature works. The second builds a profile. Policies rarely distinguish them, so check any vendor names listed and what those vendors sell.
If the app is free and sells nothing, this section is usually where the business model reveals itself.
5. Staff access
Search for: employee, personnel, access, authorized, support, encrypt
Ask a narrow question: under what circumstances can a human being at this company read what I wrote?
There are three broad answers. Some policies say staff may access content for support, moderation, or debugging, sometimes with an approval process. Some say nothing, which is not reassurance — silence is permission. And some say the company is technically unable to read entries because content is encrypted with a key the company does not hold.
That third claim is the strongest, and it is also the one worth checking against the rest of the document. Real end-to-end encryption has visible consequences elsewhere: a password or key that cannot be reset for you, a warning that losing it means losing the archive, a support process that cannot recover content. If a policy claims content is unreadable to the company but the app also offers to email you a password reset that restores everything, the two statements are in tension and the tension is the finding.
Yesterself is the journal that writes back. Every morning it sends you a letter from your own past writing, and your reply becomes tomorrow's. End-to-end encrypted, no account, no email — your archive is yours to export, free, forever.
Join the waiting list6. Jurisdiction and transfers
Search for: governing law, jurisdiction, transfer, stored in, standard contractual clauses, law enforcement, legal process
Two things live here. The first is where disputes are settled and under which country's law, which matters less for most people than it sounds but tells you where the company actually is. The second is more practical: where the servers are, whether data crosses borders, and what happens when a government asks.
Look for a law enforcement paragraph. The honest ones say plainly that the company will respond to valid legal process and describe what it can produce. Notice the phrase what it can produce — a company holding ciphertext it cannot decrypt has a genuinely different answer than a company holding plain text, and the difference shows up in this paragraph more clearly than in the marketing.
None of this is legal advice, and a privacy policy is a contract; if a specific clause matters to you for a legal or professional reason, ask a lawyer rather than a blog.
What to do with what you find
Write the six answers down in one line each. Then read them together, because the failure mode of policy reading is evaluating clauses one at a time and missing the contradiction between them. An app that shares broadly, retains indefinitely, and grants staff access is at least coherent. An app that promises encryption in clause five and unlimited partner sharing of "your content" in clause one is telling you something about how carefully it was written.
Two closing notes. A policy can change; look for the last-updated date and the clause describing how you will be told about changes. And a policy describes intent and permission, not capability — it is a promise about what a company will do, and technical design is what determines what it can do. When the two agree, you have something. When only the promise exists, you are relying entirely on the company's continued good behavior and continued ownership.
We built Yesterself so that most of these questions have short answers. It is a journaling app in which each morning brings you one letter from your own past writing, and your evening reply becomes tomorrow's mail. Entries are end-to-end encrypted; there is no account, no email address, and no password, because your identity is twelve words that stay with you. The server holds ciphertext it cannot read, nothing is used to train anything, and export is free forever on every tier. Yesterself is not released yet — the waiting list on the site is the only thing to join today.
If you want more on the technical claims behind clause five, we wrote about what zero-knowledge encryption actually means and about whether app employees can read your entries.
Common questions
Do I have to read the whole policy?
No. Six clauses carry almost all the consequence. Search for them by phrase, read those paragraphs closely, and skim the rest.
What is the fastest single check?
Search the document for the word sell. If selling is permitted or defined vaguely, nothing else in the policy will make up for it.
Does a short policy mean a safer app?
Not by itself. A short policy can be short because it says little. Judge it by whether it answers the six questions plainly, not by length.
What if the policy contradicts the app store listing?
Treat the policy as the binding document and the listing as marketing, then ask the developer in writing which one governs. A refusal to answer is itself an answer.
Should I read the terms of service too?
If you have time, skim it for the account termination and data deletion sections, since those decide what happens to your archive if the relationship ends.