Privacy Policy

The short version

You can use the practice questions without an account. If you make an account, the only thing we ask you for is an email address - there is no password, no phone number, no date of birth, and no payment information. Everything else we hold today is a record of your own study: what you answered, when, and how the app scheduled your next review. We do not sell it, we do not share it with advertisers, and we run no advertising or cross-site trackers. You can download your account data and delete your account and study record from inside the app. The sections below name the narrow security, measurement, logging, and future payment records that are handled differently.

What we collect

If you use the app signed out

The guest practice round runs in your browser. Your answers are held on your own device and are not attached to any identity on our servers. If you later sign in, the app asks whether you want to keep that practice or discard it - if you discard it, it is deleted from your device and never reaches an account.

If you create an account

Your account record holds:

• Your email address, plus a SHA-256 hash of it used to look you up at sign-in without scanning the plaintext column.
• Your time zone, so daily streaks roll over on your local calendar day.
• Your career targets, if you set them: branch of service, job code, target test date, and target AFQT score.
• Your reminder-email preference, and when you last changed it.
• Your lifetime XP, streak-freeze balance, and the dates any freeze was used.
• The dates your account was created and last updated, and when it first completed a streak-qualifying session.
• When the account's primary email address was first verified.

Your study record

Everything the learning engine needs in order to work is stored against your account:

• Each practice attempt or test - its mode, when it started and finished, and any estimated score it produced.
• Each individual answer - which question, which option you selected, whether it was correct, how many milliseconds you spent on it, and when you answered.
• Spaced-repetition state for each question you have seen: its stability and difficulty parameters, when it is next due, and how many times you have reviewed or lapsed on it.
• Mastery state for each skill: crown level, accuracy, question and session counts, and average time per question.
• Your study plan, daily lesson target, and daily snapshots of your estimated score.
• A log of which reminder emails were sent to you on which day.

Purchases

If you use our checkout, ASVAB Daily sends the email address on your account to Stripe for the hosted checkout and its payment receipt. The internal order temporarily keeps that address. It becomes eligible for removal at the whole-second provider cutoff, which is no later than 24 hours after the internal order was recorded. After that cutoff, ASVAB Daily will not issue another public create retry. An eligible checkout request or attended payment recovery can remove the copied address sooner; otherwise, the next daily cleanup removes it. Because the cleanup runs once per day, that normal sweep can occur almost another 24 hours after eligibility. Removal retains the non-email order identity and unresolved-purchase fence needed for a later signed event or attended provider reconciliation. A cleanup failure can delay removal and remains visible to payment operations. Stripe collects and processes the card and billing details you enter on its page. ASVAB Daily also stores the records needed to deliver and support the purchase: your internal order, the product and quantity, Stripe Price, Checkout Session, and Payment Intent identifiers, the order's Automatic Tax setting, order state and timestamps, and any in-app refund request, refund, or dispute state. Checkout requires Terms acceptance, stores the exact displayed revision message and acceptance status on the Checkout Session, and attaches that revision as metadata on both the Checkout Session and Payment Intent. We do not receive or store your full card number or card security code.

Sign-in and security records

Signing in works by emailing you a link. We store a session record and a hash of each sign-in link, never the link itself - the usable token exists only in your inbox and your browser. Alongside each sign-in request we store a SHA-256 hash of the network address it came from, to investigate abuse of the sign-in endpoint. The address itself is not stored with that record, and the hash is never included in a data export.

Separately, rate limiting protects the service from floods and abuse by counting recent requests against a short-lived counter. A few of those counters are keyed on your account. Most are keyed on the network address the request came from, which means your IP address appears in the counter's key in the clear. That is true across the service, on public and signed-in endpoints alike, so treat it as something that happens on ordinary requests rather than on a short list of special ones. What is kept is only a key, a window, and a number: it is not a log of what you did, and an address-keyed counter is never joined to your account or to your study record. Some of these counters live in our database and are deleted by a daily cleanup job once their window has elapsed; the rest live in Cloudflare's edge key-value store, where each is written with an expiry and stops being readable once that expiry passes. ASVAB Daily does not add browser user-agent strings to those database or edge rate-limit records. Cloudflare invocation logs and observability can process request metadata, including a browser user-agent, under Cloudflare's own retention controls.

An append-only security and operator-action ledger records bounded account events such as administrative reads and recovery actions. It retains opaque account, operator, request, and action identifiers after account deletion and has no automatic expiry. It rejects raw email addresses. An earlier operator email-change event can retain an unsalted SHA-256 digest of the destination address; that digest is pseudonymous data, not an anonymous value or a usable sign-in credential.

