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

On Wed, Jun 23, 2010 at 9:49 PM, Doug Schepers <schepers@w3.org> wrote:

> SVG2 seemed like a good place to solve that, because we could look at that
> class of security risk more comprehensively, and come up with a robust and
> broad solution.  I also don't want to hold up the SVG 1.1 SE publication,
> because it needs to be finished so we can move on to more pressing matters;
> we know there are still outstanding issues in SVG 1.1 which the 2nd edition
> doesn't deal with, but SVG 1.1 SE is not meant to be definitive... it's a
> snapshot that incrementally improves SVG 1.1, and we will have to keep
> maintaining SVG 1.1 for a long while, even as we move forward on SVG2; this
> is only the first of a series of updated editions of SVG 1.1.
>

Yeah, but this is not just any old issue. This is a security issue and it
involves features that Web browsers are implementing.

I do recognize the importance and urgency of this issue, though.  So, here's
> my proposal for resolving it:
> * we publish SVG 1.1 Second Edition as is
> * we immediately begin work with browser vendors and security experts to
> find a reasonable solution for ISSUE-2071 that doesn't cripple content
> authors while plugging the security hole
> ** we publish a new errata for SVG 1.1 SE, putting forth a proposed
> solution, which will ultimately be published as SVG 1.1 3rd Edition
> ** we include the solution in early drafts of SVG2
>
> We could do this over the next couple months, I think.  I will put a
> priority on it, personally.  How does that strike you?
>
> [1] http://www.w3.org/2005/10/Process-20051014/tr.html#correction-classes
>

That would be adequate. However I think if we just had a discussion right
now, we could get a solution right now and put it in SVG 1.1 2nd Edition. I
don't think minimizing "class 3" issues should be a goal in itself;
minimizing incompatible changes certainly should be a goal, but here we have
a situation where we clearly do need to make an incompatible change. Right
now we can probably still make a change that would be incompatible with the
previous spec but compatible with all shipping implementations, but that
window of opportunity could close anytime.

Here's a proposal:
1) 'pointer-events:painted' should treat images with a different origin to
the containing document as completely opaque.
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.

Rule 1 prevents leaking information about the contents of images from other
origins. This is actually a different problem to the one I raised, but it's
serious (e.g. for <canvas> we have a taint flag that blocks recovery of
other-origin image data).

Rule 2 prevents leaking information about the contents of resources from
other origins.

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.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]