Simple cross-origin requests generated outside this specification (such as cross-origin form submissions using GET
or POST
or cross-origin GET
requests resulting from script
elements) typically include user credentials, so resources conforming to this specification must always be prepared to expect simple cross-origin requests with credentials."
Essentially, CORS was designed so it did not expand the threat model of existing services deployed in the field. And to relax the existing security model, a resource (AKA the server) must explicitly indicate that it is amenable to such relaxation.
Nothing stops a user agent from allowing users to grant cross-origin privileges to some code, but that is not standardized. Typically the way do to this is through an extension mechanism. I think there is little or no interest in standardizing a mechanism to grant web resources permissions to break the Same Origin Policy with user permission, because of the long and entirely ignominious history of similar things (see: ActiveX). You can't simply allow code to declare itself privileged in that regard, and experience shows that it is extraordinarily difficult to ask the user to make a meaningful and informed choice that maintains their safety. So the fallback position has been to reserve such privileges for extension mechanisms where some level of additional review and feedback can be applied at the distribution points, on the user's behalf, to protect their interests. Or you can write your own extension for your own browser to do such things.
In the near future, we may be able to do more interesting things for users if we are able to create robust confinement mechanisms that allow new kinds of information flows without violating the security assumptions of existing applications. The proposed COWL deliverable on this group's new charter is a step in that direction. But I don't think you will find much support for anything resembling a pop-up dialog that asks users if they'd like to let this web page read their banking details, etc.