Idle CEF sends ListAccounts to accounts.google.com for every disk profile, and embedders cannot turn it off

[josefguenther]

Describe the bug

With no browser created and no page loaded, CEF sends a POST to https://accounts.google.com/ListAccounts?...&source=ChromiumBrowser about half a second after CefInitialize. It comes from the initial Default profile under root_cache_path. It is sent again the first time each request context with a disk cache_path is used, and that one carries the profile's google.com cookies if there are any.

It comes from IdentityManager::OnNetworkInitialized (components/signin/public/identity_manager/identity_manager.cc), which lists the Google accounts in the cookie jar for every regular profile once its network is up. CEF already disables browser sign-in, and Google does not allow sign-in from CEF-based browsers, so the answer is never used. For an embedder it's an unrequested request to Google, carrying the user's Google session cookies, sent whenever a profile loads.

We couldn't find a way to stop it:

• --allow-browser-signin=false has no effect.
• The sign-in preferences have no effect. A CEF profile already reads signin.allowed = false. Setting signin.allowed and signin.allowed_on_next_startup to false through CefRequestContext::SetPreference, or seeding them in the profile's Preferences file before the context opens, changes nothing on that launch or the next.
• Disabling features has no effect. We tried AvoidAutoTriggerListAccountsOnStale (enabled), plus EnableBoundSessionCredentials, FetchAccountInfoOnRestart, DiceHeaderVersion2, DiceLinkedAccounts, EnablePreferencesAccountStorage, EnableChromeRefreshTokenBinding, EnableOAuthMultiloginCookiesBinding and EnableAccountPreviewData (all disabled), then disabled in a single --disable-features every one of the 242 identifiers in the framework's strings that mention sign-in, accounts, GAIA, DICE, identity, OAuth, reconciliation or sync.
• The request never reaches CefRequestContextHandler or CefResourceRequestHandler, so it can't be cancelled there.
• --gaia-url pointed at a dead address only makes it retry, about 8 times over roughly 15 minutes, and it also redirects every other GAIA URL.

To Reproduce

1. Initialize CEF with windowless rendering, root_cache_path set, and cache_path empty. Create no browser.
2. Launch with --log-net-log=/tmp/net.json --net-log-capture-mode=IncludeSensitive.
3. Wait a few seconds and quit.
4. In the net log, the only request is POST accounts.google.com/ListAccounts. It carries no Cookie header, because the Default profile has none.
5. Create a CefRequestContext with cache_path set to a direct child of root_cache_path, open a browser on it, and repeat. A second ListAccounts appears when that profile loads. If the profile has google.com cookies, they're sent with it.

Expected behavior

No request to accounts.google.com unless a page navigates there. At a minimum, give embedders a setting or preference that turns off Google account reconciliation for a profile.

Versions

• OS: macOS 26.6.2 (Apple silicon, M2)
• CEF Version: 152.0.6+g708dc14+chromium-152.0.7977.83
• Compiler: Xcode 27.0, Apple clang 21.0.0

Additional context

Does the problem reproduce with the cefclient or cefsimple sample application at the same version?
Yes. I built cefsimple from the 152.0.6 binary distribution. The only change was setting root_cache_path to a fresh empty directory, so the test didn't touch the shared default location. With the net-log switches above, it sends the same ListAccounts POST about 0.25 to 0.5 s after startup, before its first page request. So it isn't specific to windowless rendering or to our app. Setting cache_path to a child of the root didn't stop the request, and a Default directory was still created under the root.

Does the problem reproduce with Google Chrome at the same version?
Chrome sends this request by design, because it keeps browser sign-in in step with Google web sign-in. The issue is only that CEF, where sign-in is disabled, still does it.

[magreenblatt]

The request has multiple triggers (code references at M154):

• IdentityManager::OnNetworkInitialized() (components/signin/public/identity_manager/identity_manager.cc:458) initiates the
  startup fetch.

• GaiaCookieManagerService::OnCookieChange() (components/signin/internal/identity_manager/gaia_cookie_manager_service.cc:636)
  initiates subsequent fetches when Google cookies change.

• Callers querying stale account information can also initiate a fetch.

These converge on TriggerListAccounts().

The recommended minimum change is:

1. In components/signin/internal/identity_manager/gaia_cookie_manager_service.cc:527, include cef/libcef/features/features.h and
   add this before enqueueing anything:

     void GaiaCookieManagerService::TriggerListAccounts() {
     #if BUILDFLAG(ENABLE_CEF)
       return;
     #endif
       // Existing implementation...
     }

2. Add "//cef/libcef/features:buildflags" to the identity_manager target’s dependencies in components/signin/internal/
   identity_manager/BUILD.gn:65.

This prevents startup, cookie-change, explicit refresh, and subsequent retry requests through this service. The other
CreateListAccountsRequest() occurrence only repositions an already-enqueued request. Guarding here also avoids leaving a pending
request stranded, which would happen if the fetch-start method simply returned.

