When scripts load cross-domain from load.php (e.g. enwiki loading a gadget from mediawiki.org and a GlobalCssJs script from Meta-Wiki), everything works great. It is well-cached. It's secure (only public stuff is served). And it emits the proper headers to allow browsers to report errors with full details, because the CORS headers we emit from load.php basically tell browsers that we ignored any cookies the user might have and that they do not affect the source code, and thus it is okay to tell en.wikipedia.org (or third party domains) about any strings or other content within the scripts we serve.
But, for `index.php?action=raw` this is not the case.
When loading it plainly as a `<script src=…>` across domains, it is allowed to run but is treated as authenticated cross-domain content, similar to how hotlinked images are treated by default. They are allowed to download and run, but no details about the network transfer or the script content are meant to leak.
Also, when logged-in, the scripts are never cached as precaution since on private wikis these could contain non-public details.
#### Objective
In the common case of any user (logged-in or not) on public wiki A importing a known publicly-visible revision from public wiki B, as a script, the browser should emit `Access-Control-Allow-Origin: *` so that stack traces are not redacted by the browser.
It'd be nice if we can also make it so that these can be cached for logged-in users, but that's a stretch goal and probably not feasible without VCL changes in the WMF traffic edge, which probably isn't worth it. We do still allow the browser to cache them locally and use If-Not-Modified/304 checks to reduce transfers.