Our Privacy Policy Explained in Plain English (2026)

A privacy policy is a promise, but a promise becomes useful only when you can understand what it covers. This guide explains the intended behavior of the apps described as local or offline-first. It is not a substitute for the current privacy policy, store disclosure, terms, or permission list for a specific app and version. Read those documents in the order they appear at purchase time, especially if an update adds a network feature, backup, or support attachment.

The central promise is narrower than “nothing exists.” A tarot shuffle, rune draw, or local journal entry can be processed on the device, but the operating system may still provide crash diagnostics, the store may record a purchase, and a user can export or send a file elsewhere. “No data collection” should be scoped to the developer’s servers, the current version, and the feature being used. A responsible privacy explanation says what is local, what may pass through a platform, what the user creates, and how to delete or export it.

The Short Version

• Local processing: core tools are designed to calculate, draw, calculate phases, or store a user-created entry on the device.
• No developer account for core use: a local task should not require a profile merely to unlock a calculator or journal.
• No advertising sale: if an app has no ads, it should not be described as a source of advertising data.
• No analytics by the developer: a current version should state whether it includes usage analytics, crash reporting, or diagnostic services.
• User-controlled exports: a file you export can leave the device, so the app should explain where you save it and what you share.

These are product claims to verify, not universal facts about every app or store service. “Offline” can mean that a feature works without a network, not that the operating system or payment provider has never recorded a transaction. “No account” can mean that the developer does not require one, while a store purchase still belongs to the platform account used to buy it. A clear policy names these boundaries.

What the App May Handle

A local reading tool may create data on the device: a saved journal entry, a sigil image, a rune layout, a dream timestamp, a moon-phase note, or a calculation result. The user decides whether to keep, export, share, or delete that file. A privacy-aware app should say where the file is stored, whether it is encrypted at rest, what an export includes, and what happens when the app is uninstalled. It should not silently upload a private journal to make a backup convenient.

Some functions may require an operating-system permission. A camera feature may request camera access, a recorder may request microphone access, and a notification or export feature may request storage access. A permission is not itself proof of collection, but it is a reason to read the explanation. The app should request access when the related feature is used, explain the purpose, and provide a way to deny it if the core tool still works. If the product does not have a meaningful reason for a permission, do not infer one from the feature name.

What the Policy Should Clarify

• No advertising identifiers in a version that genuinely has no ads or ad SDKs.
• No developer sale or sharing of personal journal content.
• No mandatory email marketing list for a one-time purchase, unless the current terms clearly say otherwise.
• No hidden telemetry added without an updated disclosure and permission context.
• No third-party analytics, crash, or advertising service hidden behind the word “offline.”
• No claim that a local tool can prevent the operating system, store, payment provider, or a user export from handling data.

A “we never do this” list should be dateable. If a future release changes the architecture, the policy and release notes should say so. Users should not have to infer a new data flow from a silent update. A trustworthy policy explains what changed, why, whether old data is affected, and how to opt out or delete it.

Store, Purchases, and Support

Buying an app through Google Play or another store usually creates a transaction record in the platform’s system. That is a store or payment event, not automatically developer collection. The developer may receive a receipt, order identifier, or account information needed to deliver support, but should not receive more than the current policy and app operation require. Do not send a full card number through an ordinary support email. Keep the platform receipt separate from private app content.

Support can also create data. If a user sends a screenshot, crash log, order reference, or email, the support team may temporarily process that information to answer the request. The page should explain how long a message is retained, whether attachments are deleted after resolution, and where a security issue should go. Redact a password, full payment number, private journal, or another person’s information before sending an attachment.

How to Verify a Privacy Claim

1. Read the current listing: compare the Data Safety section, privacy policy, app permissions, and release notes for the same version.
2. Test the core task: use airplane mode for a calculator, journal, or local reference; note which functions still work and which intentionally require a network.
3. Inspect permissions: ask whether each permission is needed for a feature you use. Deny optional permissions and test the core task.
4. Use safe network tools: a firewall or router log can help spot unexpected connections, but it cannot prove that no data was ever collected or that a server received no metadata.
5. Make a test export: save one file outside the app, open it, and delete it when finished. This reveals what the export includes.
6. Check updates: privacy behavior can change with a new version. Repeat the test after major updates and record the date.

Airplane mode is useful but not conclusive. An app may use cached content, a queued update, or a preloaded file; a router may not show every local or encrypted exchange. Use several observations and read the disclosure rather than treating one test as a universal certification.

