Beta Briefing — Privacy Policy

Version: v2.1 Last updated: 2026-09-06

The short version

Beta Briefing is a personalized news briefing service. To do that, we need to know a few things about you (your email, what you're interested in, when you'd like your briefing) and we need to send some of that information to AI providers, search APIs, and an email-delivery service so we can actually research and ship your briefing.

We don't sell your data, and there is no third-party ad tracker, ad pixel, or ad-network tag on our pages — nothing that reports your browsing to an advertising company. The one piece of advertising code we run is our own, and it reports your browsing to no one: when you arrive from one of our ads it reads the click ID out of the address so the sign-up form can carry it (§2.3). We do buy ads on Google. When someone signs up after clicking one, our server — never your browser — tells Google that the click led to a trial or a subscription, and, for a subscription, the plan's list price. That is the whole message: no name, no email, nothing about your briefing, and nothing at all if you arrived some other way. In the EEA, the UK, and Switzerland the sign-up form asks first, and a "no" means we send nothing. If we can't place you when the page loads, we ask too; if your browser's time zone then places you outside those places when you submit, the question didn't apply to you and an unticked box isn't read as a "no" (§2.3, §3, §4, §7). The web dashboard uses a signed session cookie, and one short-lived sign-up cookie if you tick the ad-measurement box (§2.3); the public site uses a privacy-friendly analytics service that doesn't set cookies and doesn't store your IP address. Briefing emails measure deliverability and engagement (opens and clicks) so we can tell whether briefings are actually landing — full details in §2.3.

If you subscribe, payments run through Stripe. Your card number goes directly to Stripe and never reaches our servers; what we keep is your plan, its status, and Stripe's identifiers for your account (§2.2, §4).

You can edit your data at any time in the dashboard; to export or delete it, email us.

The rest of this document is the formal version.

1. Who we are

This Privacy Policy describes how Beta Briefing LLC, a California limited liability company ("Beta Briefing," "we," "us," or "our"), handles your personal information when you use our website, email briefings, audio briefings, podcast feeds, web dashboard, and related services (together, the "Service").

This Policy is incorporated into our Terms of Use. For questions, contact us at legal@betabriefing.ai.

2. Information we collect

2.1 Information you give us directly

• Account information. Your name (optional) and email address.
• Onboarding description. When you sign up via our public onboarding form, you provide a freeform description of yourself and your interests. We use this to generate your initial briefing configuration.
• Briefing configuration. Topics, publications, schedule, format, writing-style preferences, audio preferences, and similar settings you set or edit through the dashboard. You can change these at any time.
• Smart Edit prompts. When you use the dashboard's natural-language config editor, the prompts you write are sent to our AI provider to generate the proposed configuration changes.
• Feedback. Freeform feedback you send us through the Help & Feedback option in the dashboard, which opens an email to our team.
• Referral source. If you tell us how you heard about Beta Briefing during signup, we store that for our own understanding of where users come from.
• Email theme preference. Whether you prefer the light or dark email template. Stored server-side as part of your briefing configuration so we can render emails in your preferred style.
• Telegram chat ID. Only if you choose to link your Telegram account for briefing notifications, in which case we store the chat ID needed to message you.
• Public-profile details, if you sign up by sharing your public work. That sign-up option asks for any of an X handle, GitHub username, LinkedIn URL, website, and employer, plus free-text notes. We store what you provide and use it to research the public profile of the person signing up; §4 lists the providers involved.

2.2 Information generated as you use the Service

• Briefing memory. To make recurring stories feel coherent over time, we keep two kinds of memory tied to your briefing:
  • Story memory, a rolling 30-day record of recent stories and key facts so we don't repeat ourselves and can write follow-ups intelligently.
  • Topic memory, a longer-lived evolving summary per topic that captures the running thread of a beat. Topic memory is updated after each briefing run; we may delete it on request.
