Re: Inline style: external resources

On Wed, Oct 21, 2015 at 2:35 PM, Simon Pieters <simonp@opera.com> wrote:
> As part of specifying inline style in WebVTT [1], it occurred to me that
> supporting @import and background-image in a WebVTT file is a new ability
> for <video> (when the video has in-band WebVTT) and <track>, namely that it
> can cause network requests (1) when the track is first loaded (with @import)
> and (2) whenever a new cue is rendered (with background-image). New ability
> for an HTML element on the Web translates to potential security problem.
>
> As a related case study, consider SVG in <img>: <img> has historically only
> supported raster image formats, which could not run scripts nor issue
> network requests, which led Web pages to assume that <img> can be trusted to
> not have side-effects (e.g. blogs and forums allow arbitrary external images
> to be embedded with <img>). When browsers wanted to support SVG in <img>, in
> order to not break that trust and expectation, support for scripting and
> external resources were turned off in SVG in <img>. This is now specified in
> https://svgwg.org/specs/integration/#secure-animated-mode
>
> I think <video> and <track> are in a similar position as <img>. It seems
> plausible to assume that embedding arbitrary video with captions would not
> have side-effects like pinging a server for each cue as the user watches the
> video.
>
> The obvious way to solve this is to disable external resources in STYLE
> blocks in WebVTT, until a secure way to allow external resources is found.
> So I propose that we do so. data: URLs can still be supported.
>
> [1] https://github.com/w3c/webvtt/pull/219

Not honoring @import sounds good to me, but for everything else I
guess the property whitelist should solve the problem? In some ad-hoc
testing it looks like @import really is blocked for SVG-in-<img>, so
however that works can hopefully be done for STYLE blocks in WebVTT as
well.

Philip

Received on Wednesday, 21 October 2015 12:52:46 UTC