1532646 - Produce the algorithm that determines whether something is a media resource

Status: NEW

(Core :: Audio/Video, enhancement, P3)

Description

[Anne (:annevk)]

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.)

Comment 1

[Tom Tung [:tt, :ttung]]

It seems this is the code for Media sniffing: https://searchfox.org/mozilla-central/rev/c7cf087b6e1384608ca3989f042f12f7cabd0a5f/toolkit/components/mediasniffer/nsMediaSniffer.cpp#140

Looks like necko sniffs the content at OnStartRequest

Comment 2

[Sean Feng [:sefeng]]

Paul, I did a comparison between our implementation and the spec https://mimesniff.spec.whatwg.org/#audio-or-video-type-pattern-matching-algorithm. I see a few patterns that we check, but the spec doesn't, like fLaC, M4V, M4A, and M4P. I guess there are probably reasons for them to be not included in the spec, so I think we likely don't need to do anything changes to the spec.

Do you mind confirm this?

Comment 3

[Paul Adenot (:padenot)]

No reasons that I know of, except that we simply haven't written the patches to the spec.