Part 1 was about a capability extensions visibly lack. This one is quieter. Nothing fails, nothing prompts, nobody notices anything. Chrome sync just does its job, and its job is moving browser state off the machine.

What sync actually carries

Sync is not one stream, it is a set of typed channels: bookmarks, history, open tabs, passwords, autofill including addresses and payment cards, extensions, settings, and a handful of smaller types. Sign into Chrome with any Google account and every enabled type starts flowing to that account. Encrypted to Google by default, end to end only if the user sets a passphrase, which almost nobody does.

Now picture the standard mixed setup: a corporate machine, a managed work profile, and an employee who signs a personal Gmail into that profile, or just uses the personal profile sitting one click away in the profile switcher. The passwords saved against internal apps, the history of every internal hostname, the open tabs with ticket numbers in their titles, all of it syncs up to the personal account and back down to a personal laptop at home. No upload event, no file, nothing a DLP rule would classify as exfiltration. The traffic is TLS to google.com, which every allowlist on earth permits.

The policies, item by item

Chrome Enterprise has real controls here, and they are narrower than people assume.

  • SyncDisabled kills sync for the profiles it reaches. Total and blunt, and users notice their bookmarks stopped following them.
  • SyncTypesListDisabled turns off individual types. Most teams disable passwords and autofill, keep bookmarks, and call it scoped.
  • BrowserSignin can block browser sign-in entirely, or force it so the profile is always managed.
  • RestrictSigninToPattern is the precise one: a pattern over which accounts may sign in, usually anchored to the corporate domain.

The catch is scope. A policy attaches to whatever is managed: the device, the browser install, or the account. Applied at the machine or browser level, RestrictSigninToPattern does reach every profile on that install, and that is the strict setup. Applied through the managed account, it governs that account's profile and says nothing about the personal profile next to it. BYOD, unmanaged home installs of the same browser, and half-enrolled fleets fall through exactly this gap. The data follows the account, and the account is the one thing MDM does not own.

Where the extension sits

Below all of it. There is no extensions API for sync. An extension can read bookmarks and history, but it cannot tell synced from local, cannot see the sync queue, and cannot observe a personal account attaching itself to the profile. Extension-based DLP does not have a degraded view of this channel. It has none.

Closing it for real

Strict policy gets you most of the way if you are willing to pay for it: force managed sign-in, restrict the pattern at the browser level, disable secondary profiles, accept the tickets. In our fork we went one layer further, because we could reach the layer policy cannot: the sync client itself. The browser knows which profile is corporate, so it can refuse to start typed channels for the wrong account, log what would have left, and leave personal Chrome on the same machine alone. That is not cleverness, it is just owning the code that runs.

Part 3 needs no account and no API gap at all, only a keyboard shortcut: the incognito window.