Part of the concerns are actually that not sending cookies will make some things less secure because it encourages that the requesting party will ask the user for authentication data of the site being targeted

I can understand that but I actually think that number would be reasonably small. I think even the most security ingorant site developers can realize that a logon on an external system isn’t a great idea, and the need to explicetly send either credientials or a retrieved session identifier with each request as a post (or god forbid, get) paramater would be enough of a pain that many sites would be too lazy to implement it. At the same time if cookies are enabled and the API exposes getAllResponseHeaders() or getResponseHeader(), which would make sense from a functionality standpoint (the feature would be much more handicapped if you couldn’t query the server response than it would not sending cookies), then I can get at the cookies as the script author. I can already do that to get past the HttpOnly flag in an XSS attack.

I do think the browser should strip the cookie from the response header before handing the response to the script, even in the current XMLHttpRequest, to protect against this. (as an aside I think document.cookie should also be disabled except for sites running in some trusted context, if even then. The situations where the client is the better entity to edit or examine cookies rather than the server are very few and far between. In almost every legitimate use the server should be doing that work, even if a design makes it easier to do on the client). Doing so would make me a good deal less wary, and rereading the spec I see I missed that in the user agent section the first time.

Furthermore, the primary reason to pass session or authentication information in the request is to get at a user specific protected portion of the website. Certain well designed websites will expose this to external request in a very well thought out manner, but I think the number of websites that will expose information in a poorly thought out manner will be many. Companies have already proven with their various Web APIs that even if they think about security with their website they often forget it when they implement the other means of accessing their data. I think this is opening the door to enable much more dangerous designs than leaving it out and hoping companies don’t pass credentials in another fashion.

I also think that we already have a safer method of doing cross site requests using web services. There are a wealth of things I can do to ensure my exposed data is only going to trusted sources when the external entity is another server (requiring digital certs, IP filters if only a limited number of external entities, source authentication credentials, etc) that I either can’t do on the client, or would be really dumb (the source authentication credentials, since anyone could view source for static credentials, or drop in with a debugger if the creds are dynamically retrieved). With the client side request, I as the host ultimately cannot trust the real source of the request.

I’ll properly collect my thoughts and post something to the mailing list monday or tuesday (and admittedly do a better job rereading the spec, since I missed the User Agent is supposed to strip cookies from the response the first read through).

(Part of the concerns are actually that not sending cookies will make some things less secure because it encourages that the requesting party will ask the user for authentication data of the site being targeted.)

If they really didn’t chime up, despite chairing the WG, then by all means, you are right. I don’t have issue with them deviating from the spec in this case, but if they didn’t notify their peers in the W3C that they were doing so, or why, then you are justified in having issue with it (you would be more in the know than I, which will teach me for mouthing off without doing my research about who I was mouthing off about, though I hope I didn’t come across as too rude).

Would you agree that there are some serious security implications with the proposal as it stands though?

It is true that they haven’t communicated details to the public until the first public developer beta, but when would be a better time to make the decision public? When the public cannot actually play with the implementation and is left to base any feedback entirely on speculation or when the public can actually see the implementation in action. The public developer beta is largely for the purpose of getting the general public to send feedback while the product can still be changed reflecting the feedback. If that isn’t a good time to inform others, I am not sure when a good time would be.

Aaron Wakling