ChromeLock review: what does its password actually protect?

What protection do you actually get?

ChromeLock 3.28.5 can stop ordinary use of Chrome while its lock is running. Its password does not encrypt your saved Chrome profile. With browser debugging enabled beforehand, ChromeLock was removed while its lock was active; after restart, the extension was gone and the site was still signed in.

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 ChromeLock password. What can they open?

What happens when you lock and unlock Chrome?

ChromeLock can run this lock at startup, on demand or after you have been idle. That gives you more chances to put a password in front of Chrome. There is no separate companion app or file-encryption layer in this package, so the ChromeLock password is not required to open the saved profile if ChromeLock itself is disabled or removed.

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?

With browser debugging enabled beforehand, ChromeLock was removed while its password screen was active, without entering its password. After restarting the browser, the extension was gone and the site was still signed in.

Trying to reach Chrome's extension manager through ordinary foreground browsing was blocked. The successful removal used the already-enabled debugger to reach that manager, where Chrome's standard Remove dialog performed the removal.

Chrome can impose separate enterprise policy that prevents users from modifying an extension. That administrative boundary comes from Chrome management, not from the ChromeLock password.

What does the ChromeLock password protect if ChromeLock is not running?

Nothing extra in the saved Chrome profile. Chrome and the operating system do not use the ChromeLock 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 ChromeLock.

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 ChromeLock 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. ChromeLock 3.28.5 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 lock screen.

Will I still be signed in after unlocking?

The site stayed signed in after ChromeLock locked on startup and we entered the correct password. We returned to the same page without signing in again; its saved site data was still present.

What happens to open tabs? ChromeLock closes and reloads pages. It restores URLs and tab metadata, not live page memory or unsaved form contents. Restored windows are maximized instead of using their saved dimensions and position.

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 3.28.5

The following are additional weaknesses in this version.

The lock did not come back after its background process restarted

After we deliberately stopped and restarted ChromeLock's background process using debugging tools, the lock did not come back. New tabs that the active lock had closed before the stop stayed open afterward; in the repeat run, the saved browser state was readable without unlocking.

The code saves lock state, but that alone does not reinstall enforcement. Window and tab listeners and the cleanup interval are enabled by the lock/restore path. The browser-startup handler can restore that path; an ordinary worker restart is not a browser-startup event. The experiment shows that the stored locked flag did not guarantee active enforcement through this transition.

The first result used a deliberate debugging command to stop the background process. It does not establish a wait-only bypass, a fixed time-to-bypass or failure on every restart. Background-process restart is also different from disabling or uninstalling the extension.

How does that compare with the product description?

The Chrome Web Store description is technically incorrect on this point: hashing and encryption are different operations. Version 3.28.5 hashes the password with MD5; it does not encrypt the password.

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. A separate completed removal check used Chromium 144.0.7559.96 on Debian GNU/Linux 13 with ChromeLock installed under its production extension ID.

Each active-lock management case began with the Browser Locked window active. Foreground extension-management navigation was blocked. Debugger-assisted management reached Chrome controls without submitting the ChromeLock password; the completed removal run then used Chrome's standard Remove confirmation dialog.

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 disable/removal and after restart. These results concern those saved items rather than every possible browser store or account.

Vendor networking and real credentials were excluded. Debugger access is a stronger same-user capability than ordinary foreground browsing, and the article identifies it explicitly where the management result depends on it.

Package and evidence

The complete CRX was downloaded directly from Google's extension update service on September 19, 2026. It is byte-for-byte identical to the package used for the earlier article. Its manifest declares version 3.28.5. The package contains 98 files, including 22 JavaScript files.

All 22 JavaScript files were parsed for inspection. The review traced the manifest and HTML entry points, window capture and restoration, the storage helper, password setup and verification, the failed-attempt counter, recovery screens, background message dispatch and reset handlers. Bundled cryptographic functions were distinguished from functions actually called by the lock workflow. Network call sites and local-service references were checked for delegation of profile encryption or file access control.

case 3:
  return (
    (r = kt.default.hashPassword(e)),
    (t.next = 6),
    this.stateManager.savePasswordHash(r)
  );

case 6:
  return t.abrupt(
    "return",
    kt.default.verifyPassword(e, r),
  );

{
  key: "md5Hash",
  value: function (t) {
    return t ? o().MD5(t).toString() : "";
  },
},
{
  key: "verifyPassword",
  value: function (t, e) {
    return !(!t || !e) && this.md5Hash(t) === e;
  },
},
{
  key: "hashPassword",
  value: function (t) {
    if (!t || t.length < 1)
      throw new Error("Password cannot be empty");
    return this.md5Hash(t);
  },
},

if (
  s.destination.context === t &&
  !s.destination.frameId &&
  !s.destination.tabId
) {
  null == r || r(s);
  const { transactionId: e, messageID: n, messageType: c } = s,

(t) => {
  const e = nt(
      J(
        J({}, t.origin),
        "window" === t.origin.context && {
          context: "content-script",
        },
      ),
    ),
    r = ht.get(e),
    n = {
      message: t,
      to: yt,
      from: { endpointId: e, fingerprint: r.fingerprint },
    };
  mt(e).withFingerprint(r.fingerprint).aboutSuccessfulDelivery(n);
},

const r = i.get(n);
if ("function" != typeof r)
  throw (
    (o = !0),
    new Error(
      `[webext-bridge] No handler registered in '${t}' to accept messages with id '${n}'`,
    )
  );
e = await r({
  sender: s.origin,
  id: n,
  data: s.data,
  timestamp: s.timestamp,
});

case 0:
  return (
    (n = e.data),
    (o = n.password),
    (i = n.securityQuestion),
    (a = n.securityAnswer),
    (s = _e()),
    (t.next = 5),
    Promise.resolve().then(r.bind(r, 12006))
  );
case 5:
  return (
    (c = t.sent.default),
    (u = c.hashPassword(o)),
    (t.next = 9),
    s.stateManager.savePasswordHash(u)
  );