Can an embedded frame keep its own login?

When a page embeds content from a different website in a frame, browsers have become strict about letting that frame remember anything — that mechanism is what cross-site tracking was built on. This measures which ways still work in your browser.

Not run yet Press Run the test.

The four rows

Baseline: Two subdomains of one parent domain, so the browser sees one site. Should always pass.
Expected to fail: Genuinely different domains, ordinary cookie. Browsers are supposed to refuse this.
The row that matters: Same as above plus one word, Partitioned: the frame gets a private jar usable only while embedded here. This is the proposal.
Backup plan: Ordinary cookie, but the frame may ask permission. Browsers only consider the request if you have visited that site directly before, in a regular (non-private) window, and interacted with it within the last 30 days. The frame offers a link to do that. Costs the user a click, which is why it is the fallback rather than the plan.

What each frame reports

Login stuck: A value was stored, then checked to see whether the browser sent it back.
Images & files: Background content the frame loads needs the same login.
Live connection: Real-time features authenticate separately, over a persistent connection.
Extra permission: Normally no. A partitioned login works without asking — that is the point.

Notes

Rows two and three are the experiment. They differ by one word, so comparing them isolates exactly what that word does.
Blocked is not broken. What matters is whether row three is accepted.
Each row has its own domain — once a browser accepts a cookie for a domain it treats it differently afterwards, which would contaminate later rows.
Version beats brand. A failure usually means an old browser, not a hostile one.
Private window for rows 1–3, which want clean state. Regular window for the backup plan — browsers refuse storage access in private browsing, so that row can never pass there.

Raw results (for sharing)

No accounts, no personal data, nothing kept server-side. Each frame stores a random throwaway value and reports whether it came back.