• Run records. Operational metadata about each briefing run — when it ran, which models and search providers were used, success/failure, token and dollar costs. This is used for cost tracking, debugging, and reliability.
• Briefing artifacts. The intermediate research, candidate stories, and editorial outputs produced when generating your briefing. These are stored on our server and are not published unless your briefing belongs to a public channel (see §5).
• Dashboard interactions (saved, liked, dismissed). When you use the dashboard to save, like, or dismiss story cards, we store a snapshot record of that action (saved_items_snapshot, liked_items_snapshot, and dismissed_items_snapshot tables). These records power the Saved, Liked, and Dismissed library pages and feed-filtering features. They are stored as first-party feature data, not shared externally. They live in a separate database from your account record and are deleted automatically when your account is deleted.
• Subscription and billing records. If you start a trial or subscribe, we store the plan attached to your briefing, its billing status, and the dates that drive it (when a trial ends, when the current paid period ends, when complimentary access expires), along with the identifiers Stripe uses for your customer and subscription records. We also keep an audit log of the billing events Stripe sends us — subscriptions created, payments succeeded or failed, refunds, disputes — so we can reconstruct what happened to an account. We do not store card numbers (§2.4).
• Sign-in and verification tokens. Signed sign-in links that expire after 15 minutes, and sign-up email-verification tokens that stop working after 14 days — except invitation links we create when we invite you ourselves, which last 90 days. Verification records become eligible for deletion about a year after the sign-up attempt they belong to, and are removed during periodic cleanup — so a record can persist past a year until the next cleanup runs. Deleting your account invalidates them sooner.
• Telegram link tokens. Short-lived one-time tokens used during the Telegram linking flow. Expires after 15 minutes.

2.3 Information collected automatically

• Session cookie. When you sign in to the dashboard, we set a signed session cookie (itsdangerous-signed). It uses a rolling ~30-day sliding window that refreshes on activity, so staying active keeps you signed in; sign out or a period of inactivity ends it. It identifies your account on subsequent requests. No third party reads it.

• Sign-up proof cookie. If you tick the ad-measurement box on the sign-up form, we set one more signed cookie in that browser, holding only an opaque reference to your sign-up — no click ID, no email. It lets us keep your "yes" only when the confirmation link is opened from the same browser that ticked the box; opened elsewhere, the "yes" is dropped and nothing is sent. It lasts as long as the pending sign-up does (14 days) and is removed when you confirm.

• Appearance preferences. Your light/dark theme choice on the public website is stored locally in your browser via localStorage — it doesn't leave your device. Some interface state is instead stored server-side against your account: your dashboard theme, accent and layout density (so the dashboard looks the same on every device you sign in from), your email template preference (§2.1), which we need at email-render time, and which guided tours you've seen or completed. Smaller states stay only in your browser — whether the dashboard sidebar is pinned, and how much detail a briefing's story cards show.

• Ad click identifiers — only if you arrive from one of our ads. When you land on our public site from a Google ad, the address you arrive on carries Google's click ID. A script on our own pages reads it and keeps it — with the moment it first saw it, which campaign it came from, and a two-letter country code — in your browser's sessionStorage, which the browser throws away when you close the tab. The script itself sets no cookie and uses no localStorage; on the public site nothing outlives the visit. Having read it, the script immediately removes the click ID from the address bar — before our analytics reads the page address — so it isn't kept in our analytics records for the public site (§6). Its only job is to carry those values across to the sign-up form on app.betabriefing.ai when you click through, so we can tell Google the ad worked (§3, §4) and, where we're required to, ask you first (§7). On that form the ID does arrive in the address, because that is how it crosses between the two sites, and it is recorded there as §6 describes. To read the country code, the script makes one request to https://betabriefing.ai/cdn-cgi/trace — an address on our own site, answered by Cloudflare, which already handles every request to the site anyway. It makes that request only when a click ID is present; on an ordinary visit it makes none. On the sign-up form itself, your browser's time-zone name is submitted with the form whenever you arrive from an ad; we consult it only if no country code came through, to work out whether to ask you. We keep the region we worked out, not the time zone. Visitors who don't arrive from an ad have none of this: no stored ID, no lookup, no record.

• Web analytics (two-tier). We run a self-hosted Umami instance at analytics.betabriefing.ai. Umami is cookieless — it uses a session hash derived from browser metadata (user-agent, language, screen size, IP) without storing a persistent cookie or cross-site identifier.

  • Tier 1 — Public site and pre-auth funnel (login, sign-up, onboard, claim, research sign-up, unsubscribe): tracked under a separate website ID (UMAMI_WEBSITE_ID_PUBLIC) with no subscriber identifier attached — no umami.identify() call is made. Data collected: page URL (including any campaign parameters it arrived with, such as which ad campaign sent you — but not the ad click ID itself on our public site, which is removed from the address before analytics reads it; on the sign-up form, which is on a different site of ours, it is still in the address analytics records), referrer, browser type, country. Legal basis: legitimate interest (Art 6(1)(f) GDPR).
  • Tier 2 — Authenticated portal and dashboard (pages you see after signing in): tracked under a separate website ID (UMAMI_WEBSITE_ID_APP). We call umami.identify({ id: "<slug>" }) after page load to attribute activity to your pseudonymous subscriber slug (e.g. adam-miller-3). Your slug is name-derived and therefore personal data. Legal basis: legitimate interest (Art 6(1)(f) GDPR) — understanding how authenticated subscribers use product features for product improvement. Admin impersonation suppresses the identify call so admin browsing a subscriber's view is not attributed to that subscriber.

  We also keep Cloudflare Web Analytics (beaconed to Cloudflare) for aggregate traffic monitoring. It provides aggregate visitor counts, does not set cookies, does not fingerprint visitors, and does not record full IP addresses.

