net::ERR_FAILED with cross-origin embeds (Web/Chrome)

[Couchy]

Console output:

Access to fetch at 'https://i.4cdn.org/f/owata.swf' from origin 'https://boards.4chan.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

core.ruffle.js:1 GET https://i.4cdn.org/f/owata.swf net::ERR_FAILED

[kmeisthax]

Looking at WebNavigatorBackend it appears we aren't requesting CORS, but it ran a CORS check anyway. This won't be fixable until Hiroyuki configures i.4cdn.org to accept cross-origin requests from 4chan.org. (Interestingly, the crossdomain.xml on 4cdn is deliberately configured to deny all Flash cross-origin requests, though that was probably done back when moot ran that site.)

The reason why this works in Flash Player is because Flash doesn't apply same-origin rules to initial SWF loads (in fact, it doesn't even use the same HTTP stack). This is the same rule that lets you hotlink images off of other domains. However, Ruffle isn't "trusted" code so it doesn't get to make any use of cross-origin data unless the server sends back a header saying that it's OK for us to use it. This applies for both the self-hosted and extension versions, because even the extension has to run in the "untrusted" world.

[Couchy]

This could be a problem given that flash heavy sites are naturally more likely to be older and unmaintained. Unfortunately, it looks like things are only going to get worse in Chrome's jihad to cripple extensions:

https://www.chromium.org/Home/chromium-security/extension-content-script-fetches

[floens]

4chan/4chan-API#83

[kmeisthax]

@Couchy We don't use CORS bypass in Ruffle as-is, and I really would like to avoid doing so if I can. We can't run Ruffle isolated from the page it's attached to (unlike Flash Player, which sat behind a plugin API that pages had limited interaction with), so any attempt to support this usecase would effectively constitute handing the page an arbitrary cross-domain request mechanism.

The closest thing I could think of would be a trusted extension URL that the untrusted Ruffle Player could shove in a shadowed iframe to request an opaque/nocors style third-party SWF load. However, I still have a number of questions related to that:

1. Can the extension's background page tell the difference between the untrusted outer page and the trusted inner iframe?
2. How do self-hosted Ruffle instances know that there's a trusted Ruffle instance they can use opaquely?
3. How does an opaque trusted Ruffle iframe expose ExternalInterface functions or other Flash Player API surface to the untrusted world? Should it?
4. Is Flash's lack of root movie origin checks itself a security problem that nobody has noticed?
5. How isolated are extension pages in iframes from the page that's including them, compared to the isolation that a plugin in an object tag gets?

The number of questions here, even for a somewhat experienced webdev like me, would indicate that we should not support this in the extension, at least not by default.

[Couchy]

Something else I wondered about, maybe tangentially related - Is it possible to handle direct links to .swf files? If so, maybe there could be a right-click "Open in new tab" option that would bypass the CORS issues with embedding.

[Couchy]

so we can expect this to be implemented by 2030 the earliest.. (not that that site is usable anymore anyway, and /f/ is kind of dead. but I guess that's off topic)

Well, he found time to add three more vidya boards. And Flash in general is dead, isn't that why we're all here? But I will never not love me some lolicatgirls.swf.

[Herschel]

Generally I agree with @kmeisthax, in that we simply have to (and should) live within the security restrictions of the modern web, so these kind of issues will be unavoidable.

However, I do think it's worth at least investigating if the extension could allow this via adding cross-domain permission for the extension, fetching data in the background script, and passing that data to a content script via a message. Even if this is possible, this not something I would want to allow in the build by default for the reasons @kmeisthax mentions (even if we fully mimic Flash's own security and crossdomain.xml restrictions). But perhaps this could be an additional option during compilation.

[puigru]

However, I do think it's worth at least investigating if the extension could allow this via adding cross-domain permission for the extension, fetching data in the background script, and passing that data to a content script via a message.

I've dabbed in developing Firefox extensions in the past and this is definitely possible.

[alexolog]

Is it possible to "fake" the required CORS headers with an add-on?
For example: https://github.com/didierfred/SimpleModifyHeaders

[Couchy]

Is it possible to "fake" the required CORS headers with an add-on?
For example: https://github.com/didierfred/SimpleModifyHeaders

Yes, I was able to do this in the above mentioned issue.

[alexolog]

Yes, I was able to do this in the above mentioned issue.

Could you please post a walk-through or a short tutorial?
I am not familiar with the syntax.

Thanks!

[Couchy]

@alexolog
Look at dist/background.js in that zip I posted there. It uses webRequest to listen for swf files. If the request comes from an XMLHttpRequest (i.e. Ruffle trying to fetch it) then it sets the "Access-Control-Allow-Origin" response header to the current page domain to allow that.

[alexolog]

The zip you posted where?
I am not conversant with javascript, and was hoping to just use an extension, provided I knew how to set up the rules.

Obviously it would be much better if Ruffle did that natively.

[Couchy]

Here: #2167 (comment)

Then follow the instructions to install an unzipped extension: https://ruffle.rs/#usage

Note this is only for Chromium variants; I haven't tried it on Firefox.

[alexolog]

Yea, FF needs it's own extension, although most of the code is the same.

I really believe that Ruffle should be doing it natively. The whole idea of preserving old (and by extension unmaintained) technology is not to expect the site operators to do maintenance.

[Couchy]

@kmeisthax I don't think specifically allowing just swf files requested by XHR Is too much of a security threat, do you?

Another idea I had is that the extension could pass a randomly generated key to the Ruffle script to append to its XHR requests to identify them and allow them through. Not sure if it's possible to make said key visible only to the Ruffle script, though.

[digitalcircuit]

I may just be missing it, but I can't seem to find where the documentation mentions this incompatibility with crossdomain.xml?

I had pointed out Ruffle to a network that has Flash files that made API requests across a domain via crossdomain.xml, and they did not expect to need to add CORS HTTP headers (I forgot to mention that part to them).

This can be filed as a new issue if desired.

[alexolog]

Most Flash content still on the net is left as an afterthought and is no longer supported on maintained. I do not believe that expecting site owners to update CORS rules on the server side is realistic, and therefore would like to see the option of overwriting CORS in Ruffle.

[Poopooracoocoo]

@alexolog i think the problem is that CORS is a security feature. Extension stores likely won't allow Ruffle. Ruffle could have two versions though

[alexolog]

I agree in principle, but it makes Ruffle unusable on many sites.

[Couchy]

Plus, there'd be no point in even having an extension if everyone updated their site to use Ruffle.