I think you’re ignoring the fact that the browser security model is based on a flawed definition of an origin that prohibits something that has very little reason not to work. Userdir sites weren’t/aren’t limited at all. If you dropped a php file into your directory it would run.
domain.suffix/full/path should have been the definition of an origin because people were literally using it as such. The default config of the most popular web server at the time was doing it. People hosted entirely different sites in subdirectories because it was really easy to just create a directory. TV ads directed people to www.blahblah/sitename.
The real definition of origins is clever since the path before the domain defines an origin path and everything after is owned by that origin. Neat and tidy for sure but broke userspace so to speak.
But that's never how userspace was ever designed to work during the web's history. Hosting sites this way, especially commercial ones, was always insecure because of the way cookies were designed from day one.
Same-site policies broke userspace in the same sense that Wayland is breaking X11 userspace by making it so applications can't just send keypresses to each other. Userspace was already broken, it was an insecure mess -- it's just that we recognize it now. If you were running a userdir site that supported PHP, you probably should not have been doing that.
I'm glad nothing got hacked for the people doing it, but I used to leave my bike unchained at the library growing up, and it didn't get stolen either -- didn't make it secure. I believe you that there was a time when companies advertised on TV using userdirs, because I know there was a time when Facebook only used SSL for its login screen and when Twitter forced users to enable SSM account recovery. Companies do insecure crap sometimes :)
If you don't care about same-site security, then nothing's broken -- the vulnerabilities you're exposed to now in a post-Javascript world for userdir sites are the same ones you were exposed to back then. It's just users today are more likely to actively exploit them.
I'm in no way saying that it wasn't a broken insecure mess and needed fixing -- just that the fix that actually happened broke some already established ways of organizing websites. Any website that relied on that doing naughty things with cookies that crossed logical boundaries they weren't supposed to -- sure -- makes total sense to break them. But having one site at mysite.com/a and another at mysite.com/b is a perfectly valid use cause and ought to have had a path to being secure instead of being fundamentally insecure which is what we have now.
Like doesn't it seem a little silly that you can't make a.mysite.com and mysite.com/a behave the same way?
The current system is mostly consistent with the way that SSL UX works, it's consistent with the way modern browsers display URLs. From an engineering perspective it's silly, but we're also thinking about ways to easily get across to users 'who owns the thing you're looking at'. It's also nice to have a rigid boundary somewhere, because it allows us to turn on isolation by default; the same-origin policy isn't something programmers have to remember to opt into. So there's UX questions like, "by default should cookies only resolve to a single URL, and programmers have to whitelist subpaths? Would any of the web operators doing this today care enough to actually implement an optional security feature?"
All that being said, I'm broadly sympathetic to an argument that same-origin policies didn't go far enough. I think you can make a very reasonable argument that origins are pretty arbitrary, and that the problems I list above are solvable, and that regardless of the original design we should adapt to what users want to do. That's a fine position to take.
I'm not sympathetic to the top-level argument I was originally responding to; that Javascript has fundamentally made things worse, or that the same-origin policy is a house of cards waiting to collapse, or that that browser policies like same-origin and SameSite aren't basic security improvements over what the web used to be before JS. The truth is, while imperfect, web browser security is still (broadly) very good. I question if there is any user-accessible native platform that comes even close to the web in having decent process/network/data isolation. There is no house of cards collapsing, in reality most native platforms like phones are largely playing catch-up to implement the same sandboxing features that the web has had for nearly a decade.
I get that's not the argument you're making, you're looking at this through the lens of, "should this be supported?". And again, that's reasonable. I do want to re-emphasize though; if you still want to host using userdirs, no browser capabilities have been removed, and nothing is any more insecure than it used to be. You're using the word 'broke', I'm not sure I get what you mean by that. There was an insecure thing people were doing, and they can still do it today with the same consequences. Nothing has fundamentally changed.
> by default should cookies only resolve to a single URL, and programmers have to whitelist subpaths?
That sounds sensible! I always wondered why the origin and cookie scope isn’t limited to the full URL of the resource that set it and only explicitly extendable by something like <link rel=“same-origin”...>
Basically make every URL it’s own security and permissions sandbox but allow the programmer some latitude to extend it (and probably the administrator of parent directories/domains some capability to restrict how far up/across the tree a URL can reach, with the default perhaps being to allow only within same domain and path.)
domain.suffix/full/path should have been the definition of an origin because people were literally using it as such. The default config of the most popular web server at the time was doing it. People hosted entirely different sites in subdirectories because it was really easy to just create a directory. TV ads directed people to www.blahblah/sitename.
The real definition of origins is clever since the path before the domain defines an origin path and everything after is owned by that origin. Neat and tidy for sure but broke userspace so to speak.