Re: Inline style: external resources

At the recent foms, Loretta and Ken raised @import as an issue for YouTube
as well, since a WebVTT import at upload time would then need to fetch
potentially more style files to resolve all styles. I think excluding these
extra fetches will address their issues.

Best Regards,
Silvia.
On 21 Oct 2015 11:33 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
> --
> Simon Pieters
> Opera Software
>
>