search

w3c / webappsec-mixed-content

WebAppSec Mixed Content
https://w3c.github.io/webappsec-mixed-content/
Other
12 stars 22 forks source link

Track being the only media type that is blocked #13

Closed RReverser closed 4 years ago

RReverser commented 7 years ago

On Twitter, I mentioned that there is some disagreement between Firefox and Chrome on which <link /> items are supposed to be blocked, in particular <link rel=preload as=track /> as an example where Firefox issues a warning as for any other passive content, but Chrome strictly blocks it.

Both @wanderview and @mikewest said that this is a bug in Firefox as per current spec (tracks should be blocked), but I expressed a concern that blocking track whereas any other media content (audio, video, ...) is allowed with a warning seems to disproportionally harm people with hearing disabilities.

@mikewest suggested raising an issue to discuss this, as it makes sense to group all the media content together and either block it all or not block any of it.

wanderview commented 7 years ago

Oh, I just assumed @mikewest was right and was asking to get a bug on file. Sorry for the confusion.

annevk commented 7 years ago

The main problem with track is that it's a CORS fetch and therefore the embedder gets access to its data. That's more severe than displaying rogue pixels as it can compromise the behavior of the embedder.

The fair solution would be to also block audio and video mixed content, but I'm not sure how feasible that is. I don't think it's ever acceptable to open up track.

RReverser commented 7 years ago

@annevk That sounds somewhat similar to image- or video-to-canvas situation, couldn't the track content be inaccessible only when used programmatically but not when displayed? Or would it put unnecessary burden on implementors given that the plan is to block all the new-ish media elements in future?

RReverser commented 7 years ago

As for video/audio - it would indeed be interesting to see stats for it. Given that they are mostly used on a relatively recent websites (last few years), perhaps it could work out with a smooth upgrade path (e.g. allow user to unblock such insecure content with a warning in the meanwhile).

annevk commented 7 years ago

I think that would add quite a bit of complexity to the API at least, which doesn't seem worthwhile just for mixed content which should go away anyway, but I haven't investigated in detail.

mikewest commented 7 years ago

I agree with @annevk that we should not open up fetches that allow bits to flow freely from a non-secure origin to a secure origin. I think the answer here is going to be to more tightly restrict <audio> and <video> rather than loosening restrictions on <track>.

I plan to have a proposal in that regard ready for TPAC in ~2 weeks. I'll leave this open for some discussion at that meeting.

mikewest commented 4 years ago

Several years ago (!!!) we decided to close this at TPAC. The approach we're taking in MIX2 is to autoupgrade-or-block all mixed content to resolve the incoherence between these request types. See https://w3c.github.io/webappsec-mixed-content/level2.html.