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.
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.
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.)
Origins are very clearly and rigorously defined[0].
It's just that people have a tendency to group multiple applications/users on the same origin. Now, would it be nice to optionally allow servers to be more restrictive? Sure. There are a few privacy implications there, but I could easily see someone making a case for that. I think I'd possibly support an HTML directive that allowed you to have a stricter same-origin policy (ie, restrict to current URL, or restrict to parent path).
At the same time, setting up subdomains that point to static directories is really stinking easy. And I am skeptical that any web host that refuses to use subdomains is going to care enough about security to opt-in to an even more aggressive scheme. A website that is hosting 3rd-party sites via userdirs is a website that will ignore or circumvent any security model you propose.
> The public suffix list is yet another incomplete workaround for the security flaw in the same origin policy
No, the opposite. The public suffix list is a workaround for the flawed security model of cookies. In your focus on Javascript, you are missing the much bigger problem. See below:
> there is however still a caveat with this: Unfortunately the same origin policy does not apply to all web technologies and particularly it does not apply to Cookies.
The same-origin policy is (overall) fine, the problem is that the old web security model didn't have it. So we are trying to retroactively build a modern security model based on strict, on-by-default isolation on top of a flawed security model that assumed every single domain would be owned by a single entity. Cookie "contexts" are a lot broader than modern definitions of "origins". They can be inherited from parent domains, they can be trivially shared across domains without user consent. And they also aren't by-default isolated across userdirs.
This has all turned out to be, broadly, a bad idea. While I don't think the same-origin policy is perfect, it's pretty obviously better than what we were using before. This is why you're seeing movement from the Chrome team to turn on SameSite isolation by default for cookies. Because we look back at the original web security model and realize that opt-in SameSite and randomized form-submit tokens for security were always a mistake.
All of this is dancing around that you mention that userdir URLs pre-date Javascript. To be clear, userdir URLs were inherently insecure from the moment they were conceived. You should not have been hosting websites this way, even before Javascript existed.
To the extent that people got away with this kind of thing before Javascript, it was only because userdir websites were so ridiculously limited that they often didn't have any serverside capabilities to respond to form submissions, or to run any kind of logic at all. To the extent that people weren't widely phished on userdir-hosted sites by fake forms with hidden fields that sent logic to parent origins or to other sites they were already logged into, it's only because the web was so young and so tiny that we were able to get away with bad security -- the same way that in a rural area I can get away with leaving my garage unlocked.
I'm not exactly happy with every decision modern browsers are making about the direction of web security, but I would challenge anyone to look at the history of CSRF mitigations and then say that the same-origin policy is not a universally better security model for Javascript to adopt.
[0]: https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...