Here is my wishlist with respect to browser profiles and containers. While the chances that I'll get them are low, I hope it inspires people to think bigger a b

Here is my wishlist with respect to browser profiles and containers. While the chances that I'll get them are low, I hope it inspires people to think bigger a bit more. It may be too hard on the current generation of web engines, but perhaps the next generation can plan better in advance. We're doing profiles and containers wrong. There are numerous other free software that demonstrate better examples. Why do we have two solutions when both are about isolation of data and execution? Browsers should take inspiration from how the Linux kernel does it using namespaces (and similar facilities in other kernels, eg: BSD jails). Divide isolation into different contexts like the different types of namespaces. There should be different contexts for isolating: - cookies policies and sharing - local data - extension availability and sharing - network access (direct internet, proxy, VPN, TOR, etc) - password stores - lifetime (permanent, limited-time, single-use) - web api availability (like no-js contexts, no-drm contexts, etc) - browser features - browsing history - sync accounts - bookmarks - tab configuration and state - theming - ad block profiles - website URL affinity (eg: don't open FB here, open YT only here, etc) - resource allocations (like CPU, RAM, etc) - redirection profiles (like to invidious, xitter, etc) Different profiles/containers can be created by mixing and matching these isolation contexts. For example you can have two different profiles that sharing password managers, but one for use with VPN and one without. All the current uses of profiles and containers can be met with this concept - including private browsing. You could even have TOR browsing in the same browser. While at it, you could even simulate resource allocations like cgroups (already mentioned in the list). All these might make you wonder if it isn't too complicated for ordinary people to use. Solutions for that exist in the OS space too. We have tools like docker, lxc and even bubblewrap to wrap over these low level complexities and present a simpler UI. In the browser, you could have different higher level plugins to setup profiles easily in specific manner. We can click 'private browsing' that will isolate a profile in every context by default (and offer to share anything else as it seems fit to you). You could have plugins that maintain different profiles for each of your gmail/workspace accounts. You could have a plugin that allows you to temporarily share OIDC SSO across profiles (currently an annoying problems with browser containers.) And finally, the power users may be able to script these low-level isolation contexts just the way they want it. The next is how pages are displayed. Today we have full-window pages with multiple pages supported by tabs. But those who use browsers for anything serious, besides watching cat videos or doom scrolling on social media know how frustrating it is to not be able to browse two pages side-by-side. Some browsers like Zen do support that workflow, while others can get it using extensions. But we could go much further. Dividing windows is a solved problem that's very well done in applications like Blender, Emacs, VSCode and other IDEs. You should be able to divide the window into any arbitrary layout, with each pane (a subdivision of a window) showing one of the open pages. Emacs shows this with the concept of windows (which are panes) and buffers. Blender gives the same facility. The browser must be able to hold hundreds of such layouts along with their page assignments. To make it easy for the common user, these layouts can be presented as tabs to the user. Web pages should also be presented as a single-pane layout for that page, so that the user is able to close it easily without having to think about the distinction between a page, a tab and a pane like the way you need to know on Emacs. Each page can be a different process with its own profile assignment and browsing history tree. The GUI should be a separate process. The amount of code shared between those processes should be based on security considerations. This way, we can have browser user profile, office profile, private browsing profile, developer profile and TOR profile all on the same window. But the window layout shouldn't stop there. Currently, the menu bars, tab bar/sidebar, toolbars, address bar etc consume too much space. Imagine if it was the same case for desktops? Desktops take only a tiny fraction of the screen space in the form of the status bar or the dock. Even that is optional in many cases and can be hidden when not in use. The best way to layout the pages on a window IMHO, is how the tiling window managers do it. Browsers like Firefox already treat the UI like HTML+CSS. But it's on a different plane from the page UI - so much so that you need to start the debugger console in a different mode to control it. But if the tabs, status bars and menu bars used the same layout as regular pages (but with special UI control privileges), you'll get numerous options to design it the way you prefer and hide them easily. To take it a bit further, I really like the concept of Wayland layer shells that allow you to make UI overlays. If you can make the controls into overlays, you could have per-pane controls like address bars and nav buttons that can be collapsed into small non-intrusive semitransparent UI buttons. This way, the UI can be truly full screen, easy to setup and easy to navigate. I know that this is a tall order to achieve. But it costs nothing to dream, I guess.