Etch Privacy Policy

v2.5 — Last updated: 2026-07-14

Etch is a spaced-repetition flashcard app for Android. It is built to work entirely on your device. This page explains, in plain language, what that means for your data — and what changes when you opt in to the optional crash-reporting and feedback features.

1. Overview

• Etch is local-first by design. Your cards, decks, and study history live in private storage on your device. Etch has no server or account of its own and never syncs your data to one. (Android's own system backup can copy this data to *your* Google Drive — see §12 for exactly what, and how to turn it off.)
• There are no ads, no third-party advertising SDKs, no Firebase, no analytics SDKs, and no user accounts.
• Etch has two network-touching features: (a) the optional crash / feedback flow that ships data to our error-tracking service (Sentry) — in production builds it is OFF by default and you control it from Settings → Privacy; in beta/testing builds it is ON by default and cannot be turned off in-app, so we can diagnose problems quickly during the test period (see §6); and (b) Google Play Billing, which contacts Google Play to check, complete, and restore the one-time Etch Pro / Supporter in-app purchases (see §7a). Neither transmits your card content, and Google — not Etch — processes any payment.
• Even with telemetry off, the Send feedback form remains available — if you tap it and submit, what you typed (plus the context items listed in §5) is sent. This is explicit user intent, so it bypasses the on/off toggle.

The rest of this document explains, field by field, exactly what is collected, when, and where it goes.

2. What's collected by default

Production builds

Nothing. No crash reports, no usage data, no events. The Sentry SDK is initialised so the toggle in Settings can switch it on if you choose, but until you do, every event the SDK would emit is gated and dropped before it reaches the network.

The only data that ever leaves your device without you opting in is data you explicitly trigger yourself — for example, by tapping Export, picking an Import file, or hitting Submit on the Send feedback screen.

On devices with Google Play there is one platform exception: at launch Etch automatically asks Google Play which of its in-app products you own (and their prices), regardless of the telemetry toggle. That request is handled by Google Play, not by an Etch server, and carries no card or personal content (see §7a and §10). On a device without Google Play the check returns "unavailable" and nothing is sent.

Beta builds

Beta builds are a separate, time-bounded pre-launch APK distributed to testers through the Play Console closed-testing track. In beta telemetry is ON by default and cannot be turned off in-app — the Settings → Privacy toggle that lets production users opt out does not appear in a beta build, so there is nothing in the app to switch off for the beta duration. Testers are told this before they join the closed-test program, and joining is how they consent to it — see §6 for details. Once v1 launches, no beta APK is distributed.

3. What's collected when telemetry is enabled in production

When you turn on Settings → Privacy → Anonymous usage data, the following surfaces become active. Every event passes through a local consent gate (beforeSend) and a path-scrubber that replaces any app-private file path with the literal token <media-path> before the event leaves your device. The same scrubbing applies to breadcrumb messages and to exception text.

3.1 Crashes (uncaught exceptions + ANRs + native crashes)

When Etch crashes, Sentry's SDK captures:

• Stack trace. Includes Etch's own class names and method names. File paths inside the stack frames are scrubbed.
• Exception type and message. Message text is scrubbed of any app-private storage paths and truncated to 500 characters.
• Device fingerprint. Manufacturer (e.g. samsung), model (e.g. Pixel 7), OS version (e.g. Android 14), CPU architecture, total memory, screen size and density bucket, and device locale (e.g. en-US).
• App version. Application ID, version name, version code, and the beta / production environment tag.
• Recent breadcrumbs. Up to the last 100 breadcrumbs from the current session — see §3.3.
• Tags. The full tag inventory from §3.2.
• ANRs (Android's "App Not Responding" signal) are treated the same as crashes.
• Native crashes (crashes in C/C++ libraries) are also captured. They contain native stack frames; no card content can be in them because card content never crosses into native code.

Things that are explicitly disabled in our Sentry configuration and so are never captured: automatic UI-interaction breadcrumbs (which would capture text-field content), automatic screenshots, view-hierarchy snapshots (which would expose the Compose UI tree), performance/tracing data, profiling data, and Session Replay.

3.2 Tags (attached to every event)

Tags are short categorical labels attached to every event we send — crashes, ANRs, recoverable warnings, and feedback. They make the Sentry dashboard filterable without our team needing to dig into event details. Every count is bucketed so a single tag value cannot be used to re-identify a specific user.

Tags refresh whenever the app comes to the foreground, so they reflect your current configuration rather than the configuration you had at install time.

3.3 Breadcrumbs (sent only with an event)

Breadcrumbs are a rolling log of recent in-app events. The SDK keeps up to 100 of them in memory; they are not transmitted on their own. They only ride along when an event (a crash, an ANR, a recoverable warning, or a feedback submission) is also being sent. If telemetry is off, breadcrumbs are gated off at the source too, so the buffer stays clean and a later opt-in won't surface stale pre-consent activity. Flipping the toggle off explicitly clears the buffer.

Every breadcrumb message and data field is also run through the path-scrubber as defence in depth.

3.4 Named events (count against our Sentry quota)

Named events are sent as standalone Sentry events when they fire. Each is gated on the telemetry toggle. Two events are sampled in beta — learn_session_completed at 1-in-5 and search_filtered at 1-in-3 — because their volume would otherwise dominate our quota. Every other named event fires on each real-world occurrence.

3.5 Recoverable warnings (deduped per session)

These are signals that something went silently wrong but the app handled it gracefully — you typically don't see them. They're shipped as Sentry events at WARNING level. The same category is sent at most once per process to avoid quota burn.

The plan that drove this work listed nine recoverable categories, five of which are wired today; a sixth category, overlay_show_failed, was added afterwards and is also wired — so six are emitted from production code paths today. The remaining four planned categories (review_save_retry, migration_warning, overlay_bal_denied, fsrs_unexpected_state) are not currently emitted.

3.6 Session lifecycle

When telemetry is enabled, Etch records Sentry sessions. A "session" here is not a learn session — it's the SDK's term for a continuous foreground interval. Etch opens one when the app comes to the foreground and closes it when the app goes to the background. Sessions give us aggregate metrics like crash-free session rate and anonymous DAU/MAU; we never look at individual sessions.

Each session carries:

Sessions carry no new PII fields beyond the device info / app version already documented in §3.2.

Sessions only run while telemetry is on. Etch does not use the SDK's automatic session tracking. It starts and ends sessions itself and only ever starts one while the telemetry toggle is on — so nothing, not even an anonymous session, is recorded or sent before you opt in. Turning the toggle off immediately ends the open session and stops new ones from starting.

4. What's in a state snapshot (feedback only)

When you submit feedback (via the Settings entry or by shaking your phone), Etch attaches a one-shot snapshot of your current app state to the event as the etch_state context block. This is only sent with feedback submissions, never with automatic crash reports.

The snapshot contains:

Counts — cards_total, decks_total, cards_due_now, cards_suspended. These are exact, not bucketed, because you self-selected for sharing that granularity by hitting Submit. The plan listed a cards_buried field — we omit it because "buried" is a transient queue state with no persistent counterpart in Etch.

Timings — last_review_at_relative and last_session_at_relative (both rendered as "3h ago" / "2d ago" / "never" — coarse, never an absolute timestamp). last_import_at_relative and last_backup_at_relative are currently reported as "unknown" because those flows don't persist their own timestamps yet.

Configuration — triggers_active as a list (e.g. ["unlock", "timer"]), trigger_timer_minutes if a timer is set, trigger_app_packages (comma-separated list of public Play Store package identifiers for any apps configured as triggers, e.g. "com.reddit.frontpage,com.instagram.android" — package names are not PII), and non_default_settings: a map of preference values that differ from their defaults. Only booleans, enums, and bounded numeric settings are eligible; free-text preference values are excluded by design.

Permissions — overlay, notifications, usage_stats, camera, battery_optimization_exempt, each as true/false.

System — free_storage_bucket (<100MB / 100MB-1GB / 1-10GB / >10GB), available_memory_bucket (<100MB / 100-500MB / >500MB).

Recent errors — crashes_last_7d (count over the last 7 days, maintained in a local on-device ledger) and recoverable_warnings_last_24h (count over the last 24 hours).

App — version_name, version_code, is_beta_build, days_since_install, feedback_entry_point (settings / shake_main / shake_overlay).

The snapshot never contains card content, deck names, file paths, search queries, AI prompts, or free-text settings.

5. Feedback submissions

The Send feedback or report a bug flow is accessible from Settings → Privacy and from a shake gesture (which can be disabled in the same section). It bypasses the consent gate: hitting Submit sends data regardless of the telemetry toggle's state, because submitting feedback is itself explicit consent for that one submission.

Before sending, the form shows a confirmation dialog that lists exactly what will be sent. What goes out:

• The free-text description you typed (truncated at 5 000 characters as a safety cap; the form's own char-counter warns you well before that).
• The category you picked (Bug report, Suggestion, Question, or Other).
• The contact email you typed, if you provided one (left blank means no email is attached to the event).
• The screenshot captured by the shake gesture, if one is pending and you left the "Include screenshot" toggle on.
• Any file attachments you explicitly attached (any single attachment over 100 MB is rejected; the total caps at 100 MB).
• The state snapshot described in §4.
• The tags described in §3.2 and the recent breadcrumbs described in §3.3.
• If you are an Etch Supporter and tick "Credit me as a Supporter," a single bounded flag (feedback_supporter_credit_optin=true) is attached so we know you'd like to be credited. It is set only when you tick that box, and carries no other information.

The screenshot toggle is on by default when a shake screenshot exists, but you can turn it off in the form before submitting, and the form shows a thumbnail so you can review what would be sent.

6. Beta builds

During the pre-launch beta phase:

• The Beta APK is identifiable by BuildConfig.IS_BETA_BUILD = true and by the is_beta_build=yes tag on every event. In Sentry it appears under environment=beta.
• Telemetry is ON by default and cannot be turned off in-app. The Settings → Privacy → Anonymous usage data toggle that lets production users opt out does not appear in a beta build — there is no in-app control to reduce reporting for the beta duration. Beta testers consent to this by joining the closed-test program, after being told about it beforehand; that advance disclosure, not an in-app toggle, is the consent basis.
• The data collected from a beta tester is exactly the same as the data collected from a production user who opted in via the Settings toggle (§3). That includes the anonymous session payloads described in §3.6.
• Shake-to-report is on by default; the same toggle that disables shake in production also disables it in beta.
• The learn_session_completed event is sampled 1-in-5 in beta to keep within our Sentry plan.
• Beta ends at v1 launch. No new beta APKs are distributed afterwards.

Beta-to-production transition

If you ran a beta build on a device and then update to the production APK, Etch detects the transition on first launch and resets the telemetry toggle to OFF. A one-time card appears on the Home screen explaining the change. If you want to keep helping, re-enable the toggle in Settings → Privacy.

7. Where the data goes

The data described above is sent to Sentry (https://sentry.io), an error-tracking service operated by Functional Software, Inc. We do not run our own server. Once events reach Sentry, they are stored in Sentry's infrastructure and we access them through Sentry's dashboard.

Sentry's own documentation is the authoritative reference for how they handle the data:

• Sentry Privacy Policy: https://sentry.io/legal/privacy/
• Sentry Data Processing Agreement (DPA): https://sentry.io/legal/dpa/
• Sentry security / compliance overview: https://sentry.io/trust/

Sentry is SOC 2 Type II certified and supports GDPR-style data processing arrangements. We have selected Sentry's hosted offering; we are not configured to use a self-hosted Sentry instance.

In-app purchases are handled by a second, separate recipient — Google Play (Google LLC). See §7a.

7a. In-app purchases

Etch offers optional one-time in-app purchases through Google Play Billing. Today these unlock Etch Pro and Etch Supporter (extra features); the same handling applies to any premium decks or other in-app items Etch offers. Google Play (Google LLC) is the seller / merchant of record and handles the entire payment — Etch never sees or stores your card number, billing address, order ID, or Google account details.

• What leaves your device. When you open the buy page, tap Buy, or tap Restore, Etch asks Google Play — over the network — which of its products you own and the current prices, and, for a purchase, launches Google Play's own checkout. Because entitlement is also re-checked at launch (see §10), Etch contacts Google Play automatically when the app starts on any device that has Google Play, independent of the telemetry toggle.
• What Etch keeps. Only an on-device cache of *which* products you own (e.g. etch_pro), used to unlock Pro / Supporter features offline. Never card content, order IDs, or purchase tokens.
• No Etch server. Entitlement is decided on your device from Google Play's response. Etch runs no server of its own and does no server-side receipt validation.
• Google's handling of the transaction is governed by the Google Play Terms of Service and the Google Privacy Policy.

8. Retention

We defer to Sentry's default retention policy — currently 90 days for events on Sentry's standard plans. If we change the org-level retention setting in the future, we will note it here.

The local on-device ledgers used to compute crashes_last_7d and recoverable_warnings_last_24h keep timestamps for 7 days and 24 hours respectively and never leave the device except as the aggregate counts in a feedback state snapshot.

For in-app purchases, Etch keeps no purchase data on any server of its own — it has none. The only purchase-related data it stores is an on-device cache of which products you own, removed when you uninstall Etch or clear its data. Records of the purchase itself — order history and payment — are held by Google Play under your Google account and governed by Google's retention policies, not Etch's. Refunds are handled through Google Play.

9. Your rights and how to use them

Opt out of telemetry

Settings → Privacy → Anonymous usage data (production builds — see §6 for beta). Toggling this off takes effect immediately: subsequent crashes, ANRs, named events, and recoverable warnings are dropped before they hit the network, and the breadcrumb buffer is cleared so nothing pre-existing rides along on a future feedback submission. In a beta/testing build this control does not appear and telemetry cannot be turned off in-app for the beta duration; the production release, which you get at v1 launch, ships with telemetry off by default.

Disable shake-to-report

Settings → Privacy → Shake to report a bug. With this off, shaking your phone does nothing — no screenshot is captured and the feedback screen does not open.

Request deletion

To request deletion of any data you have submitted (typically via feedback), or to ask what we have for you, email:

feedback@barteknowak.com

Include enough context (approximate date, device model, or any identifier you used in the feedback) so we can find the right event in Sentry. Where possible we will delete by Sentry event ID; where the data overlaps with operational logs we will redact what we can within Sentry's tooling.

Uninstalling

Uninstalling Etch removes all local data — cards, study history, settings, the on-device ledgers, and any pending shake screenshot. It does not delete events that have already been transmitted to Sentry; for those, use the email path above.

10. INTERNET permission

Etch declares the android.permission.INTERNET permission in its manifest. This permission is declared so that the telemetry toggle and feedback flow can work at all — Android requires the declaration up front, even if the app never opens a socket.

When the telemetry toggle is off and you never tap Submit on the feedback form, Etch sends no data to Sentry — with no Sentry events being captured, there is no Sentry network traffic to inspect. This does not cover Google Play Billing: on devices with Google Play, Etch still contacts Google Play at launch (and when you open the buy page or tap Restore) to check which in-app products you own, regardless of the telemetry toggle (see §7a). On a device without Google Play, that check returns "unavailable" and no such call is made.

11. What Etch will NEVER send

This is the hard list. None of the following ever leaves your device through the telemetry or feedback pipelines:

• Card front, back, or hint text.
• Card tags (the user-typed tag strings on a card).
• Deck names.
• Image and audio file contents.
• Image and audio file paths — always scrubbed to <media-path> before any event leaves the device.
• Search queries you type into the in-app search.
• Card editor input (anything you type into front, back, hint, or tag fields).
• AI assistant prompts (the text you ask the AI feature to work on) and the model's responses.
• Custom reminder text or any other free-text settings value.

If you explicitly attach a file in the Send feedback form, that file's contents do leave the device — but only because you picked it from the file picker and confirmed the submission. The form displays a standing warning that picked files may contain personal content.

12. What Etch stores on your device

This part is unchanged from the offline-first design and is included here for completeness. None of these files are transmitted by Etch itself — they live in app-private storage and only leave the device if you use Android's system backup, export them yourself, or attach them to a feedback submission.

• Your flashcards. Text, images, and audio are stored in a local SQLite database (etch.db), an internal images folder (card_images/), and an internal audio folder (card_audio/) in Etch's private app storage, which Android isolates from other apps. Etch does not add its own encryption layer on top; the files rely on Android's own device storage protections.
• Your study history. Every review (card, timestamp, score) is stored locally and used to schedule future reviews.
• Your settings. Including the telemetry and shake-to-report toggles, the post-beta-card dismissal sentinel, the featuresUsed set used by feature_first_use, your last-import-format marker, and a locally-cached list of the in-app products you own (your Pro / Supporter entitlement, so the app knows your tier offline). None of these is sent to an Etch server; the entitlement cache is derived from Google Play (see §7a).
• Your Suppressed-history buckets (the History → Suppressed tab) — stored in a separate on-device log, not sent to an Etch server.
• The recoverable-warnings ledger (24 hours) and the crash-count ledger (7 days), used only to populate the feedback state snapshot.
• A pending-shake screenshot bitmap — in-memory only, cleared when the feedback screen closes or the process dies.

Android system backup. Etch leaves Android's built-in Auto Backup enabled. When it is on (it is on by default on most devices), Android copies etch.db, the card_images/ and card_audio/ folders, and your settings — including the list of any apps you've configured as triggers — to your own Google Drive backup, and restores them when you reinstall Etch on a new device. This is a backup in *your* Google account managed by Android, not a sync to any Etch server (Etch has none). The same data is included in a direct device-to-device transfer. If you would rather none of this leave the device, you can turn off backup in Android Settings → Google → Backup (or Settings → System → Backup, depending on your device). Regenerable caches are excluded.

13. Permissions Etch requests, and why

You can revoke any of these in Android Settings → Apps → Etch → Permissions at any time. Features that depend on a revoked permission will stop working; the rest of the app will continue normally.

14. Information Etch reads but does not collect

These behaviours predate the telemetry integration and are unchanged:

• Foreground app names. If you enable "App triggers" in Settings, Etch reads the name of the app currently in the foreground only to check whether it matches one of the apps you asked it to watch. The names are not stored, not logged in release builds, and not transmitted.
• Installed-app list. When you open the App Triggers picker, Etch asks Android for the list of apps with home-screen icons so you can pick which ones should fire a flashcard. The list is shown to you, never sent anywhere.
• Camera frames. Photos you take through the camera go into the app's private image folder. They are not transmitted unless you attach one to a feedback submission.
• Photo gallery. Images you pick via Android's system photo picker reach Etch only because you selected them. Separately, when you tap Paste to attach a recent screenshot, Etch reads only the single newest image in your gallery to offer it — it is not otherwise accessed, stored, or transmitted unless you keep it on the card.

15. Network activity you trigger explicitly

• Export / Import. Tapping Export opens Android's file-save dialog; Etch has no idea where you save the file. Import is the reverse — you pick the file, Etch reads it.
• Privacy policy / Open-source licenses links. Tapping these in Settings opens your browser to the page you're reading now and to a list of open-source licenses. Your browser handles the request, not Etch.
• Telemetry / feedback (covered in §3 and §5).
• In-app purchases. Tapping Buy or Restore on the Etch Pro / Supporter page contacts Google Play to complete or re-check a purchase (covered in §7a).

16. Children's privacy

Etch is not directed at children under 13. We do not knowingly collect any information from children. The app does not have age-gated content, but it also does not offer a child-friendly mode.

17. Changes to this policy

Future updates increment the version number at the top of this document (e.g. v2.1, v3.0) and update the date. The "Last updated" line is always the most recent change date.

If Etch changes in a way that affects this policy — for example, adding a sync feature, changing data processors, or expanding what's collected — we will publish an updated version of this page and, where the change materially affects what we send, surface an in-app notice.

18. Contact

Questions or concerns? Email: feedback@barteknowak.com

Etch is offline-first by design, with one optional, scoped opt-in for crash reporting and feedback. If anything in this document doesn't match what you observe in the app, that's a bug — please report it to the contact address above.