- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 21 Oct 2015 15:00:30 +0200
- To: Simon Pieters <simonp@opera.com>
- Cc: "public-texttracks@w3.org" <public-texttracks@w3.org>
On Wed, Oct 21, 2015 at 3:00 PM, Simon Pieters <simonp@opera.com> wrote: > On Wed, 21 Oct 2015 14:52:18 +0200, Philip Jägenstedt <philipj@opera.com> > wrote: > >> 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. > > > background-image is in the whitelist. Oh, right, as part of "the properties corresponding to the background shorthand." If it's the only problematic property, explicitly excluding it would be fine I think. Philip
Received on Wednesday, 21 October 2015 13:01:00 UTC