What we do not collect

• Passwords. There are none - sign-in is by emailed link.
• Date of birth or age. See the age section of the Terms of Service for why we do not ask.
• Full card numbers or card security codes. If you use checkout, Stripe handles those details as described above.
• Precise location, contacts, photos, or any device sensor data.
• Advertising identifiers or cross-site tracking data.

What is stored in your browser

The app keeps a small amount of state on your own device. None of it is sent anywhere except to ASVAB Daily's own servers, and clearing your browser storage clears all of it.

• An offline queue, held in IndexedDB, containing practice attempts that have not yet reached the server - so a dropped connection does not cost you your work.
• Local settings and in-progress state, held in localStorage: your theme choice, your reduce-motion preference, a short-lived return address so signing in brings you back to the page you were on, and any in-progress test or onboarding draft so you can resume it. The in-progress and draft entries are cleared when you sign out.
• A sign-in session cookie, set only after you sign in. It is HttpOnly, Secure, and SameSite=Strict, so scripts cannot read it and other sites cannot send it. It lasts 30 days, and signing out clears it. A second, 15-minute cookie is used only during cross-device sign-in.

We set no advertising, analytics, or third-party cookies of any kind. The cookies above are strictly necessary to keep you signed in.

How we measure the product

We do want to know whether the product works, and we chose a design that answers that without building a tracking capability that could later be misused or leaked. Funnel measurement is a single table of aggregate counters. A row is a UTC date, a step name, and a number. There is no user column, no IP column, no session column, and no user-agent column, and the table is never joined to any account data. The row stores no direct identifier or account link - only how many times a step happened on a given day. Someone who already knows when a small group reached a step could still draw an inference from a daily total. The internal operator report therefore hides protected daily activation cells and any exact trailing activation total that could reveal them. The identifier-free row shape is written into the database migration that creates the table, so it is a rule on the schema and not just a convention.

Those aggregate counters have no stored account key that deletion can select, so their totals are not changed when an account is deleted. Identifier-free aggregation does not make a small-group inference impossible; the reporting protections above address that separate risk.

We also measure whether people return after completing their first full daily session. The service groups those activations by UTC date and stores only the date, the number of activated accounts, exact-day return counts for days 1, 7, and 30, and the times those totals became final. It stores no account, email, IP, session, device, attempt, or raw event identifier in that measurement. Small groups are protected in the operator report: when a date has fewer than 10 activated accounts, its total and every return count are hidden. The aggregate rows store no account identifier or direct account link. Someone who already knew a person's activation date could otherwise infer behavior from a very small group, which is why those cells are hidden. The stored totals are not changed when an account is deleted.

Access to the internal measurement report is limited to an administrator and recorded before the report is read. That access record identifies the authenticated admin credential and request, not a learner, account, cohort member, device, or study event. A browser admin session has its own opaque id; use of the shared raw admin key records only a shared key label, not an individual person.

Third parties

This is the complete list of outside services involved in running ASVAB Daily, including the payment processor used if you buy access.

• Cloudflare hosts the site, runs the API, and stores the database. As our infrastructure provider it necessarily processes traffic to the service, including network addresses, in order to deliver and protect it.
• Transactional email. Mail is sent through an email service operated by Conde Digital Solutions LLC, which in turn sends through Resend. Your email address is passed along that path in order to deliver the message. Resend also maintains a bounce and spam-complaint suppression list, which is why an address that hard-bounces can stop receiving mail from us.
• Sentry is the third-party processor used by the browser and server error-reporting paths described below.
• Stripe is our payment processor. If you use checkout, Stripe receives the account email address we send for hosted checkout and receipt delivery, and processes the card and billing details you submit along with transaction and technical data needed to authorize the payment, prevent fraud, issue refunds, and handle disputes. Stripe returns the bounded transaction identifiers and status records described above; it does not give us your full card number or card security code.
• Cloudflare Turnstile is not running, and no Turnstile data leaves your browser today. Our API keeps a verification step for the public AFQT estimate endpoint, but no Turnstile widget exists anywhere in the app and our browser policy does not allow the inactive challenge host: no challenge is ever shown to you, no token is created, and nothing about your visit is sent to Cloudflare for one. The AFQT calculator on this site is a further step removed - the estimate works entirely inside your browser and sends none of your score inputs to our API. If we ever switch a challenge on, it would require a reviewed browser-policy change, send a challenge token and your network address to Cloudflare for verification, and this page will say so before that happens.

