- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 01 Jun 2013 18:16:21 -0400
- To: Dirk Schulze <dschulze@adobe.com>
- CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
On 6/1/13 2:25 PM, Dirk Schulze wrote: > It can't for SVG Masks, SVG Filters and SVG Paint Servers (pattern, linearGradient, radialGradient). They just influence the visual appearance on the screen without read backs. I assume we're disregarding timing channel attacks for the time being, right? > The following example would NOT expose data: > <clipPath> > <text>Password</text> > </clipPath> Again, I'm more worried about stealing path data. Especially path data that's not necessarily meant to be a clipping path in the SVG being linked to. Is that something I should worry about, or only things that are explicitly inside <clipPath> elements in the target svg? If it's the latter, that helps a lot. > But the text can be transformed to a path (for instance with Illustrator). Then evil.com can clip an element with this resource and somehow try to get the hit regions (let the user move over the the object a lot of times like you would do on a lottery scratch ticket). Nah, you just use elementFromPoint from http://dev.w3.org/csswg/cssom-view/#extensions-to-the-document-interface and do whatever sort of sampling you want. > This would mean that mybank.com would not use a proper session management Huh? If you're logged into the bank at the same time as you happen to load an evil site, we need to worry about that. > The clip-path property does allow CSS Shapes as well: clip-path: polygon(…) [1]. This is very helpful for doing CSS animations or transitions on a clipping path. Do you think that could be a possible threat for privacy as well? As much as "must be inside <clipPath> SVG". -Boris
Received on Saturday, 1 June 2013 22:16:51 UTC