Bug 1532646 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

In order to prevent non-media "no-cors" cross-origin content from entering the content process it would be good to know what logic we use today to determine whether a resource is allowed to be played.

My suspicion is that this is a combination of Content-Type parsing and sniffing some initial set of bytes of the response.

If we feed a response into some subsystem without any kind of validation it would be good to know whether the subsystem performs validation and what that might be.

I'm further assuming that range responses cannot be made without first confirming the type of the resource somehow.
In order to prevent non-media "no-cors" cross-origin content from entering the content process it would be good to know what logic we use today to determine whether a resource is allowed to be played.

My suspicion is that this is a combination of Content-Type parsing and sniffing some initial set of bytes of the response.

If we feed a response into some subsystem without any kind of validation it would be good to know whether the subsystem performs validation and what that might be.

I'm further assuming that range responses cannot be made without first confirming the type of the resource somehow.

(To be clear, this is only about audio/video elements as those are the only contexts that can fetch and render responses that are otherwise opaque to the page; i.e., "no-cors" cross-origin requests that result in opaque responses.)

Back to Bug 1532646 Comment 0