Isolation boundaries between coexisting accounts must be explicit

What it is

When several accounts are signed in on one device, people need to know what is separate and what is shared on purpose: content and drafts apart, whether they share a download folder, search history, payment methods, device-level biometrics. Explicit isolation boundaries means those rules sit in the switcher or account copy, and the implementation matches. This entry is policy visibility. It is not whether the foreground is cleaned at the instant of switch, and not whether notifications print an account name.

Why it happens

“Multiple accounts” is understood as several fully separate houses; engineering often shares a download folder, logs, an advertising id, a push certificate. Undeclared sharing reads as a cross-account bug; undeclared isolation makes people think an invoice just downloaded is visible in the other account. Payment methods visible across accounts turn a family device into cross-charging. Biometrics that unlock the device rather than the account will, after a switch, unlock the wrong one. Boundaries must be listed by object type; “data is isolated” cannot be checked. Exceptions (device-level dark mode) should be named as device settings so account preferences are not read as isolation failures.

Studying it

List object types (files, search, payments, messages, theme); ask people to predict what remains visible after a switch; compare to the implementation.

Independent variables: whether an explanation exists, which types are actually bucketed, whether device-level settings are labeled. Dependent variables: match between prediction and implementation, failing to find a file because they assumed sharing, seeing payment methods in the wrong account because they assumed isolation.

Do not only test whether messages are separate—sharing often lives in files and payments. Labs should use two real accounts, not two test prefixes, to surface implicit sharing such as address-book matching.

Where it stops holding

OS-forced sharing (one app’s disk quota, one push certificate) belongs in the copy; do not pretend it can be turned off. An enterprise account may forbid sitting beside a personal account on the same device; the boundary is “cannot coexist,” not how to isolate when they do. Browser profiles and in-app multi-account are two models; do not reuse one paragraph. Intentional cross-account acts (“like this work post as your personal account”) must be explicit actions, not silent shared cookies.

Applying it

• In the switcher or help, a table: messages, files, search, payments, sign-in sessions, device appearance—each “separate per account” or “shared on this device.”
• Implementation shares a source with the table; new object types are classified before they ship.
• If device-level biometrics unlock whichever account is in the foreground, say so; if each account must hold its own token, do not reuse one device unlock for every account.
• Verify: people uninvolved in the design, without acting, predict visibility of five object types after a switch, against the table and the implementation. Download an invoice visible only to A; after switching to B it must not open from a shared downloads list under A’s filename. B must not see A’s payment methods unless the table declares sharing and consent was given at add time.

Related

• Within the group: H6.13.1 Account switching must show which identity is current · H6.13.2 Switching must not leave the previous account's sensitive state · H6.13.3 Notifications must name the source account
• Adjacent: H6.05 Biometrics · H8.08 Sharing scope and permission settings
• Search terms: account isolation · profile boundary · multi-account storage