We load no third-party browser analytics script. We do not use Google Analytics, advertising networks, social media pixels, session replay, or heatmap tools.

Error tracking, honestly

ASVAB Daily sends browser error reports to Sentry when the browser error-reporting connection is enabled. Owner-verified production evidence confirms that this path has sent events. Reports contain diagnostic data - stack traces and request context. In browser reports, token-shaped values are redacted before send and no learner identity is attached. The server path sends diagnostic error reports whenever its separate Sentry connection is enabled.

Why we are allowed to hold it

• To provide the service you asked for: your account, your answers, your schedule, and your progress. Without these there is no product.
• To keep the service secure and available: sign-in records, hashed request addresses, and rate-limit counters exist to stop abuse of public, sign-in, and authenticated service endpoints.

If you are somewhere that frames this in terms of a legal basis, providing the service is performance of our agreement with you, and protecting it is our legitimate interest in a secure service. Study reminders remain disabled for the controlled release described below.

Email we send you

Each message class has its own purpose and release boundary.

• Sign-in and account-security messages. A sign-in link is sent only when requested. If the separately gated email-change feature is enabled, its confirmation and security notices are sent only for that requested account action. Turning off reminders never blocks these messages.
• Payment receipts. If you buy access, Stripe can send the purchase and refund receipts described in the purchase section above.
• Study reminders. These remain disabled for the controlled Stage 1 paid release and are not sent. They cannot be enabled until the product has a genuine opt-in, a valid postal footer, a visible unsubscribe route, and proven suppression behavior. This policy must be updated before that changes.

Your data, in your hands

Download everything

Go to your Profile page, find "Data and account", and use "Download my data". You get a JSON file containing your profile, every attempt and every individual answer, your spaced-repetition and mastery state, your study plan, your progress snapshots, your reminder history, and your sign-in record. Security material - session identifiers, token hashes, the hashed request address, and your email hash - is deliberately withheld from the file, because handing those out would weaken the account they protect. The export is limited to five downloads an hour. If checkout has been activated and your account has payment records, the file also includes the orders, payment delivery and operator records attributable to you, in-app refund requests, access grants, and the events that changed those grants. It never includes Stripe's provider body or our one-way security digests.

Delete everything

On the same Profile page, "Delete my account" asks you to type your email address to confirm, then permanently removes your account, access grants, and personal study rows: answers, attempts, assessment records, spaced-repetition and mastery state, progress snapshots, study plan, reminder log, sign-in sessions and tokens, and the account record itself including your email address. This is a hard delete from the active service database, not a flag. It cannot be undone through the account, and there is no account recovery window. If this account has an open unpaid Stripe checkout, we first ask Stripe to expire it so it cannot accept a later payment after the account disappears. If Stripe reports payment processing, deletion pauses and leaves the account intact for a safe retry. After you confirm deletion, a failure to create and read back the recovery record or finish the database deletion instead leaves the exact deletion fence in place. That fence remains in place and refuses ordinary account changes while an owner-confirmed repeat or a bounded daily retry attempts the same fail-closed steps again. The specific records retained for recovery, security, measurement, payment, backup, and logging are disclosed below.

A few things do outlive the account for a short while, and this page is not going to pretend otherwise. Deletion is itself rate limited, so the request that deletes you writes a security counter whose key contains your account id; it lives in Cloudflare's edge key-value store with an expiry of at most an hour and stops being readable once that expiry passes. Separately, if you asked for a sign-in link recently, a counter keyed on a hash of your email address is still in our database, where the daily cleanup job removes it once its window has elapsed - so at most about a day. Each of those is a key, a window, and a number, holding nothing that could rebuild your account or your study record. The identifier-free aggregate measurement totals described above also continue; their rows store no account identifier or direct link to your account.

The bounded deletion retry also keeps a temporary database cursor so older blocked work cannot starve later requests. It contains the exact fence time and an internal database row number, not your email address, account UUID, recovery digest, or object key. That makes it identifier-minimized operational personal data, not anonymous data. A completed traversal clears the cursor; an older backup or point-in-time state can retain its prior value for the recovery windows described next.

Separately controlled daily disaster-recovery backups are full copies of the database. An older private backup can therefore retain rows that were later deleted from the active service until that backup expires, currently no more than 35 days after it was created. Cloudflare D1 also keeps built-in point-in-time recovery history for up to 30 days under its current provider limit. Neither recovery layer is available to recover an individual account. Deleting an account does not immediately rewrite or remove every older full-database backup or point-in-time recovery state.

