- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 7 Jul 2010 21:27:40 +0200
- To: Doug Schepers <schepers@w3.org>
- Cc: Thomas Roessler <tlr@w3.org>, robert@ocallahan.org, "www-svg@w3.org" <www-svg@w3.org>
Doug, reviewing the discussion, it sounds like you're dealing with a violation of a relatively important instance of the same origin policy. So this is indeed an issue that's worth addressing quickly, given increasing deployment of SVG. I don't know enough about SVG's details to give you a full assessment of the proposed solution; however, it seems to me that the basic approach -- i.e., any mechanism that knows how to read pixel values will fail (or return a fixed value) for any pixel that's under a different origin's control -- is the right direction to go into. -- Thomas Roessler, W3C <tlr@w3.org> (@roessler) On 24 Jun 2010, at 01:49, Doug Schepers wrote: > Hi, Thomas- > > We have an issue with some SVG functionality that we are trying to close in on an erratum for, possibly in SVG 1.1 SE. > > The issue is here: > http://www.w3.org/Graphics/SVG/WG/track/issues/2071 > > ROC proposes a solution below, and I wondered if we could get your assessment of the threat and of the solution. If you need more details, I will be happy to schedule a call with you. > > Regards- > -Doug Schepers > W3C Team Contact, SVG and WebApps WGs > > > Robert O'Callahan wrote (on 6/23/10 10:54 PM): >> On Wed, Jun 23, 2010 at 9:49 PM, Doug Schepers <schepers@w3.org >> <mailto: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] > > -- >
Received on Wednesday, 7 July 2010 19:27:43 UTC