• Email-delivery metadata and engagement. Our email provider (Resend) reports deliverability information (delivered, bounced, complained) and may track engagement with our emails — specifically, when emails are opened (via a small embedded tracking image) and when links inside briefings are clicked (via a tracking redirect that forwards you to the source). These events record a timestamp and basic technical data, such as user agent and approximate location derived from your IP address. We use this information to monitor inbox placement, troubleshoot delivery problems, and understand which briefings and stories are being read so we can improve them.

• Server logs. Our application server and pipeline logs may briefly record IP addresses, user agents, request paths (including anything in the address, such as an ad click ID arriving at the sign-up form), and error traces for security and debugging. We keep them for those purposes only and don't combine them with your account profile for tracking. They live in the server's system log, which rotates them out automatically; we don't commit here to a particular retention period for them. Our public site is served by a static host and we keep no request log of our own for it.

• Dashboard behavior telemetry (currently disabled). The dashboard is capable of logging a richer stream of interaction events to a behavior_events table (page opens, dwell time, item interactions, preference changes). This collection is disabled by default and is not currently active in production. If enabled in the future, telemetry would be bounded by a configurable retention window (default 90 days) and used solely for product improvement. No behavior telemetry is shared externally.

2.4 Information we do not collect

• We don't put ad networks, third-party marketing pixels, or ad trackers on any page. No Google tag, no consent mode, no remarketing tag — nothing on our pages that reports your browsing to an advertising company. The only advertising code on our site is the first-party script described in §2.3: it reads the click ID out of the address and hands it to the sign-up form. It reports nothing to an advertising company, and the single request it makes is to an address on our own site. We do buy ads on Google, and we measure whether they work afterwards, from our own server (§3, §4, §7). No advertising data goes to Google from your browser — no click ID, nothing about your account, nothing about what you read. Our pages do load web fonts from Google Fonts (§4), which, like any file your browser fetches from another host, tells Google your IP address and browser type; it carries none of the above.
• We don't ask for or store your card details. Payment information is entered on Stripe's own checkout and customer-portal pages and stays with Stripe. Your card number and security code never reach our servers, and we don't store the billing address Stripe collects. What we do hold is described in §2.2.

3. How we use your information

We use the information described above to:

• Operate and personalize the Service — researching, generating, rendering, and delivering your briefings.
• Maintain continuity in your briefings (using memory described in §2.2) so recurring stories build on prior coverage.
• Send you transactional messages: your daily briefing, recap emails, sign-in magic links, account notifications.
• Take payment and run your subscription — starting and ending trials, charging renewals, telling you when a trial is about to end or a payment failed, and keeping the accounting records behind those charges.
• Monitor email deliverability and engagement (such as whether briefings are reaching inboxes, being opened, and which stories or links are being read) to maintain delivery quality and improve briefings.
• Measure our advertising. If you arrived from one of our Google ads, we tell Google that the click led to a signup, so we can see which ads are worth paying for. What we send is the click identifier, what happened (a trial started, or a subscription started), when, the plan's list price if you subscribed, and an opaque reference we use to avoid counting the same event twice — no name, no email, no briefing content (§4). Where consent is required we ask on the sign-up form and honour the answer (§7). We don't use it to target advertising at you: every message we send explicitly declines personalized advertising.
• Detect, prevent, and debug operational problems, errors, abuse, and security incidents.
• Improve the Service. Briefing artifacts and feedback may be reviewed manually by the operator to improve quality. We do not sell or share this data with outside parties for their own use.
• Comply with applicable law and respond to lawful requests.