Data Rights and Deletion

What rights can a user exercise depends on where the data is stored and which law applies. If a developer has no server-side account, the user may need to delete a local journal, remove an export, clear app storage, or uninstall the app. If a server or store holds an account record, ask how to request access, correction, export, or deletion. A privacy policy should provide a contact route and distinguish developer data from platform data.

Deleting a local app does not necessarily delete a cloud backup, a screenshot sent to support, an email retained by a provider, or a file copied to another service. Be explicit about these limitations. Avoid claiming that a one-time purchase has no data footprint when a receipt, device file, or store account record exists. The point is to give the user control over the parts they can control and a clear route for the rest.

Accessibility and Privacy

A privacy promise should not require a user to surrender accessibility. Screen-reader labels, text resizing, and clear focus order should be available without sending a private journal to a remote service. If a support page asks for a screenshot, offer a text description and a way to reproduce the problem without uploading intimate content. Accessibility and data minimization reinforce each other: a useful product should not collect more than needed to make a core task work.

Also check whether a privacy control is understandable. A hidden toggle, a consent banner that blocks the calculator, or a dark pattern that makes deletion harder is not a meaningful choice. The user should be able to find the permission, export, delete, and support routes in plain language.

Privacy by Architecture, Carefully Stated

Offline-first architecture can reduce server exposure because a local calculation does not need to transmit a user’s reading. It does not make a product automatically private, private from the operating system, or immune to future changes. The architecture must be checked against the actual version, permissions, libraries, and network behavior. The best policy says “we designed this core feature to work locally” and then gives the reader a way to test that design.

Astral Lab and other apps should be described using the terms in their current listing: offline feature, optional online feature, local storage, and support route. A local app can be a good privacy choice for a particular task without claiming that the entire product ecosystem or every platform service is outside its scope. Precision is more trustworthy than an absolute adjective.

A Privacy Policy Readers Can Use

A good policy is not the one that promises the least detail; it is the one that lets a reader make a decision. Identify the app and version, name the data categories, explain permissions, distinguish local processing from store and support activity, and give a deletion route. Then update the evidence when the software changes. Privacy is a relationship between architecture, disclosure, and user behavior—not a decorative sentence at the bottom of a page.

FAQ

Frequently Asked Questions

How can an app work with no data at all?

A local calculator or journal may create files on the device without sending them to a developer server. That does not mean no receipt, store record, or exported file exists. Ask what the current version stores locally, what the platform handles, and what happens when you export or uninstall.

What about app updates and purchases?

The store usually handles payment and delivery, while the developer may receive a receipt or support identifier. A purchase record is not automatically developer analytics, but the current privacy policy should define what is visible. A major update can add a network feature, so check the release notes and Data Safety section again.

Could the policy change later?

Yes, software and policy can change. A responsible change should be described in release notes, privacy terms, and the app listing, with a clear date and explanation of old data. Do not treat “offline-first” as a permanent technical guarantee; verify the current version.

Does airplane mode prove an app is offline?

No. It is a useful test for the core task, but cached content, queued updates, operating-system services, or local networks can complicate the result. Record the version, test the feature, and read the store disclosure instead of treating one observation as certification.

What if I export a journal or sigil?

An export is a file you control and may leave the device. The app should explain the file format and destination, but you decide whether to share it. Delete the original and exported copies when you no longer need them.

Can support see my private journal?

Support should not need an entire private journal to answer a routine question. Send a redacted example, crash message, or order reference when possible. A support request may create a temporary record, so ask what is retained and how the attachment is deleted.

Is “no data collection” a guarantee of anonymity?

No. The phrase can refer to developer collection while the operating system, store, payment provider, or user action still creates a record. Read the scope and date of the statement. Privacy is stronger when the architecture, policy, permissions, and user controls all point in the same direction.

References

• Google Play Data Safety form requirements and developer disclosures.
• Google Play Console Help. Data safety, permissions, and app testing guidance.
• GDPR Article 5: principles relating to processing of personal data, including purpose limitation and data minimization.
• OWASP Mobile Application Security Verification Standard, Privacy requirements.
• Federal Trade Commission. Mobile app privacy and data security guidance for businesses.
• National Institute of Standards and Technology. Privacy Framework and Cybersecurity Framework 2.0.
• World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2.
• Apple App Store Review Guidelines. Privacy, data collection, and user-control expectations.

EN ES FR DE IT PT RU JP ZH