Requirement:
The Cross-Origin XHR was required by customers. The customer want his app to get data from 3rd party server. He want Cross-Origin XHR can works like Chrome Apps.

Issue:
The XHR request will be cancelled, once the HTTP response header from server don't has a Access-Control-Allow-Origin filed, or the value of Access-Control-Allow-Origin doesn't match the current domain.

According to W3C spec, there are 2-stage permission checks during XHR:
1. CSP check. 
It checks whether the target URL matches the 'connect-src' in CSP. If the target URL is against the CSP rules, the request won't be sent out at all.
2. Access-Control-Allow-Origin check.
After sending the XHR request header, the response header will be got by browser/runtime. If there is a Access-Control-Allow-Origin field in the header and it matches current domain, the transportation will continue. Otherwise, the request will be cancelled.

To allow Cross-Origin XHR, Access-Control-Allow-Origin check should be bypassed. Here are 2 Solutions:
1. Introduce a white list.
The Access-Control-Allow-Origin check will be skipped once the target URL is in the white list. In this case, the manifest.json should be extended to allow developers add the white list. I heard from Xinchao @takethathe that you have discussed the white list before, but it was rejected by the manifest spec.

2. Enable universal access.
Once universal access was opened by switches like 'allow-universal-access-from-file-urls', the Access-Control-Allow-Origin checks will be skipped for all XHR requests, this solution may lead to more security risks.

As white list couldn't be used to reduce the security risk, we hope a switch can be added to the packing tool, and let the developer himself to determine whether to open universal access.