I think the main issue here is people conflate the security boundaries defined by the website operators with the security or privacy boundaries a user might want to enforce. The web origin chosen for the service operator's XSS sandbox is not necessarily what a privacy-focused user wants. It's only useful when a trustworthy operator is designing for the benefit of the user.
There should really be a more granular way for the user's policy to adjust the origin definitions used for cross-origin logic as well as other types of content blocking and enforcement.
Why shouldn't they be able to grant any permission to be used in a single page https://example.com/app1/usefulpage and not in other pages on the site?
The multi-container approach to browser session isolation faces the same issues. Different users may have different preferences for when navigation shares the session and when navigation should kick you into a new session that lacks authentication, tracking, or app state.
There should really be a more granular way for the user's policy to adjust the origin definitions used for cross-origin logic as well as other types of content blocking and enforcement.
Why shouldn't a user be able to isolate https://example.com/app1 as much as https://app1.example.com?
Why shouldn't they be able to grant any permission to be used in a single page https://example.com/app1/usefulpage and not in other pages on the site?
The multi-container approach to browser session isolation faces the same issues. Different users may have different preferences for when navigation shares the session and when navigation should kick you into a new session that lacks authentication, tracking, or app state.