- From: Simon Pieters <simonp@opera.com>
- Date: Wed, 21 Oct 2015 14:35:11 +0200
- To: public-texttracks@w3.org
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
Received on Wednesday, 21 October 2015 12:33:03 UTC