- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Thu, 26 Mar 2015 21:35:53 -0700
- To: Stephen Chenney <schenney@chromium.org>, Doug Schepers <schepers@w3.org>
- Cc: David Dailey <ddailey@zoominternet.net>, www-svg <www-svg@w3.org>, Chris Lilley <chris@w3.org>
On 03/26/2015 08:48 PM, Daniel Holbert wrote: > (One scenario I've thought of, which might be what you're getting at > [please bring up other scenarios though]: some interactive user-provided > SVG content, where if you click just the right spots, some horrifically > obscene picture pops up. This is a problem, though it also seems like > it could be a problem for e.g. animated GIFs or simple animated SVG or > video -- some arbitrary frame of the animation/video could have the same > obscene content. I'll grant that it may be more discoverable via > automated tools in these non-interactive formats, though. (to the extent > that your tools can actually tell that it's obscene.) One other trick in this category -- even with static SVG, a sneaky user could sneak something objectionable past automated filters & human content-screeners using CSS media queries in their SVG. They could use a media query to control whether a piece of content is visible, based on the viewport-size (which I think would translate to the image's size), or something else that can vary between the content-screener's environment & the actual-site-on-a-particular-user's-device. I think this is somewhat similar to burying an image at frame N of an animated GIF (where N is huge), so it's not entirely a problem that's new when you introduce SVG. But I'll grant that tools can probably scan GIF-frames more trivially than they can probe the entire space of media-query-influenced renderings.
Received on Friday, 27 March 2015 04:36:24 UTC