What this extension does
AlphaDraft reads the live data stream of an ESPN auction fantasy draft
while you are on an ESPN draft page, and turns it into real-time bid/pass guidance. To do that it
observes the WebSocket messages the ESPN draft page already exchanges (nominations, bids, the clock,
and sales) and forwards a normalized version of them to its configured receiver.
What data is handled
- Draft event data from the active ESPN auction draft: nominated players, bid
amounts and the seats that placed them, the draft clock, and completed sales. This is
fantasy-sports gameplay data, not personal browsing history.
- Draft context data read from the draft page to make the above usable: the
league ID, the team display names and team IDs in your draft, each team's budget and roster (the
player names, positions, and prices they've won). Team/owner display names are league-chosen
labels that can contain real names or usernames — this is the in-draft state visible to your
league, not your personal account data.
- A cached copy of the latest draft snapshot and a sold-player index, written to
Chrome's local storage on your own device so the war room can resume after a page
reload. These hold the draft-context data above; they live only on your machine and are cleared
when you remove the extension.
- A short, bounded local retry queue of draft events awaiting forwarding, so a
brief network or relay hiccup doesn't drop picks. It is held in Chrome's local storage on
your device only (never synced), is capped in size, and is cleared when you remove the extension.
In the Chrome Web Store build, draft events captured before you grant the hosted permission are
held in this on-device queue and are forwarded only once you grant it.
- Your extension settings, stored by Chrome: the configured forwarding
destination (in the developer / side-load build you can pick Local or Hosted; the Chrome Web Store
build uses Hosted), whether forwarding is enabled, the optional raw-capture toggle, and the status
of the last forward.
- An in-page overlay credential (only if you turn on the optional in-page
overlay): a short-lived, read-only access token and the war-room room id, written to
Chrome's local storage on your device only (never synced) so the on-page advice can
authenticate. It is never sent anywhere except as an authorization header to the war-room service
when fetching your own draft advice.
The extension's content scripts run on ESPN domains — it reads and acts on your live auction-draft
page. The extension also declares a small content script on the AlphaDraft war-room site
(alphadraft.ai; the developer / side-load build also covers the legacy war-room address
draft.ninetalents.com) whose only job is to receive the short-lived overlay
access token you enable when you turn on the optional in-page overlay — it reads
no other website's content and does nothing until you turn the overlay on. The only
non-ESPN addresses the extension can reach are
the receiver destinations for the draft data it forwards: a local receiver on your own computer
(loopback) or the hosted war room — which one is the default depends on how you installed the
extension (see below). It does not track your browsing, contains no
analytics or advertising SDKs, and the extension itself does not collect your name, email, contacts,
location, or financial information.
Where the data goes (this is the important part)
Where the extension forwards your draft events depends on how you installed it.
(If the extension's options page offers only a hosted receiver, you have the Chrome Web
Store build; if it offers both a local and a hosted receiver, you have the developer /
side-load build.)
- Chrome Web Store build — the default destination is the hosted war room. The
published package is preconfigured to forward draft events to the hosted AlphaDraft
war room at
https://alphadraft.ai. Forwarding is enabled, but Chrome does
not let the extension send to that hosted receiver until you grant the
optional site permission it must have to forward there — requested on a deliberate click,
not granted automatically at install.
Before you grant it, no draft events or snapshots are sent to the hosted receiver.
After you grant it, draft events are sent to and stored by the hosted service, as described under
"Storage and retention" below. The Store build does not include the local-receiver option.
- Developer / side-load build — the default destination is your own computer. The
beta / developer build is preconfigured to forward draft events to
http://127.0.0.1:8971
— a server running on your own computer (the loopback address). If you have not
started that local receiver, nothing is received and nothing leaves your machine. This build sends
to the hosted war room only if you switch the receiver to "Hosted" and grant the hosted site
permission. Older side-load builds configured for the legacy war-room address
(draft.ninetalents.com) keep working — it is the same hosted AlphaDraft service,
which currently answers at both addresses.
Honest note on defaults: event forwarding is enabled by default in both
builds, but the default destination differs. In the Chrome Web Store build
the default destination is a remote server (alphadraft.ai); your draft data
reaches it only after you grant the hosted site permission Chrome prompts for. In the
developer / side-load build the default destination is your own computer (loopback),
and no draft data is transmitted off your device unless you switch to the Hosted receiver and grant
that permission.
Raw capture (off by default, local only)
The options page has an optional "Capture the raw frame stream" toggle used for diagnostics. It is
off by default, and the extension structurally refuses to send raw frames
to any non-local address — raw capture only functions when the receiver is the loopback
address, and that setting is stored locally and is never synced to other devices. (Because the
Chrome Web Store build has no local receiver, raw capture cannot send anywhere in that build.) This
guard exists because a raw frame can embed session/room material.
Signing in to the hosted war room (Google)
The hosted war-room service at alphadraft.ai is access-controlled, so if you opt
into it you sign in with Google. We request the standard, non-sensitive sign-in
scopes openid email profile — that is your email address and basic profile (your name
and profile picture), which we use to identify your account and gate access. We do
not request access to Gmail, Google Drive, your contacts, your calendar, or any
other Google data. The browser extension itself does not sign you in and requests no Google
permissions.
Storage and retention
- Settings are stored using Chrome's
storage API on your device (non-sensitive
preferences in your Chrome profile sync; the raw-capture toggle in local storage only). In
addition, the latest draft snapshot and a sold-player index are cached in Chrome's
local storage on your device (never synced) so the war room can recover after a
reload — this is draft-context data, held locally, not personal account data. You can clear all of
it by removing the extension.
- The extension itself does not maintain a server-side database of your data. When the
Hosted receiver is used (the default in the Chrome Web Store build, once you grant
the site permission), the AlphaDraft service stores the
room state needed to run and support your war room on its server: the draft events and snapshots
you forward, the engine's decisions, capture/health diagnostics, your account profile (your email
and Google display name), and the league setups you save. This is retained while you use the
service and for support; you can request deletion via the contact below.
- The Local receiver writes files on your own machine that you control entirely.
How the data is used
Solely to provide the draft-assistant functionality: turning the live draft into bid/pass guidance
for you, and (for the hosted service) identifying your account so your war room is yours.
Usage analytics
To understand whether the site is reaching and helping people, we keep a small amount of
first-party, aggregate usage analytics on our own servers. We do not
use Google Analytics or any third-party analytics service, and we set no tracking
cookies. What we keep are aggregate counts — plus, only so we can de-duplicate (count a
browser, a session, or an account once), a one-way, salted digest we cannot
reverse back to the underlying id. We never store the raw ids themselves:
- Anonymous page activity and the within-visit sign-in funnel — counts of
landing-page views, "Sign in" clicks, reaching the signed-in app, and reaching a live draft
recommendation in the app. To understand the sign-up funnel within a single visit —
how many sessions that arrive go on to sign in and use the tool — your
browser generates a random, anonymous session id and keeps it in your browser's
session storage. That id is temporary — scoped to the browser
tab session and normally cleared when that tab session ends — first-party, is not a
cookie (and not local storage), and is never used for
advertising, third-party analytics, or cross-site tracking. Our server never stores the
id: it keeps only a one-way, per-day salted digest of it so it can count distinct
sessions, and surfaces only the totals — never the id itself. We store no IP address and no
browser fingerprint as part of these analytics. (Like any web server, our host may keep
operational request logs, which can include an IP; those are not part of these analytics and are
not used to profile you.) Because this id lives only in your browser and only for the session,
these counts are best-effort — clearing storage or a new tab session generally starts a new
session id — so they tell us how sessions moved through sign-in, not who arrived or how many
people. (Whether a browser returns on a later day is counted separately, using the
persistent visitor id described next.)
- Returning visitors and the multi-day funnel — to tell whether a browser
comes back on a different day, and how many visitors who first landed later go on to
sign in and reach a live draft recommendation, your browser also keeps a random, anonymous
visitor id in its local storage. Unlike the session id above
this one is persistent — it survives closing the tab and lasts across days —
but it is still first-party, is not a cookie, and is never
used for advertising, third-party analytics, or cross-site tracking. Our server
never stores the id: it keeps only a one-way, salted digest
of it (a cross-day pseudonym it cannot reverse) so it can count returning visitors and the
multi-day funnel, and surfaces only those counts — never the id, an IP address, a browser
fingerprint, and never joined to your account. Because it lives only in your browser these
counts are best-effort and measure browsers, not people — clearing local
storage or using another browser is a new visitor. We keep it for a bounded, short retention
window and never longer than we need for these counts.
- Signed-in activity counts — how many distinct accounts were active on a given
day, how many leagues were created, how many drafts got going, and the aggregate outcome of
sign-in attempts (how many succeeded versus were turned away — for example because an email is not
yet invited). These are plain counts with no account attached to them. For the daily-active count we
store only a one-way, salted digest per day so we can count distinct accounts without keeping a list
of who was active; we surface only the totals.
- Onboarding & reliability counts — how many times an ESPN league was looked
up to import it and the outcome (found, incomplete, or couldn't be read), and an aggregate count
of extension "test connection" reachability pings. The league-lookup counts come from signed-in
sessions and count the lookup/preview step, not saved leagues; the reachability ping is
unauthenticated, so — like the page-activity pings — a refresh or bot can inflate it. All are
plain counts with nothing about you attached; they tell us whether onboarding is working.
- Where visits come from, and coarse device / browser — for anonymous
landing-page views we keep aggregate counts of the broad source a visit came
from (for example a search engine, a social site, or "direct"), derived from the referring
site's host — we never keep the full referring web address or any search terms
in it — together with a coarse device class (desktop / mobile / tablet) and
browser family (Chrome, Safari, and so on). Those last two are derived from your
browser's user-agent, which our server reads once, in the moment, and
then discards: we do not store the raw user-agent, we do not build a
device fingerprint, and we do not join any of this to your session id, visitor id, or account.
We do not read or store your IP address for these analytics, and we do
not collect your country or location. If the landing URL carries a
utm_source label (typically from a campaign link, though anyone can put one in a URL,
so it is unverified), we keep a bounded, sanitized copy of it. Like the other landing counts
these are best-effort and can be inflated by a refresh or bot, so they tell us how visits arrive,
not who or how many people.
AI-generated explanations (optional)
Some hosted war-room features use an AI provider (Anthropic) to put the engine's
reasoning into plain English. The recommendation itself is always made by our own deterministic
engine, not the AI. These features only run when the hosted service is configured for them; if it is
not, nothing is sent to any AI provider. Two paths use it:
- The automatic one-line "why." Next to a recommendation, the service sends a
curated, allow-listed set of decision facts for the current player — projections,
your roster needs, and the market math the engine used — to phrase a single sentence. This
projection is structured to exclude your account identity and other managers' or
league display names, so that identity data is not sent.
- The interactive advisor (only when you ask it). If you open the advisor to argue
a case for a player, the text you type is sent to the AI provider along with the
target bid and the same curated facts, so it can weigh your argument. Because this is free text,
treat it like any message to an AI service: don't type anything into it you wouldn't want
sent to the AI provider.
What we never do
- We do not sell or rent your data.
- We do not use it for advertising or to build advertising profiles.
- We do not use third-party analytics (such as Google Analytics) or tracking
cookies — usage analytics are first-party and aggregate: counts, plus one-way de-duplication
digests we can't reverse, never the raw identifiers (see above).
- We do not transfer it to third parties except the receiver the extension
forwards your draft data to and — only for the optional AI explanation features described above —
the data those features send to our AI provider (the curated decision facts, plus the text you type
if you use the interactive advisor).
- We do not use it for any purpose unrelated to the single purpose stated above
(consistent with the Chrome Web Store Limited Use requirements).
Affiliation and trademarks
AlphaDraft is an independent tool compatible with ESPN Fantasy. It is
not affiliated with, endorsed by, or sponsored by ESPN, The Walt Disney Company, or
the National Football League. "ESPN" is a trademark of its respective owner and is used here only
nominatively, to describe what the tool is compatible with — not to imply any partnership. The tool
reads the draft data shown in your own authenticated ESPN session, on your behalf; it does not
circumvent ESPN's access controls or speak for ESPN.
Changes
Material changes to this policy will be reflected here with an updated "Last updated" date.