BumbleBee
Security & privacy
BumbleBee holds your full résumé, address, phone, email and complete application history — and it reads attacker-controlled job-page content. So it is built to contain untrusted code and keep your data on your device. Here is exactly how.
The side panel — the surface that renders all your PII and runs the React UI and every npm dependency — is split across three frames. Only a tiny first-party Host touches privilege; the UI reaches it through a single, validated capability channel.
sidepanel.html — the Host page
Renders no UI. Owns chrome.*, the AES-GCM key, and
the one allowed dependency (Dexie/IndexedDB). It hands the sandbox
a single MessagePort and nothing else.
outer.html — the brokerAn opaque-origin frame with no dependencies. It whitelists which inner app may load and relays the capability port — it never touches the data flowing through it.
sidepanel-app.html — the UI
The React app and every npm dependency run
here, in an opaque origin with
no key, no database, no network and no
chrome.*. It can only invoke the closed capability set — and nothing
more.
A compromised dependency in the UI can request exactly the audited
operations (db, storage, messaging) brokered
over that port — it can never read your key, open your database, or
reach the network directly. Enforced in code and guarded by tests.
Six principles, enforced in code — every claim below is implemented and unit-tested.
The entire data-rich UI and every library run sandboxed; only a
minimal first-party Host touches chrome.*, storage
and the key — reached through a validated capability channel.
Résumé, employment history, address, phone, cover letters and your application log are AES-GCM encrypted — PII per-field, so only the needed value is ever decrypted.
The default level is Manual: autofill only. BumbleBee never clicks Next or Submit, and never attaches your résumé file, without an explicit confirmation.
The artifact sandbox is locked to
connect-src 'none' with
form-action 'none' and
object-src 'none' — no network, navigation or plugin
exfiltration path.
Hidden/invisible DOM is stripped before any model sees it, and prompts frame page text as untrusted data — never instructions.
There is no BumbleBee server. The only network calls are the model requests you trigger, made from the trusted background worker.
Grouped by area. ✅ implemented & tested.
The side panel runs as a trusted Host page that embeds a
zero-dependency broker, which in turn embeds the opaque-origin
React app. The app holds no key, no database and no
chrome.*; it reaches them only via a closed,
validated capability channel.
The artifact sandbox enforces connect-src 'none',
and img/font/media/worker/object are all
'none' too — closing every resource-load
exfiltration channel. WebRTC is nullified by the first on-load
script.
Every inbound runtime/postMessage is validated against a strict schema before the trusted layer acts — critical because it triggers real submissions of personal data.
Content scripts and the background worker import zero npm dependencies (guarded by tests). Form filling, clicking and DOM reading are 100% native browser APIs.
host_permissions are an explicit allow-list of
known job boards plus your chosen AI provider; new ATS origins
are granted per-board at runtime on a user gesture. The
cookies permission is never requested.
Banking, financial, healthcare, government and auth origins are blocked at the content-script level and re-checked at runtime — BumbleBee refuses to act there.
Name, email, phone and address are encrypted individually with AES-GCM (Web Crypto), so only the field a form needs is decrypted — never the whole profile as one blob.
Before any text reaches a model, BumbleBee removes
display:none, visibility:hidden,
aria-hidden, off-screen, zero-size,
<script>/<style> and zero-width
characters — a common prompt-injection vector.
A prompt-injected silent submit is impossible: the default level is autofill-only, and submission, file upload and screenshot capture each require an explicit human gesture.
Before filling, the target element is validated to match the expected field type (an email value only into an email field), preventing prompt-injection field remapping.
BumbleBee refuses to store or autofill SSN, passport or financial fields, surfacing them for you to complete manually.
A committed lockfile with npm ci and an
npm audit gate in CI fail the build on a tampered
dependency tree or a high/critical advisory.
BumbleBee is open about its trade-offs. The popup and résumé-editor pages remain non-sandboxed first-party extension pages today; the high-value side-panel surface is the one migrated behind the capability broker.