Privacy Policy

• Loopback only. The extension connects to your own desktop app over native messaging (preferred) or a loopback WebSocket at ws://127.0.0.1:<port> (fallback). It has no remote backend and contacts no third-party server. Its only host permission is 127.0.0.1 (loopback); it grants no access to any public or LAN address.
• Import this job sends the current tab's URL to the local app. The extension also captures the page's rendered DOM when possible (for logged-in boards that a headless server-side fetch cannot reach), and sends that HTML only to the local app. Nothing is captured in the background or on page load. Capture happens only when you click Import.
• Fill this form (assisted autofill: opt-in, off by default). If you turn on Assisted form autofill in the desktop app (Settings → Accounts → Browser extension), clicking Fill this form asks the desktop for your saved contact details (name, email, phone, location, LinkedIn/GitHub/website) over the same loopback connection and fills matching empty fields on the current page, then shows an in-page summary. Your details are your own data, come from your own paired desktop, are used only for that one fill, are never stored in the browser, and never leave your computer except into the page you chose to fill. It never submits the form for you. When the toggle is off, the desktop declines the request. This is why the extension collects no data and its Firefox data-collection declaration is ["none"].

• activeTab — read the URL and the DOM of the tab you clicked, only on that click. No standing access to any site.
• storage — store the pairing token locally so you only pair once.
• scripting — MV3 requires this to inject the DOM capture into the active tab on import click; its reach stays limited to the active tab.
• nativeMessaging — connect to the AI Job Hunter desktop host (app.aijobhunter.bridge) using the browser's native-messaging channel. This is the primary transport to the local app and is immune to Firefox HTTPS-Only Mode silently upgrading ws:// connections. Falls back to the loopback WebSocket if the native host is not registered.

No broad host access (<all_urls>), no tabs permission, no webRequest, no remotely-hosted code, no eval. Everything is bundled at build time.

The only value the extension persists is the pairing token — a one-time secret you copy from the app's Settings — kept in chrome.storage.local. It is used solely to authenticate to your local desktop app and is never sent to any remote server. No telemetry, no analytics, no external API.

When you run an AI feature (tailoring a résumé, analysing a job, writing a cover letter), the app sends the relevant résumé / job-posting / cover-letter text to the AI provider you choose and configure, authenticated with your own API key.

• Local models — Ollama runs models on your own machine (default; keyless, nothing leaves the computer).
• Cloud providers — OpenAI, Anthropic, Google Gemini, Ollama Cloud, and any OpenAI-compatible endpoint (LM Studio, OpenRouter, Groq, Together, DeepSeek, Azure, etc.) via a base URL you set.
• Local CLI agents — Claude Code, Codex, and the Gemini CLI, run as child processes under your own logged-in CLI.

When you pick a cloud provider, the content you generate over is sent to that provider and is governed by that provider's own privacy policy and terms — not by us. We are not a party to that exchange; the request goes straight from your machine to the provider you chose, under your key. If you stay on a local model (Ollama), that text never leaves your computer.

To rank job matches the app computes embeddings for your résumé and the postings. By default these are computed locally with Ollama (nomic-embed-text), so the text stays on your machine. If you explicitly configure a cloud provider for embeddings, the same "your text → your chosen provider, under your key" disclosure above applies.

To find and import jobs, the app makes outbound requests to the job boards you search. Most boards (e.g. Greenhouse, Lever, Ashby, Personio) are fetched over plain HTTP. LinkedIn job listings are also fetched over HTTP like the other boards; the only local-Chromium use is an optional login window that saves your LinkedIn session cookie to a per-board profile on your machine (to enrich authenticated searches) — not the scrape transport. The walled aggregator boards (Indeed, Glassdoor, StepStone, Xing, Workday) are reached via the Adzuna/JSearch aggregator API using your own API key — no browser required. Adzuna requests go directly to Adzuna's API. JSearch requests go through RapidAPI (the API gateway for JSearch) using your RapidAPI key. We run no proxy or intermediary; there is no AI Job Hunter server in the path. Adzuna, JSearch, and RapidAPI requests are subject to their respective terms of service and privacy policies.

LinkedIn via Apify (opt-in, off by default). Enabling the "Include LinkedIn (Apify)" toggle and providing an Apify token activates an additional source that sends a search request to Apify's API, which then queries public LinkedIn job listings on your behalf. Both conditions must be met: a token stored and the toggle on. This ensures the feature never runs silently (e.g. during a scheduled autopilot run). What leaves your machine: the search keywords, location, and date-range window, used to build a LinkedIn jobs search URL. No résumé, profile data, or other personal information is included; your Apify token travels in an authentication header only. Requests go directly to Apify's API. No AI Job Hunter server is in the path. Results are billed pay-per-result to your own Apify account. Apify requests are subject to Apify's terms of service and privacy policy.

Résumés, job and application history, embedding vectors, and settings are stored locally on your machine, in the operating system's standard per-application data directory. Secrets — AI provider API keys and saved board passwords — are kept in your operating system's keychain / credential store, never in plain-text files. None of this is uploaded anywhere by the app.