Re: CORS explained simply

Yes.  There is no simple explanation of "simple request" because it doesn't
have a simple explanation.  All the unstructured cross-origin stuff
browsers decided to do without any really coherent guiding principles over
the first dozen-ish years of the Web, they can keep doing.  Anything new
requires CORS.  In hindsight, "legacy request" would probably have been a
better name.

The spec is already somewhat long, and the algorithm of what is allowed and
what is not is as concise as possible.  I don't think it would be improved
by another ten pages of historical motivations and browser archaeology, as
interesting as that might be in a different context.

It is a very fair criticism, and an observation I have made myself, that
the spec is written primarily for an audience of web browser implementers,
and not for those deploying CORS in an application context.  But I'm not
sure why, at this point, developer-oriented resources like WebPlatform.org
and MDN aren't the best choices to fill that gap.

I will note that:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

is quite good, for example.

-Brad

On Fri Feb 20 2015 at 2:45:28 AM chaals@yandex-team.ru <
chaals@yandex-team.ru> wrote:

> I think I see the problem here…
>
> 20.02.2015, 01:38, "Brad Hill" <hillbrad@gmail.com>:
>
> There are addressed in the security considerations section:
> http://www.w3.org/TR/cors/#security
>
> The particular bit of most relevance is:
>
> "A simple cross-origin request
> <http://www.w3.org/TR/cors/#simple-cross-origin-request> has been defined
> as congruent with those which may be generated by currently deployed user
> agents that do not conform to this specification.
>
>
> I'm not questioning the accuracy of this statement.
>
> Because I am still working to parse it into something I can explain in
> clear english to my colleagues. (2 minutes later: "a 'simple request' is
> one that effectively does not use CORS. The most obvious reason these exist
> is because there are browsers that didn't implement CORS, such as those
> shipped before the specification was finished. ).
>
> It seems that Henry is suggesting an "explainer" which did that task for
> the spec as a whole would be a useful document. Based on this sample, I
> have to agree that it would be helpful.
>
> The question is whether there is someone in the group to write it, or
> whether pointing to stuff people have already written is enough. Maciej's
> slides from 2009 are also a useful reference…
>
> cheers
>
>
> Simple cross-origin requests generated outside this specification (such as
> cross-origin form submissions using GETor POST or cross-origin GET requests
> resulting from script elements) typically include user credentials
> <http://www.w3.org/TR/cors/#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.
>
>
>
> On Thu Feb 19 2015 at 2:19:54 PM henry.story@bblfish.net <
> henry.story@bblfish.net> wrote:
>
> Hi,
>
>  I find that understanding CORS is a really not easy.
> It seems that what is missing is an general overview document,
> that would start by explaining why the simplest possible method
> won't work, in order to help the user understand then why more
> complex method are needed.
>
> For example the first thing one should start by explaining is for
>
> 1) requests that do not require authentication
>   q1: why is the origin sent at all? And why are there still restictions?
>   q2: why does POSTing a url encoded form not require pre-flight? But why
> does POSTing other data do?
>
> 2) On requests that do need authentication:
>   q3: Why are the pre-flight requests needed at all?
>
> I know that the answer to q1 is that some servers have access control
> methods
> based on ip address of the client. But it is worth stating clearly the
> requirement
> in the specs so that this can be understood.
>
> There is also the question as to why the server needs to make a decision
> as to
> what the client can see. But why can't it be the client? After all the
> user could
> decide to give more rights to some JS apps than to others, and that would
> work too.
>
> I am not saying that these questions don't have answers. It is just that
> they
> would help a developer understand why CORS has taken the shape it has, and
> so
> understanding the reaons for the decisions taken, better be able to think
> about it.
>
> Henry
>
>
> Social Web Architect
> http://bblfish.net/
>
> Social Web Architect
> http://bblfish.net/
>
>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>