To stop an older recovery copy from silently bringing the account back, account deletion also creates one short recovery-authority record before the active database rows are removed. It contains a one-way SHA-256 digest of the server-generated account id and the owner-confirmed deletion-request time, not your email address, study record, payment identifiers, network address, or a reason for deletion. It is kept in a separate private Cloudflare R2 bucket under a 45-day prefix lock and expires no earlier than day 46. The digest is pseudonymous personal data, not anonymous analytics. An authorized Cloudflare account administrator can remove that lock, so a recovered database remains unavailable unless the service can verify the bucket settings and their change history for the complete recovery interval.

The append-only security and operator-action ledger described above also survives account deletion. Its opaque identifiers and bounded details cannot rebuild a study record, but they remain linkable security evidence and have no automatic expiry.

If checkout has been activated and you made a purchase, deletion removes your access grants and the order's direct account link. We retain the detached order and bounded Stripe identifiers, one-way account and request digests, signed-event delivery and replay evidence, the detached in-app refund request with its request trace cleared, fulfillment and refund or dispute blocks, and related operator audit records. We need that evidence to stop a delayed or duplicate provider event from restoring access and to reconcile payments, refunds, and disputes. These records do not contain your email or study history, but Stripe identifiers remain pseudonymous rather than anonymous and Stripe may retain the corresponding transaction under its own policy.

Our server logs are another honest exception. Some signed-in activity can create a structured line carrying the opaque account identifier. The account-deletion result line deliberately omits that identifier. Cloudflare holds those logs on a schedule we do not configure, so we are not going to quote you a retention window we cannot verify from our own settings.

Correction and other requests

Your career targets, time zone, and email preference are all editable from your Profile page. For anything else - a correction, a question about this policy, or a request you cannot complete in the app - use the contact route below.

If we deny a privacy request, we will explain why. You may appeal by replying to that response or emailing the privacy address below with "privacy appeal" in the subject. We will review the appeal and, if we deny it, tell you how to contact the regulator that applies to the request.

How long we keep it

Plainly: your study record is kept until you delete your account. There is no automatic expiry on practice attempts, answers, mastery state, or study plans, and we are not going to claim a retention schedule the code does not implement. Deleting your account is the mechanism that ends retention, and it is available to you at any time without asking us.

The retained payment evidence described above has no automatic expiry in the service today. It remains for replay prevention and payment reconciliation after the account link is removed. Stripe controls the retention schedule for the transaction records it holds as the payment processor.

The append-only account security and operator-action ledger also has no automatic expiry. Private full-database backups expire under the separate 35-day disaster-recovery lifecycle described above, and Cloudflare's built-in point-in-time recovery history has a current maximum of 30 days. The separate digest-only recovery-authority record is locked for 45 days and expires no earlier than day 46.

Some things do expire on their own:

• Sign-in links expire 15 minutes after they are issued and can be used once.
• Sign-in sessions expire after 30 days.
• Expired sessions, used or expired sign-in links, finished cross-device pairings, and the rate-limit counters held in our database are deleted by a daily cleanup job. The rate-limit counters held in Cloudflare's edge key-value store expire on their own instead.

Security

The service runs over HTTPS. Sign-in tokens and session cookies are stored as hashes, so the database never holds a usable credential. The session cookie is HttpOnly, Secure, and SameSite=Strict. Sign-in, verification, and the public endpoints are rate limited, and the site sends a strict Content Security Policy that names every outside host it is allowed to talk to.

What we will not tell you is that this makes the service unbreakable, that we hold a security certification, or that we have passed an external audit. We have not sought one, and claiming otherwise on this page would be the easiest lie on it.

Where your data is

The service runs on Cloudflare's global network, and the database is a Cloudflare D1 database. Depending on where you are, that may mean your data is processed outside your own country. Processing in another country does not waive any privacy right that applies to you.

Children

ASVAB Daily is not intended for anyone under 13, and we do not knowingly collect data from anyone under 13. We do not ask for a date of birth - collecting birth dates from a general audience would mean gathering more personal data from more people in order to manage a risk it also creates. If you believe a child under 13 has created an account, use the contact route below. We will investigate promptly and take the steps required by applicable law. Because a report alone does not prove authority over an account, we use a verified process before restricting or deleting it. Active-account deletion and the limited records that can survive it are described above.

Changes to this policy

If this policy changes, the date at the top changes with it. If a change materially affects what we collect or what we do with it, we will say so on this page rather than revising it quietly.

Contact

Have a question about this policy or your privacy rights, or need help with a request you cannot finish in the app? Email privacy@condedigitalsolutions.com.

ASVAB Daily is operated by Conde Digital Solutions LLC.