Re: Announcement: Last Call WD of SVG 1.1 Second Edition

On Wed, 23 Jun 2010 23:54:22 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> On Wed, Jun 23, 2010 at 9:49 PM, Doug Schepers <schepers@w3.org> wrote:
...
> Here's a proposal:
> 1) 'pointer-events:painted' should treat images with a different origin  
> to
> the containing document as completely opaque.

That sounds acceptable to me.

> 2) 'pointer-events:painted' should treat "mixed-origin" images as  
> completely
> opaque. A "mixed-origin resource" is a resource containing a subresource
> with a different origin to the resource itself, or a subresource that is
> itself mixed-origin.

I think you'd need to be much more specific about what consitutes a  
"mixed-origin resource". E.g if a stylesheet contained some cross-origin  
image url that wasn't used by the resource at the moment, would that be  
ok? How about a resource that once was mixed-origin and a script changed  
it to not be mixed-origin? I think the "tainting" model used by canvas in  
html5 isn't so bad, but it's a lot less complex since it deals only with  
raster images, not with the full mix of html, css and svg. Say for example  
that you have <xhtml:link> elements anywhere in the svg markup and that  
references something cross-origin. It's probably easier to restrict based  
on what's loaded from a given document, not by what's actually used in  
that document.

A suggestion would be to clarify that if an svg:image references an svg  
resource it's treated the same as the raster image case when it comes to  
pointer-events. And more specifically: there shall be no script execution  
in the referenced resource, and no interactivity inside the resource.  
Those restrictions are outlined in the SVG Integration module[1], and  
would map to either "Animated mode" (if we think animation is ok, like it  
is for html:img) or "Static mode".

Another solution would be to always treat referenced svg images as in rule  
1), and define a more advanced security model in a later version of the  
svg spec.

...
> The only spec difficulty I see here is defining exactly what the
> subresources of a resource are. However, it would be far better for a
> proposal like this to get into the spec ASAP even if it's not perfectly
> defined than to leave this issue completely unaddressed; the latter  
> would be
> a classic case of making the best the enemy of the good.
> We'll actually need to extend canvas with an analogue of rule 2 when we  
> add
> the ability to paint SVG images into the canvas; that's not your problem,
> but it means that even if this proposal isn't adopted for SVG, we'll  
> need to
> define something like "mixed-origin images" anyway.

Right, and to address that issue is one of the points with the SVG  
Integration spec.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Thursday, 24 June 2010 08:44:08 UTC