Maciej Stachowiak wrote:
On Jun 14, 2008, at 4:23 AM, Jonas Sicking wrote:
I must say though, this is starting to sound complex and I am not
totally convinced of the need to make servers opt in to getting
cookies. Is it really a likely mistake that someone would take
affirmative steps to enable cross-site access to a per-user resource,
but then neglect to check whether requests are cross-site and act
appropriately?
I do think there is a big risk of that yes. I do think that many sites
that today serve public data do have a few pages in there which
contain forms or other pages that serve user specific data.
Even something as simple as a news site that largely serves public
news articles might have a cookie where the user has chosen a home
location for local news. This is the case on the news site I use for
example, it usually just serves a standard list of news, but if I give
it my home zip code, it will additionally serve a section of local news.
I guess I don't see that as a huge risk. In the case of the hypothetical
news site, if it is handing out news in some kind of data feed format,
wouldn't the point of access-control be to give the personalized feed?
If the site gives out a personalized feed it has to be *a lot* more
careful who it gives it out to. It must first ask the user for every
site it gives the feed to.
If it just gives out non-personalized feeds it can safely share the feed
with any site.
After all, you could otherwise use server-to-server communication to get
the public data.
Yes, but server-to-server communication has a lot of downsides. First of
all it greatly increases the latency since the information is
transferred over two connections rather than one. Second, it means that
you have to have a server that has enough capacity to tunnel all the
mashup data for all the users of your site. This can be a significant
hurdle.
This is something that could very easily be overlooked by an
administrator that just configures his server to add a
"Access-Control: allow<*>" header using a site-wide configuration
file, without going through all CGI scripts on the server and teaching
the ones that honor cookies to ignore the cookies for cross-site
requests.
No site should add "Access-Control: allow<*>" site-wide!
Experiences with Adobes crossdomain.xml show that they do.
I mean, I guess
it's possible people will do this, but people could add
"Access-Control-Allow-Credentials" site-wide too. And if we add
"Access-Control-Allow-Credentials-I-Really-Mean-It", they'll add even more.
Yes, this is certainly a possibility. But my hope is that this will
happen to a smaller extent.
Basically the part of this that worries me is that it requires agreement
between the client and the server, but those are expected to be
controlled by different parties in many cases. If our favorite news site
starts out only offering unpersonalized news feeds to other sites, but
then wants to use cookies to personalize, then all existing clients of
its cross-site data must change. That seems like a huge burden. Worse
yet, if the site changes its mind in the other direction, existing
clients break completely.
If you start sharing a new set of data it makes a lot of sense to me
that people reading that data need to change. This seems no different
than if you change from sharing an address book to sharing emails.
Usually someone reading the data would need to both change the URI they
are reading, as well as how they display the data.
And if the administrator of such a server thoughtlessly enabled
cross-site access without thinking about the consequences, would they
not be equally likely to enable cross-site cookies without thinking
about the consequences?
Not more likely than someone adding any other header without knowing
what it does. This is why I designed my proposal such that opting in
to cookies is a separate "step".
But you are expecting people to add Access-Control without knowing what
it does.
It's not a matter of knowing what the spec says, its a matter of knowing
with 100% certainty that you are not sending any private data on any of
the URIs you are sharing.
It seems like we are adding a lot of complexity (and therefore more
opportunity for implementation mistakes) for a marginal reduction in
the likelihood of server configuration errors.
I think the ability to separate sharing of private data from sharing
of public data is a huge help for server operators. So I think this is
much more than a marginal reduction of configuration errors.
The possibility of making this separation is there - simply ignore
Cookie and/or Authorization headers when Access-Control-Origin is
present. So this opt-in doesn't offer a new capability, just changes the
defaults.
In many server technologies it's not trivial to ignore cookies and/or
auth headers. Session handling tends to be handled before the "CGI"
script starts which means that you have to weed though the whole code to
ensure that no code uses the stored session state.
After reviewing your comments, I am much more inclined to favor
Microsoft's proposal on this: rename the relevant headers. I think you
argued that this "doesn't scale", but I think only two headers have to
be renamed, "Cookie" and "Authorization". Note that other
authentication-related headers, if any, do not need to be renamed,
because without the "Authorization" header being present, no other
authentication processing will take place. If the headers have different
names, it's very hard to reveal private data accidentally. No site-wide
blanket addition with headers will cause it, you have to go out of your
way to process an extra header and treat it the same as "Cookie". It
would allow allow servers to choose whether to offer personalized or
public data and change their mind at any time, without having to change
clients of the data. It would also work for inclusion of cross-site data
via mechanisms that don't have a convenient way to add an out of band flag.
The only downside I can think of to this approach is that it may break
load balancers that look at cookies, unless they are changed to also
consider the new header ("Cross-Site-Cookie"?).
Using different header names would certainly address the concern I have
regarding reducing the risk that private data is inadvertently leaked.
However I think the downsides are pretty big. The load balancer issue
you bring up is just one example. Another is that I think caching
proxies today avoid caching data that is requested using Authentication
headers. Probably the same is true for the cookie header in some
configurations.
I think going against the HTTP spec carries big unknown risks. I'm sure
others with more HTTP experience than me can chime in here better.
The cost and risk of adding an extra boolean to XMLHttpRequest seems
much lower.
/ Jonas