Loading: <link rel=preload as=track src=http://... /> is permitted. I didn't have a CORS permitting WevVTT file to hand to test if this is the case, however I assume it is. Source: https://twitter.com/RReverser/status/917742809226141696

I haven't tried this either, but I assume you mean "treated as optionally blockable/passive". The tweet says there was a warning. But this is also "preload" which is _not_ in the document (yet). Maybe we warn on the preload (because cookies were sent, it was loaded, but it can't corrupt the document) and then come around later if the track is actually loaded in the document and block it? I have two questions here that are unanswered. The tweet jkt links to led to a github issue that has nothing to do with preload, but is about whether track ought to be blocked or not differently from the media it's loaded with. https://github.com/w3c/webappsec-mixed-content/issues/13 -> Do we treat "track" according to the spec and block it? (secondary, need to resolve that github about whether the spec should be changed) -> Do we honor the "as" part of <link rel=preload>, or are we just treating them all the same (and apparently, as passive content)?

I don't have an answer here, and would have to dig into it. Jonathan, if you have an opinion, please chime in.

So we do appear to support "as=track" from bug 1222633. TYPE_INTERNAL_TRACK is eventually traslated to TYPE_MEDIA which we treat as optionally blockable (matching the symptoms in this bug). If the spec says otherwise than that's where the bug is.