Adam Kershner

Oasis Browser: Import bookmarks, passwords, history, and autofill data from other browser

Hey Product Hunt community

We’ve been getting great questions from early testers and people considering Oasis as their daily browser. One keeps coming up after every iteration, and it’s exactly the right question to ask:

You talk about history, bookmarks, and semantic search staying on-device while the assistant runs on cloud models. When onboarding says I can pull passwords over from my old browser — where do those actually land? How are they encrypted? And is the vault fully walled off from anything that could train or power the assistant? @ferdi_sigona

We want to answer that plainly, without hand-waving. If you’re evaluating Oasis (or any AI browser), this is the thread we wish existed before we shipped.

The split we’re building around

Oasis is trying to do two different jobs and keep them separate:

  1. Your browser — browsing, bookmarks, history, saved logins, extensions. Most of this is local-first, inherited from Firefox.

  2. Your assistant — chat, tab/bookmark/history search, page summaries, voice. That layer uses remote LLMs when you invoke it, plus optional product-improvement logging you control in settings.

Those are related in the product, but not the same data pipeline. Passwords belong in the first bucket, not the second.

Where imported passwords go

When you import from another browser (Chrome, Safari, Edge, etc.), passwords don’t go to our servers or into “assistant memory.” They go into Firefox’s Login Manager — the same encrypted vault Firefox has used for years.

Concretely:

What

Where it lives

Saved site logins

On your device — Firefox Login Manager (logins.json + crypto keys in your profile)

Browsing history & bookmarks

On your device — Firefox Places

Assistant searchable memory / semantic history

On your device — local IndexedDB + on-device embeddings

Assistant chat UI state

On your device — IndexedDB

LLM replies when you use the assistant

Cloud — when you send a message

So when we say history and semantic indexes stay local, imported passwords follow the Firefox vault path, not the assistant index path.

How they’re encrypted

At rest, usernames and passwords in logins.json are not stored in plaintext. They’re encrypted through Firefox’s NSS / Login Manager crypto stack, with key material in your profile (often integrated with the OS keychain on macOS and Windows where supported). You can also set a Primary Password for an extra unlock step.

We didn’t invent a parallel “Oasis password cloud.” If it’s a saved login from import or autofill, it’s in the same on-device vault as Firefox.

Is the vault walled off from the assistant?

For vault contents: yes, by architecture.

  • The Oasis Assistant exposes dozens of browser tools (tabs, groups, bookmarks, history search, page summarize, etc.). There is no “list my passwords,” “export logins,” or vault-read tool in that set.

  • Product-improvement telemetry (anonymous by default) is scoped to assistant interactions — prompts, replies, active tab URL/title when you’re using the assistant, tool summaries — not a bulk export of your password database.

  • Local semantic search and memory indexing are built around history, bookmarks, tabs, and groups — not saved logins.

That does not mean “nothing sensitive ever touches the cloud.” It means the password vault is a separate subsystem from the assistant’s context pipeline.

Here’s the honest boundary table:

Scenario

Vault

Assistant / cloud

Passwords you imported from Chrome/Safari/etc.

On-device, encrypted

Not exposed via assistant tools

You ask the assistant a normal question

Prompt + reply go to the remote model

You use summarize this page

Vault not opened

Visible page text (excerpt) can be sent to the model — e.g. if a password is on-screen, not pulled from the vault

You paste a password into chat

Treated like any other message (cloud + optional logging)

Oasis account sign-in

We store session tokens in Login Manager under our auth host (same technology, different purpose than your site passwords)

Needed for signed-in assistant features

So: we don’t feed your imported password vault into assistant training or semantic memory. If you voluntarily put secrets into chat, or a page visibly shows them, that’s a different path — and we think you should know that.

Onboarding copy vs. what ships today

Our welcome flow includes an option described as importing cookies and login data (saved passwords, stay signed in). We’re being transparent here: that screen records your choices as preferencesfull automatic migration from the welcome UI is still being wired up.

Today, password import runs through Firefox’s standard Migration Wizard (Settings → import, or the flows in about:logins) — same engine, same vault, same encryption.

We’d rather you hear that from us than discover it. If import-from-welcome is important to you, tell us — it’s active feedback we’re tracking.

What we’re not claiming

  • Not “zero data” when you use the assistant — cloud models need your prompts (and sometimes page/tab context).

  • Not “anonymous mode sends nothing” — default anonymous logging means not linked to your account, not “nothing leaves the device.”

  • Not “the assistant can never see anything sensitive” — it can see what you send it and what’s extractable from an open page when you use page-grounded tools.

We are claiming: saved passwords from import live in Firefox’s encrypted on-device vault, outside assistant memory and outside vault-read tools — and that’s the bar we hold ourselves to.

Your controls

  • Privacy & Security → Oasis Data Collection and Use — anonymous assistant logging by default; optional account-linked personalization if you opt in.

  • Firefox password settings — Primary Password, saved logins management, import/export via standard Firefox UI.

  • Don’t paste secrets into chat — same rule as any AI product.

More detail (for the curious): our internal docs distinguish browser privacy (ETP, cookies) from assistant telemetry — two different systems, two different toggles.

Why we posted this here

Product Hunt folks tend to ask the hard question first: “Where do my passwords go?” We respect that. Oasis is an AI browser, not a password manager — and we don’t want ambiguity on the one surface people scrutinize most when switching browsers.

If you’re testing Oasis:

  • What would proof look like to you — architecture doc, settings screenshot tour, independent review?

  • Did you import passwords from another browser — how did the flow feel?

  • Anything in the table above that still feels fuzzy?

Drop a comment. We read these threads and use them to prioritize both product and copy (including making the onboarding → migration path impossible to miss).

Thanks for pushing us on this. It’s the right question.

— The Oasis team

Doc: https://kahana.co/docs/import-opt-out
Related: https://kahana.co/docs/onboarding-checklist-assistant-panel | https://kahana.co/docs/oasis-welcome-not-firefox-about-welcome

Questions we would love your take on:

  1. Clean start vs import
    Did you skip import on purpose? What would have made “fresh start” the obvious default?

  2. What to import
    If you did import, what mattered most: bookmarks, history, passwords (if offered), or nothing?

  3. Nudging
    After you opt out, should Oasis ever suggest import again, or stay silent unless you open Settings?

  4. Privacy framing
    For a privacy-first browser, does importing Chrome history feel wrong? How should we explain the tradeoff?

  5. For the Oasis team
    Was the skip path easy to find in the onboarding checklist?

Share how you onboarded. It helps us tune first-run flow.

28 views

Add a comment

Replies

Be the first to comment