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

I think the main value of an 'allow-origin' manifest field would be to 
implement least-privilege restrictions defined by the application 
itself, rather than access control defined by the remote origin.

I agree that CORS should be respected for browser-based apps (all hosted 
apps?)

For packaged apps, we could reuse the CSP 'connect-src' directive to 
optionally constrain XHR/WebSockets. In Chrome, you can add CSP 
directive to the manifest of packaged apps - 
https://developer.chrome.com/beta/apps/app_csp.html- as well as defining 
cross-origin permissions for extensions - 
https://developer.chrome.com/extensions/xhr.html. This doesn't seem to 
be the case in the current sysapps runtime spec.  My opinion is that, 
for packaged apps, it makes sense to support CSP rules included in the 
manifest and ignore CORS, as this is the behaviour of native apps.

If an application has access to a raw socket API, then any 
origin-related policies seem a bit futile and the CSP directive ought to 
be "connect-src *;"

Other state of the art is WARP - http://www.w3.org/TR/widgets-access/.

Best wishes,

John




On 27/03/13 10:42, SULLIVAN, BRYAN L wrote:
>
> 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.
>
> For a browser based app the origin would never be based on the 
> app: scheme.
>
> Thanks,
>
> Bryan Sullivan
>
> ------ Original message------
>
> *From: *Ming Jin
>
> *Date: *Wed, 3/27/2013 3:52 AM
>
> *To: *public-sysapps@w3.org;
>
> *Subject:*[sysapps/runtime] cross origin XHR in packaged apps
>
> Hi SysApps,
>
> I'd like to discuss about supporting cross-origin XHR in packaged apps.
>
> *Problem statement*
> In current runtime proposal, local resources in a packaged app have 
> "app://"
> based origin, and every XHR request to http/https url will initiate a 
> cross
> origin XHR. Since most of the servers are not aware of "app://" origin and
> even not CORS-enabled, the XHR will simply fail due to same-origin policy.
>
> *Existing approaches*
> Firefox OS provides a modified XHR API (new XMLHttpRequest({mozSystem:
> true});) to relax same-origin restrictions [1], and Chrome allows 
> Extensions
> to specify origin white-listing to by-pass CORS checking [2].
>
> *Analysis*
> In general, it'll be better to reuse existing XHR without 
> modification, and
> also better to provide the cross-origin XHR functionality to as many 
> apps as
> possible (i.e., not only restricted to "certified" apps).
>
> Adding a manifest entry (e.g., "allow-origin") to white-list the origins
> seems to be a better approach, but the manifest entry should not be
> applicable to hosted apps (otherwise it defeats the purpose of CORS). 
> Since
> the "app://" origin only makes sense locally to the device, by-passing 
> CORS
> checking for local resources also makes sense.
>
> *Proposed change*
> Introduce a new manifest entry (e.g., "allow-origin"), and put additional
> description on that to indicate that it's only applicable to local 
> resources
> of packaged apps.
>
> So what's your opinion?
>
> Thanks,
> Ming Jin
>
> [1] 
> https://groups.google.com/forum/#!topic/mozilla.dev.gaia/sc-G5prl7D8 
> <https://groups.google.com/forum/#%21topic/mozilla.dev.gaia/sc-G5prl7D8>
> [2] https://developer.chrome.com/extensions/xhr.html
>
>