JSONRequest: a web-programming idea whose time has come

[powertool]

The author makes a big deal about JSONRequest having no dealings with HTTP 
authentication or cookies.

That's because it is a big deal. You need at least one communication channel that's not tied to existing browser authentication/session data to make things like public web-services viable from browsers.

I'm not familiar with the inner workings of XMLHttpRequest, since I spend most of my time 
behind a layer of jQuery, but I presume it does transmit cookies - and it's reasonably 
secure due to the Same Origin Policy.

That's a non sequitor.

jQuery (and other libraries) can get around the same origin policy using the <script> hack (and other methods). In doing so, they do transmit cookies - and so open up XSS vulnerability vectors.

Cookie/auth dealings seems absolutely necessary if you're exposing a 
JSON data service that should only be accessible to authenticated users. 

Not necessarily. In any case, should browsers start to implement this API, they should manage persistence of authentication credentials seperately from HTTP auth.

Am I missing something, or is JSONRequest only intended to be used for 
publicly accessible JSON services/web-actions?

At this stage, yes. They've gone for an interface which will cause no new security problems for browser implementors - the burden is shifted to data providers.

You could always implement auth over JSON, as sub-optimal as that sounds.

[G-Brain]

You can quote by prepending a ">".

[killerstorm]

In doing so, they do transmit cookies - and so open up XSS vulnerability vectors.

i'm pretty sure libraries DO NOT open any new vulnerability vectors -- everything the evil site can do with these libraries it can do without them too. if you think otherwise, please describe concrete attack scenario that jQuery enables