4 ms·

I disagree about domain names, but I don't think that's even relevant to this discussion. Do you have some kind of security model in mind that would work bette

I disagree about domain names, but I don't think that's even relevant to this discussion. Do you have some kind of security model in mind that would work better than same-origin policy in this case? I.e. cross-origin requests are still allowed to happen somehow, but users are still protected against random services intentionally disabling your security measures?

gambler 7y ago
It is bloody obvious that when people spin something up on their local machines the do not intend to make those pages available to every website they visit. This by itself suggests that there should be a dedicated security context for such applications and that the restriction on information exchange should be based on that context. Not on some random thing the application does (like authentication, CSRF or sending CORS headers). Scenarios like that should be the foundation of a sensible security model, not an afterthought achieved by applying layers and layers of security ducktape in every single instance.
- kyle-rb 7y ago
  >Not on some random thing the application does (like authentication, CSRF or sending CORS headers). Sending CORS headers isn't "some random thing" though, it's specifically the one thing that stops the security model that's in place from working. There's a lot of bad security practices that you could define as "some random thing", and the fact that some people might do that thing doesn't make the whole model around it invalid.
- brlewis 7y ago
  >an afterthought achieved by applying layers and layers of security ducktape This is where you're missing the fundamental nature of the issue in this article. The sensible security model is there by default. An additional layer is added to make a resource available cross-origin, and the article merely serves to remind people that making a resource available cross-origin is still making it available cross-origin when the origin is localhost.

gambler 7y ago

It is bloody obvious that when people spin something up on their local machines the do not intend to make those pages available to every website they visit. This by itself suggests that there should be a dedicated security context for such applications and that the restriction on information exchange should be based on that context. Not on some random thing the application does (like authentication, CSRF or sending CORS headers). Scenarios like that should be the foundation of a sensible security model, not an afterthought achieved by applying layers and layers of security ducktape in every single instance.

kyle-rb 7y ago
>Not on some random thing the application does (like authentication, CSRF or sending CORS headers). Sending CORS headers isn't "some random thing" though, it's specifically the one thing that stops the security model that's in place from working. There's a lot of bad security practices that you could define as "some random thing", and the fact that some people might do that thing doesn't make the whole model around it invalid.
brlewis 7y ago
>an afterthought achieved by applying layers and layers of security ducktape This is where you're missing the fundamental nature of the issue in this article. The sensible security model is there by default. An additional layer is added to make a resource available cross-origin, and the article merely serves to remind people that making a resource available cross-origin is still making it available cross-origin when the origin is localhost.