We do not use your data to train general-purpose AI models. We select providers and configurations whose terms do not, by default, use customer API data to train their models. For routed providers (such as OpenRouter), training behavior depends on the underlying model's upstream provider, and we choose models accordingly.

Automated processing. Briefings are produced by automated systems that select, score, and write content based on your configuration. Human review is limited to the operator's ongoing quality monitoring rather than a per-briefing approval step. If you have concerns about how this processing affects you, contact us at legal@betabriefing.ai.

4. Third-party services we share data with

To operate the Service we send relevant portions of your data to the following providers. Each receives only what's needed for its function.

The providers listed above may use their own infrastructure sub-processors (such as cloud hosting providers like AWS, GCP, or Azure) under their own terms.

We may also disclose information when required by law, to enforce our Terms of Use, to protect the rights, property, or safety of Beta Briefing, our users, or others, or in connection with a sale or transfer of the Service (in which case the recipient is bound by terms at least as protective as these).

We do not sell your personal information. The only thing we send to an advertising platform is the conversion record in the Google Ads row above — sent to Google, acting as our processor, so we can tell whether an ad we paid for did anything. We don't hand your details to advertisers for their own purposes, we don't take part in ad exchanges or data co-ops, and we don't build or share audience segments.

5. Public channels and publication

Some briefings are published as public channels with their own permanent web archive, RSS feed, and podcast feed. Public-channel briefings carry an intro paragraph and audio script written from the channel's identity rather than yours, and if your full name appears in that public intro we automatically replace it with the channel name. That guard is deliberately narrow — a first name on its own is an ordinary word in the news, so we don't substitute it separately — and because the writing is AI-generated we can't guarantee that no personal detail ever reaches a published edition. If you spot one, tell us and we'll correct it. Publication is intentional and channel-level, not user-level: a personal briefing is never published as public web pages unless it has been explicitly configured as a public channel.

If your briefing is part of a public channel, the published briefing content is publicly accessible by design. The settings, configuration, and memory associated with it remain private to you and the operator.

