Browser Lock review: does it password-protect your Chrome profile?

What does its password protect?

Browser Lock 2.0.4 can stop ordinary use of Chrome while its lock is running. Its password does not encrypt your saved Chrome profile. Reopening the same profile with extensions disabled bypassed the lock: Browser Lock did not run, and the site was still signed in without entering its password.

Who are you protecting the browser from?

Someone else sits down at your computer while you are still signed in to it. They do not know the Browser Lock password. What can they open?

What the password actually controls

When you lock Chrome, Browser Lock saves a list of open tabs, closes the browsing windows and opens its password screen. After the correct password, it opens the saved pages again. It does not encrypt your Chrome profile during that process.

Browser Lock can lock at startup, from a shortcut or menu, and after a configured idle period. Those options help when you step away from an unlocked browser. They do not make the Browser Lock password necessary for opening the saved Chrome profile if Browser Lock itself is not running.

The technical storage and window-control details are in the evidence section.

Does it keep the locked browser out of sight?

No. The password screen remains visible. It blocks the pages from ordinary view, but it does not hide that Chrome is locked.

A visible lock and keeping a private space out of sight are separate requirements.

What happens if the extension is disabled or removed?

Reopening the same profile with extensions disabled bypassed Browser Lock without entering its password. Browser Lock did not run, and the site was still signed in. Separately, with browser debugging already enabled, Chrome removed Browser Lock while its lock screen was active; after restart, the extension was gone and the site was still signed in.

A normal attempt to open Chrome's extension manager while Browser Lock was active was blocked. The successful removal run used the already-enabled debugger to reach Chrome's extension-management page, then Chrome's standard Remove dialog performed the removal.

Chrome can impose separate enterprise policy that prevents users from disabling or removing extensions. That administrative boundary comes from Chrome management, not from the Browser Lock password.

What does the Browser Lock password protect if Browser Lock is not running?

Nothing extra in the saved Chrome profile. Chrome and the operating system do not use the Browser Lock password when opening Chrome's saved data. Chrome and the OS may still protect particular secrets in their own ways, but those protections do not come from Browser Lock.

For example, Chrome introduced App-Bound Encryption on Windows beginning with cookies in Chrome 127. The absence of an additional extension layer does not mean every browser secret is plain text, or that a copied cookie or password database can necessarily be decrypted or reused.

Would fixing every bug make its password protect the saved profile?

No—not by fixing the password screen alone. Fixes can make the lock more reliable, but protecting the saved profile after Browser Lock stops requires a separate mechanism that protects the data itself.

An extension can be part of a larger system that protects browser data with a separate native app or encryption layer. Browser Lock 2.0.4 does not do that here: it controls Chrome windows and tabs. Making its password protect the saved profile would require a different data-protection layer, not just a better password screen.

Will I still be signed in after unlocking?

The site stayed signed in after locking and unlocking. Entering the correct password let us return to it without signing in again. Its saved site data was still present.

What happens to open tabs? Browser Lock reopens saved URLs, pinned tabs and tab groups in maximized windows. Pages load again rather than returning from live page memory, so unsaved form state is not part of the extension snapshot.

Check the settings for deleting data after wrong passwords. Browser Lock calls this Quarantine. Those deletion options were off during the sign-in check; turning them on can change what remains afterward. See the data-deletion finding.

Need to keep your accounts signed in on a shared computer?

If you need to keep accounts signed in while keeping other people out, compare browser-protection options for a shared computer.

If the space itself must stay out of ordinary view, see locking a profile versus hiding its existence.

Other weaknesses in version 2.0.4

The following are additional weaknesses in this version.

if (
  zm.SHA256(w).toString() !==
  ((x = e.security.browser_password) == null ? void 0 : x.password)
) {
  (y(n("popup.password_wrong")), m(""), t());
  return;
} else
  (o(qr.actions.clearQuarantine()),
    ab
      .unlockTheBrowser()

if (d.status) {
  const g = zm
    .SHA256(u.values.password_section.new_password)
    .toString();
  (s(
    qr.actions.updateSecurity({
      browser_password: {
        password: g,
        length: u.values.password_section.new_password,
        changed_at: Fn().unix(),
      },
    }),
  ),

updateSecurity: (e, t) => {
  const n = { ...e, security: { ...e.security, ...t.payload } };
  return (chrome.storage.local.set({ mainStorage: JSON.stringify(n) }), n);
},

Worker restart retained the lock state

Browser Lock keeps lock state and its tab snapshot in chrome.storage.session; its tab handler reloads that state before deciding whether to close a new tab. This avoids relying solely on worker-global variables, which disappear when a worker stops.

In the completed toolbar-lock run, an explicit CDP worker stop and restart preserved the locked state and enforcement. The worker received a new target ID, the new tab was closed, and a later attempt after the transition had settled was closed too. This run did not reproduce a persistent worker-stop bypass. It is not a guarantee about every timing, startup or crash scenario.

Session storage survives worker suspension but is cleared on extension disable, reload, update or browser restart. Correctly resuming the lock after worker suspension improves the browsing barrier; it does not make the extension password an independent requirement for accessing profile contents.

Runtime validation

The security-boundary experiments used a non-administrator Windows profile in Chrome for Testing 153.0.8010.52 with the distributed package loaded unpacked and its executable code unchanged. Separate September 25 management checks used Chromium 144.0.7559.96 on Debian GNU/Linux 13 with the production extension ID.

Each active-lock management case began with Browser Lock visibly locked. Foreground management navigation was blocked. Debugger-assisted management reached Chrome controls without submitting the extension password. The separate same-profile relaunch used Chromium's --disable-extensions option and required no debugger interaction with the lock.

The saved profile state consisted of a persistent cookie, a localStorage value and, in the Windows checks, a seeded history entry. It remained readable after the relevant disable/removal paths and after restart. These results concern those saved items; they are not a claim that every browser store or account uses the same persistence mechanism.

Vendor networking and real credentials were excluded from the experiments. Debugger-assisted removal and the command-line relaunch represent stronger same-user capabilities than ordinary foreground browsing; the article labels those capabilities where they matter.

Package and evidence

All nine JavaScript files were parsed. The review traces the manifest and module imports, locking and restoration, local and session storage, password setup and comparison, recovery, quarantine and network destinations. The 44-file package also contains a nested CRX; its nine JavaScript files are byte-for-byte identical to the outer files, and no entry point loads that archive.

const { windows: n, tabs: r } = await bo.getOpenedTabs(),
  i = await Ar.open();
(s === "init" && (Pe.sessionStorage.lock.initial_locked = !0),
  (Pe.sessionStorage.lock = {
    ...Pe.sessionStorage.lock,
    auto_locked: !0,
    open_after: ["https://x.com"],
    locked: !0,
    locked_at: vn().unix(),
    locked_reason: s,
    stored_windows: n,
    popup: i,
  }),
  Pe.save(),
  await bo.closeTabs(r),
  await bo.closeWindows(n));

save: () =>
  new Promise((s, n) => {
    chrome.storage.session
      .set({ sessionStorage: JSON.stringify(Pe.sessionStorage) })
      .then(() => s(!0))
      .catch((r) => n(r));
  }),