Closed Bug 1439463 Opened 6 years ago Closed 9 months ago

Preload as=track treated as "optionally blockable" by the Mixed Content Blocker

Categories

(Core :: DOM: Security, enhancement, P3)

enhancement

Tracking

()

RESOLVED DUPLICATE of bug 1819898

People

(Reporter: jkt, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: good-first-bug, Whiteboard: [domsecurity-backlog2])

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)?
Flags: needinfo?(tanvi)
Summary: Preload track isn't caught by the Mixed Content Blocker → Preload as=track treated as "optionally blockable" by the Mixed Content Blocker
I don't have an answer here, and would have to dig into it.  Jonathan, if you have an opinion, please chime in.
Flags: needinfo?(jkt)
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.
Flags: needinfo?(tanvi)
Priority: -- → P3
Whiteboard: [domsecurity-backlog2]

We instead should block on type TYPE_INTERNAL_TRACK when checking the load info in the MCB as we don't want to be losening the MCB. Chrome and the standard won't be changing around this.

Flags: needinfo?(jkt)
Keywords: good-first-bug
Severity: normal → S3

Should have been closed through bug 1819898.

Status: NEW → RESOLVED
Closed: 9 months ago
Duplicate of bug: 1819898
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.