Podcast and RSS feeds. A briefing configured with a channel has a podcast and RSS feed so it can be followed in a podcast app (podcast apps can't sign in). Feed content carries the channel pseudonym and the public intro and audio (see the anonymization note above, and its limits) — never the personalized intro or your email address. One exception to be aware of: the links inside a private feed point to your own sign-in-protected dashboard and include your briefing's identifier, which is typically derived from your name — so anyone who holds the feed URL can see which briefing it belongs to (the pages behind those links still require signing in). When a briefing is not published as a public channel, its feeds are served at an unguessable, non-indexed URL (a random token in the path) that is not linked from any public page: reachable only by someone who has the URL, and excluded from search engines. Because a feed URL is effectively a shareable key, anyone you give it to can read that feed. You can ask us to rotate the URL at any time, which disconnects existing subscribers.

6. Data retention

• Account and briefing configuration. Retained for as long as your account is active. Deleted (or anonymized to the extent we still need it for operational records) when you ask us to delete your account.
• Story memory. Retained on a rolling 30-day window per briefing.
• Topic memory. Retained until updated by a future briefing run, edited at your request, or deleted on request.
• Run records and briefing artifacts. Retained for as long as needed for cost tracking, reliability, and reproducibility, and reviewed periodically for deletion. Deleted on request, subject to legal record-keeping needs.
• Subscription and billing records. Retained while your subscription is active, and afterwards for as long as we need them for accounting, financial record-keeping, and chargeback or dispute handling — typically seven years — even if you delete the rest of your account. Stripe keeps its own payment records under its policy.
• Sign-in link records. Expire on their own; the record of a used link is deleted shortly after it expires.
• Sign-up verification records. Stop working after 14 days — 90 days for invitation links we create when we invite you ourselves. The record itself becomes eligible for deletion about a year after the sign-up attempt and is removed during periodic cleanup, so it can persist past a year until the next cleanup runs.
• Public-channel archives. Retained indefinitely while the channel exists. Published editions are written at the channel level rather than addressed to you (see §5), so we don't take them down merely because you change your topics, schedule, or delivery settings — but if you delete your account, or ask us to stop publishing the channel, that channel's pages come down at the next site rebuild. If you operate a public channel and want it discontinued or specific past editions unpublished, contact us.
• Dashboard saved and liked items. Retained as long as the action stands (you can un-save or unlike at any time in the dashboard).
• Dashboard archived (dismissed) items. You can un-archive at any time in the dashboard. Otherwise we keep roughly the most recent 200 dismissals per briefing; older ones are cleared automatically each day.
• Deleting saved, liked, and dismissed items. They are deleted automatically when your account is deleted.
• Research records. If you signed up by sharing your public work — or if we researched your public profile before inviting you — the form entry itself follows the sign-up-verification retention above. The research run it produced is separate: the details you gave us (§2.1), the evidence the agent gathered about you, and the profile it wrote are stored on our server and kept indefinitely. When your account is deleted we remove the run's record; the evidence and profile files it produced are removed on request.
• Dashboard behavior telemetry (when enabled). Retained for the configured retention window (default 90 days) from the timestamp of the event; trimmed automatically by a daily job.
• Umami analytics — Tier 1 (public/funnel, no subscriber identifier). Retained until manually deleted. No slug is attached to it, and on our public site it holds nothing that identifies you. The exception is the sign-up form, where the recorded page address can carry an ad click ID — the next bullet covers that.
• Umami analytics — Tier 2 (authenticated, slug-identified). Retained until erasure request or account deletion. Erased via internal tooling within 30 days of a valid request.
• Ad click identifiers. Deleted from our live database 90 days after the click — from the sign-up record and from your account record alike — leaving only a one-way hash of the identifier on our ledger of every ad-sourced conversion we decided on, whether or not we sent it. We keep that hash so the same conversion can't be sent twice, and so a decision not to send one — including a signup you told us not to report, where nothing was ever sent to Google at all — stays on the record. What goes at 90 days is the identifier itself; the rest of what we recorded about the click does not. That is: when the click happened and which kind of click it was, which campaign and ad group it came from, the region we worked out, and — where we asked — your answer to the consent question and which wording you were shown. On the conversion ledger it also includes the date the identifier was due for deletion, from which the time of the click can be worked back. Those follow the retention of the record they sit on — your account record and the sign-up record above — and on the conversion ledger they stay for as long as the ledger does, alongside the hash. That deletion runs on its own schedule whether or not the measurement integration is switched on or working. It reaches our live systems; our database backups are separate, so a backup taken while the identifier was still there keeps it until that backup ages out on its own rolling schedule, which for the oldest copies we keep runs to years. On our public site the click identifier is taken out of the address bar as soon as it is read, before our analytics records the page address, so no copy is kept in our analytics there. That removal happens in your browser, after the page has been requested, so the ad landing itself is requested with the identifier still in the address — and that request is handled by Cloudflare, which hosts our public site and sees every request to it (§2.3, §4). Other copies sit outside the database too. The ones that follow come from the sign-up form on app.betabriefing.ai, where the identifier arrives in the address so the form can read it. It appears in the page address recorded by our self-hosted Umami analytics (Tier 1 above — retained until manually deleted), and in that server's request log, kept for security and debugging and not linked to your account profile (§2.3). It is also in the address bar of the page itself, which means the interface libraries that page loads from public code CDNs could read it, as any code running on a page can; we don't send it to them and they aren't part of our measurement, but we'd rather say so than imply the address is sealed.
• Email-delivery metadata. Retained by our email provider for the period described in their policy.

7. Your rights and choices

Wherever you live, you can:

• Access and edit your data. Sign in to the dashboard at the URL we email you. The dashboard exposes your full briefing configuration and your settings (email theme, audio voice preference, Telegram, announcements preferences); edits take effect immediately. To change your name or email address, or to access or edit your briefing memory (story memory and topic memory described in §2.2), email us — we'll send you a copy or apply your edits.
• Export your data. Email us and we'll send a copy of the data we hold about you in a machine-readable format.
• Unsubscribe. Briefing emails carry an unsubscribe link; you can also email us to stop briefings.
• Manage or cancel a subscription. Your Billing page in the dashboard opens Stripe's hosted customer portal, where you can update your card, change plans, view invoices, or cancel. Cancelling takes effect at the end of your current trial or paid period, not immediately (Terms §4.4).
• Delete your account. Email us and we'll delete your account, configuration, memory, your saved/liked/dismissed dashboard items, and the record of any research we did on your public profile; your historical briefing artifacts and any research evidence files are kept unpublished on our server and removed if you ask. Your briefing's identifier is retired for good — a new account under the same name gets a new one, so nothing from the old account can attach to it. If you have a live subscription, cancel it first — or say so and we'll cancel it as part of the deletion. Billing and payment records are kept for the period described in §6. (Public-channel archives are channel-level rather than addressed to you; see §6 for what happens to them.) We may retain limited records as required by law or for security and abuse prevention. If you used the authenticated portal or dashboard, we will also erase your identified Umami analytics data (the pseudonymous slug attributed to your sessions) within 30 days of your request, using our internal erasure tooling. If you arrived from one of our ads, that erasure also covers the sign-up-form pageview our analytics recorded with the ad click identifier in its address (§6), which we remove by hand.
• Opt out of optional integrations. Telegram notifications and your audio voice preference can be turned off or changed in your dashboard settings. For recap-email preferences, email us.
• Opt out of ad measurement. If you arrived from one of our Google ads, you can tell us not to report your signup to Google — email us and we'll mark it withdrawn. That stops everything we haven't sent yet, including anything sitting in a queue or a retry: each attempt re-reads your current answer rather than the one we had when we queued it. What it can't do is take back a conversion we already sent — once Google has it, it is recorded on their side, and we have no way to retract it. If we asked you on the sign-up form and you left the box unticked, nothing was ever sent in the first place — apart from the one edge case described under Ad measurement in the EEA, the UK, and Switzerland below. A self-serve control is on the way; for now the address at the bottom of this page is the channel.

California residents (CCPA/CPRA): You have the right to request access to, correction of, and deletion of your personal information, and to opt out of its sale or sharing. We do not sell personal information. The one disclosure that touches advertising is the conversion record described in §3 and §4: if you arrived from one of our Google ads, we tell Google that the click led to a signup. We send it to Google as our service provider, for measurement only — every message we send explicitly declines personalized advertising, and we don't use it to build, buy, or target audiences — so we do not treat it as "sharing" for cross-context behavioural advertising as the CPRA defines that term. If you would rather we didn't send it at all, tell us and we'll stop (see the ad-measurement opt-out above). To exercise your rights, email legal@betabriefing.ai.

EEA / UK residents (GDPR / UK GDPR): You have rights of access, rectification, erasure, restriction of processing, data portability, and objection. Our legal basis for processing is performance of our agreement with you (delivering the Service you signed up for) and our legitimate interests in operating, securing, and improving the Service. To exercise your rights, email legal@betabriefing.ai. You also have the right to lodge a complaint with your local data-protection authority.

Ad measurement in the EEA, the UK, and Switzerland: If you're in one of those places — or if we can't tell where you are — and you arrive from one of our Google ads, the sign-up form asks you, in a single unticked box, whether we may tell Google the signup came from its ad. It is never required and it changes nothing about the product: leave it alone and you get exactly the same service. If you decline, we never send your signup to Google at all. Neither do we if you agree and later withdraw (see the ad-measurement opt-out above) — every send re-reads your current answer before it goes. Either way the signup still counts in our own records; it simply stays with us. One edge case: if we couldn't place you when the page loaded but your browser's time zone places you outside the EEA, the UK, and Switzerland when you submit, the question didn't apply to you — an unticked box is not treated as a decline, and the signup is reported the way it would be for anyone outside those places (a ticked box is still honoured as consent). We also record which wording you were shown, so a later change to the question can't be read back onto an answer you gave to a different one.

We will respond to verifiable requests within the time required by applicable law (typically 30–45 days).

8. Children

The Service is not directed to children under 18, and we don't knowingly collect personal information from anyone under 18. If you believe a child has provided us personal information, contact us and we'll delete it.

9. International users

Beta Briefing operates from the United States, and our service providers are primarily located in the United States. If you use the Service from outside the United States, you understand that your information will be transferred to and processed in the United States, which may have data-protection rules that differ from your local laws.

10. Security

We use reasonable technical and organizational measures to protect your information, including TLS for all web traffic, signed session cookies, magic-link authentication (no passwords stored), and access controls on operational data. No system is perfectly secure, however, and we can't guarantee the security of information transmitted to or from the Service.

If we become aware of a security incident affecting your information, we'll notify you and any required authorities as required by applicable law.

11. Changes to this policy

We may update this Privacy Policy from time to time. If we make material changes, we'll notify you by email or through the Service before they take effect, and we'll bump the Version at the top of this document. Your continued use of the Service after changes take effect means you accept the updated Policy.

12. Contact

Questions, requests, or concerns about this Privacy Policy?

• Email: legal@betabriefing.ai
• Mailing address: Beta Briefing LLC, 2108 N St, Ste N, Sacramento, CA 95816, USA