I think, and always thought of it as intuitive with the way I use browsers, that sessions should work as a tree. So only child tabs in that tree should see the contents of parent's session. If I open a new tab, it's a new tree. Bookmarks could create permanent root node.
But I never got around to polishing it and making it more accessible.
The thing that really prompted me was peeking at what financial websites were doing, trying to connect to data mining sites like ru4.com and refusing to load if they couldn't connect to facebook.com and twitter.com.
My script also fixes paths in profile folders so that the roboforms extension will still work, because it is the only password manager that I have found that is able to completely automate my logins, despite the best efforts of UX designers.
I also couldn't order food from seamless.com unless I allowed a script on their site to connect to facebook.com. So, now seamless.com gets its own empty sandbox.
And because you're using your filesystem to store a browser profile, you can have specific extensions or settings for each profile.
So whenever I want to do financial stuff, it just connects over an autossh tunnel to my home, so it will never trigger any any stupid re-authentications when I'm connecting from a cellphone or work.
That's awesome, thanks. I've tried the Tree Style Tabs in the past, it made a lot of sense to me, but unfortunately I had other issues with FF back then. Now with the containers support there's more incentive to try it again.
The problem with this (and the reason browsers don't already do things this way) is that it breaks Single Sign-On flows like OAuth.
When your browser redirects a tab from example.com to accounts.google.com to do an OAuth login, the Google OAuth login cookie that gets set by accounts.google.com under that tab, needs to also be visible later on to any other tab whose "root node" navigates to accounts.google.com.
Maybe you can make an exception for just SSO providers—but won't other nefarious uses (e.g. analytics providers) then just pretend to be SSO flows?
And maybe you can just whitelist the existing SSO providers—but that's an instant oligopoly.
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.)
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?
If I understand you correctly, Safari does this on both iOS and macOS.
If you click a link that opens a new tab and swipe back from that new tab, Safari closes the new tab and shows you the previous tab.
I’m not exactly sure of the behavior when you open a new tab, then go to another tab, then back to the tab that was opened and then swipe back, though.
Safari for iOS has kind of a "grace period" where the back gestures do work from the new tab. But I think this is more to aid the confusion for people who don't understand that a new tab has even been created.
If you switch tabs, or close the app, or do anything other than somewhat immediately go back, that back history is lost. And if you do use the shortcut to go back, the new tab is destroyed. There's no ability to open a bunch of tabs and then in each of them independently navigate back to the parent.
People who are aware of how pervasive tracking is wouldn't mind much indeed. The average user would be _infuriated_ of having to login every time they open a tab.
That's where LastPass, et. al. come to the rescue. Minimizes the annoyance of multiple logins, while increasing overall security if they didn't already use a password manager.
There's only so long that all those angry, multi-tabbing, somehow-simultaneously-both-ignorant-and-power users will be infuriated at every single website before they forget it ever wasn't like that.
From a UX perspective, that sounds confusing to me. How do you know which subtree from 2 weeks ago each tab is from? It might be an alright tradeoff for 'power' users though