Re: SVGT 1.2: OriginalEvent underspecified; behavior could be a security risk

Hi Maciej,

We are following your recommendation and are removing the OriginalEvent
interface. The CDF group has decided that events do not propagate across
document boundaries in the CDR scenario. Since we want to align with CDR
we're removing OriginalEvent.

If you don't approve to this change please let us know

within 2 weeks.

 

Regards,

Ola Andersson

On behalf of the SVG WG

 
 
---
From: Maciej Stachowiak <mjs@apple.com
<mailto:mjs@apple.com?Subject=Re%3A%20SVGT%201.2%3A%20OriginalEvent%20un
derspecified%3B%20behavior%20could%20be%20a%20security%20risk&In-Reply-T
o=%253C5C47B355-C485-497B-97CA-E11A0F139EF6%40apple.com%253E&References=
%253C5C47B355-C485-497B-97CA-E11A0F139EF6%40apple.com%253E> > 
Date: Tue, 27 Dec 2005 00:25:09 -0700
Message-Id: <5C47B355-C485-497B-97CA-E11A0F139EF6@apple.com> 
To: www-svg@w3c.org
<mailto:www-svg@w3c.org?Subject=Re%3A%20SVGT%201.2%3A%20OriginalEvent%20
underspecified%3B%20behavior%20could%20be%20a%20security%20risk&In-Reply
-To=%253C5C47B355-C485-497B-97CA-E11A0F139EF6%40apple.com%253E&Reference
s=%253C5C47B355-C485-497B-97CA-E11A0F139EF6%40apple.com%253E>  
 
 
CONFUSION
 
The OriginalEvent interface is confusing as specified. Here are  
things I did not get:
 
1) The description says events can be dispatched to  
SVGElementInstance objects referenced by the supported <animation> or  
<foreignObject> element. However, from the rest of the spec it sounds  
like only <use> elements create SVGElementInstance objects. What  
SVGElementInstance objects is it talking about here?
 
2) The spec says "UI events that are dispatched to these  
SVGElementInstance objects can bubble up to the supported element.  
Upon bubbling to the supported element, the User Agent must  
manufacture new Event and OriginalEvent objects." OK, so which of  
these now three objects (the original event, the new copied event,  
and the OriginalEvent object) is the one bubbled? What is done with  
the manufactured element?
 
3) "The new OriginalEvent object must set the originalEvent attribute  
to the original event object." - so this means the actual original  
event, not the copied one?
 
4) Are the Event and OriginalEvent interfaces actually supposed to be  
on the same object? That would kind of make sense, but that doesn't  
sound like what the spec is saying. Perhaps the intent is that there  
is in fact a MouseOriginalEvent interface which inherits from  
OriginalEvent and MouseEvent, and so forth?
 
5) How would any of this work with full DOM UAs that support capture?  
Should events also support capture across external reference boundaries?
 
Someone who understands what this section is trying to say needs to  
rewrite it to make sense.
 
SECURITY ISSUES
 
Furthermore, it seems to me that cross-inclusion bubbling of events  
could be a security risk, when used across domains. At least reading  
this naiively, you could pull off exploits like this:
 
* Include a web page from a different web server in a full-window  
foreignObject and install a keyboard/mouse sniffer on it to see what  
the user is typing into a seemingly other site.
 
* Get access to elements of the foreign document via  
event.originalEvent.target and so forth, and then use DOM APIs to  
inject content into the foreign document.
 
Is it really necessary to provide cross-domain bubbling like this? It  
seems like the right way to deal with this is to provide  
contentDocument attributes on any element that can attach foreign  
content, subject to the typical security restrictions, then you can  
attach any event handlers you want, whether capturing or bubbling or  
what have you.
 
Therefore I recommend removing this feature and instead providing  
contentDocument attributes for foreignObject and animation (or  
skipping over cross-document inclusion issues for now and let the CDF  
WG handle it).
 
Regards,
Maciej