That's not a bug, that's the point.

"Single sign on" means "contact centralised provider with identifying information plus site browsed".

The explicit desire here is to stop that tracking.

Tracking _is_ single sign on with the "sign on" being invisible to the user.

You're thinking of consumer SSO. There's also enterprise SSO. Per-tab cookie isolation would break pretty much every bigcorp's Intranet, because they're composed of a bunch of different services that all rely on a centralized IAM provider.

(Mind you, Google themselves are working to move enterprises away from this model, with their https://cloud.google.com/beyondcorp/ effort avoiding the "Intranet as a bunch of services on separate internal domains" model, in favor of a "Intranet as a bunch of services all living under smart proxies that make them look like one domain and handle IAM for you" model. But enterprises would need to move first, before complete tab isolation could be workable for them.)

There's also even-more-enterprise SSO, i.e. SAML and its "using your bank as an SSO provider to prove your identity to government services" use-cases. This actually isn't SSO at all—there are more identity providers than there are services. The point here is to federate proofs-of-identity by allowing many different (whitelisted) agencies to vouch for your identity, so that the government doesn't need to issue you some centralized proof-of-identity. This would also break under complete tab isolation, and I don't think there's any good replacement in this case.

this is an ideal example of "you know you need this, whitelist it" vs "this is always allowed". sites will definitely start messaging "whitelist or follow link from X" if default-block becomes popular, so I don't really think it'll break anything, tho it might be a bit more annoying.

(personally I get a small hit of joy every time I hit a site that is caught and blocked trying to do things it shouldn't, and vow never to return. it's better than it happening without knowing.)

Not at all, it's the exact same thing in that case as well, it's just that you _want_ the tracking.

If you don't want every tab to be connected, every tab isn't connected.

How do you suggest enabling these use-cases for users that want them, on top of a browser that isolates tabs by default, without requiring any technical aptitude of the user to understand what a "cookie" is (which would normally suggest "have a UX flow for it") but while preventing arbitrary websites from triggering such a flow and thereby tricking these non-technical users into enabling the site to track them?

It's not like the problem is impossible; nobody is saying that. My point is that the solution is non-obvious to the point that nobody has solved it yet, despite likely man-years being put into trying. Firefox Containers are the best UX we've come up with so far to kinda-sorta solve the problem. Do you have any better idea?

Easy: take the original comment literally and make the interface like Tree Style Tabs [0].

[0] https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...

Let’s break it and have the browser handle auth flow itself.

But then you have state shared between tabs and that breaks OPs whole idea, because it kills the sandboxing.

See BrowserID. It’s based on cryptographic proof and would work with any backend, including offline.

What about have the consumers sign on to the SSO provider at the root node?

I had the same issue with the Facebook container tab on Firefox as well.