[magreenblatt]

A better dynamic option might be checking the existing prefs::kSigninAllowed preference in TriggerListAccounts.

• --allow-browser-signin → prefs::kSigninAllowed: Allows the browser profile to have a Google identity and enables desktop account consistency (DICE).
• ListAccounts and cookie observation: Discover which Google accounts are signed into websites in that profile, so Chromium can reconcile those website sessions with browser-held accounts and tokens.

Website sign-in itself does not require this background discovery. Gmail, for example, uses its own requests and cookies.

When kSigninAllowed is true, this functionality should remain enabled for the browser identity system to operate correctly. In desktop Chromium, that preference selects DICE; normal reconciliation then consumes the cookie-account list and, when it is stale, waits for an update. Suppressing discovery independently can leave reconciliation unable to complete normally. See account consistency selection (chrome/browser/signin/account_consistency_mode_manager.cc:98) and reconciliation (components/signin/core/browser/account_reconcilor.cc:442).

That does not mean every idle profile needs the startup request merely because sign-in is permitted. It means the enabled identity subsystem depends on this capability, including before a primary browser account exists.

When kSigninAllowed is false, Chromium disables DICE, but the lower-level cookie-discovery service continues running independently. That separation explains the CEF requests.

For CEF, this supports using kSigninAllowed as the gate. It preserves discovery when browser identity is enabled and suppresses it when that functionality is disabled. This uses the existing launch-time sign-in configuration; it does not make live toggling safe, because Chromium fixes the account-consistency mode for the profile’s lifetime.

The minimal proposed change at the beginning of TriggerListAccounts() would be:

  if (!signin_client_->GetPrefs()->GetBoolean(prefs::kSigninAllowed)) {
    return;
  }

[magreenblatt]

There is a Chromium callback with the right timing for changing prefs::kSigninAllowed, but it is explicitly a testing API. I found no equivalent production CEF callback exposing a usable Profile at that point.

• ProfileManagerObserver::OnProfileCreationStarted: Too early: ProfileImpl has not loaded/created its preferences yet.
• BrowserContextDependencyManager::RegisterCreateServicesCallbackForTesting: Right timing: preferences exist, profile services have not been created.
• CreateProfileAsync’s “created” callback: Too late: the account-consistency service already exists.
• CEF SetInitialProfilePrefs / OnRequestContextInitialized: Too late for account-consistency initialization.

The testing callback (components/keyed_service/content/browser_context_dependency_manager.cc:35) runs immediately before service creation. It would technically provide the hook, but we should avoid using a testing API in production CEF.

There is also a crucial distinction: an early write should target kSigninAllowedOnNextStartup, not kSigninAllowed. An embedder can change kSigninAllowedOnNextStartup ("signin.allowed_on_next_startup") through SetPreference; it takes effect on the next profile load. They should not change kSigninAllowed ("signin.allowed") directly. Chromium derives it during initialization, and changing it afterward can violate the cached account-consistency mode and trigger a CHECK failure.

The practical default change location would be in AccountConsistencyModeManager::RegisterProfilePrefs (chrome/browser/signin/account_consistency_mode_manager.cc:147), where Chromium currently registers it as true:

  registry->RegisterBooleanPref(
      prefs::kSigninAllowedOnNextStartup,
      !BUILDFLAG(ENABLE_CEF));

If we wanted to expose this configuration timing/location more generally we could change the timing of the existing CefBrowserProcessHandler::OnRegisterCustomPreferences callback (or add a new callback) that triggers after RegisterProfilePrefsForServices and before CreateBrowserContextServices (in ProfileImpl::OnSyncToSigninMigrationMaybeCompleted).

The main changes would be:

• Remove the CEF registration call from Chromium’s RegisterUserProfilePrefs().
• Add it at the end of RegisterProfilePrefs() in pref_service_builder_utils.cc (chrome/browser/profiles/pref_service_builder_utils.cc:66), after both dependency managers register their preferences.

[magreenblatt]

In summary, we make the following Chromium changes:

1. At the beginning of TriggerListAccounts() (components/signin/internal/identity_manager/gaia_cookie_manager_service.cc:527), to disable the Google requests:

  if (!signin_client_->GetPrefs()->GetBoolean(prefs::kSigninAllowed)) {
    return;
  }

2. In AccountConsistencyModeManager::RegisterProfilePrefs (chrome/browser/signin/account_consistency_mode_manager.cc:147), to change the default value of prefs::kSigninAllowedOnNextStartup to false for CEF:

  registry->RegisterBooleanPref(
      prefs::kSigninAllowedOnNextStartup,
      !BUILDFLAG(ENABLE_CEF));

And implement issue #4281 to support user configuration of kSigninAllowedOnNextStartup ("signin.allowed_on_next_startup") on newly-created CefRequestContexts (Profiles) via the newly added CefPreferenceRegistrar::SetDefaultPreference.