Hi Charlie,

I was hoping you could help me find an appropriate person to triage this bug.  I'm not sure what component/area it would fall under.

Thanks much!

Dale, do you know who's working on <track> captions?

I'm not sure it makes sense for CSP to override any requirements we have for `crossorigin`. The two are completely orthogonal, and CSP does not aim to grant any ability to the page that it doesn't already have (quite the opposite).

In other words, per current specs, this is a feature request and not a bug?

All I'm saying is that if `<track>` requires `crossorigin` on the parent `<video>`, then adding its URL to CSP's whitelist should now and will not bypass that requirement.

I don't know enough about `<track>` and `<video>` to say whether the `crossorigin` requirement itself makes sense.

The spec for this is https://html.spec.whatwg.org/multipage/embedded-content.html#start-the-track-processing-model and to the best of my knowledge it makes sense. IIRC, it seemed like overkill to add a separate crossorigin attribute to the track element itself, so that's why the video element's attribute is used.

I'm not sure if there are bugs in how the crossorigin attribute is handled for the media resource itself. kyvago@, you wrote "<track> src is denied due to lack of the crossorigin attribute on the parent <video>, while the <source> src from the same 3rd party site is allowed." Is the fact that the behavior is different what caused you to notice this?

The seemingly inconsistent implementations of this between Firefox and Chrome are what made me notice this. It appears Firefox is the one not up to date with the current spec. I also saw an additional line from
https://www.w3.org/TR/html5/embedded-content-0.html
"The resource obtained in this fashion, if any, contains the text track data. If any data is obtained, it is by definition CORS-same-origin (cross-origin resources that are not suitably CORS-enabled do not get this far)."

It does baffle me how forcing <track> to be CORS-enabled makes sense over either CSP directives or the upcoming integrity attribute. The end result on the clientside wanting accessibility is a prohibitive standard for those servers either unconfigurable to be or just not CORS-aware.

But that's a spec issue so this bug is invalid.

Note that https://www.w3.org/TR/html5/embedded-content-0.html is not up to date, currently the only HTML spec that's actively maintained when it comes to details and algorithms of this sort is https://html.spec.whatwg.org/ (Disclaimer: I'm one of the editors.)

I'm not sure what the current state of implementation here and can't say I'm certain that the spec makes sense, although I suspect it does. Can you file an issue at https://github.com/whatwg/html/issues if you have some specific change in mind and mention @foolip (me)?

https://github.com/whatwg/html/issues/995

Renamed Blink>Text>Track to Blink>Media>Track. Moving these bugs to the new component.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot