RE: [sysapps/runtime] cross origin XHR in packaged apps

Comments inline.

From: Ming Jin [mailto:ming.jin.web@gmail.com]
Sent: Thursday, March 28, 2013 8:35 AM
To: SULLIVAN, BRYAN L
Cc: public-sysapps@w3.org
Subject: Re: [sysapps/runtime] cross origin XHR in packaged apps


2013/3/27 SULLIVAN, BRYAN L <bs3131@att.com<mailto:bs3131@att.com>>

I think CORS should work as is, since the origin header will be set correctly by the web runtime (browser or native web engine) and the resource (network based or local server) can choose to honor the request or not.

IMHO, compared to hosted apps (or browser-based apps, as you call it), there are a few things that packaged apps (local resources) are not quite appropriate for CORS.

First thing is the uniqueness of "app://" based origin. Unlike DNS that has a central authority (IANA) to ensure the uniqueness of an internet domain, there's no such authority for "app://<opaque_string>" origin. If we cannot ensure global uniqueness, by theory it's not reliable to implement access control logic based on "app://" origin on the server-side.

<bryan> The UA (in this case the web runtime of the device) should ensure that the app origin is trusted, either as confirmed by the user or through digital signature applied to the app package. I agree that if the app origin is not trusted, then the UA should not allow it to make cross-origin requests.

Second is that, unlike hosted apps which can at least make XHR calls to the same origin, every XHR call in a packaged app is cross-origin (i.e., no same-origin XHR at all). This means that if we allow CORS as is for packaged apps, there'll be no way to do any XHR call from a packaged app.

<bryan> I don't understand your point. XHR2 supports CORS, and is the defacto standard now. So cross-origin XHR works fine.

Third point is that there will be no http cookies or authentication info generated upon loading a local resource file from a packaged app. That said XHR calls with "withCredentials" flag set "true" will not be able to send any cookies or auth info.

<bryan> This sounds like the app would have to first establish cookies and the authentication with the remote server, at least once, but I don't see a use case that is explicitly prevented because of that.

Regards,
Ming Jin