[webkit-dev] SVG Stabilization
neumann at karto.baug.ethz.ch
Tue Feb 20 01:12:38 PST 2007
Hello Maciej and others,
I am not a Webkit SVG developer, but a SVG developer and webkit user. I
think it is important that SVG is turned on in Webkit. The main reason
that SVG isn't widely used today is the fact that some major browsers
don't support it. So please turn it on but disable experimental features.
From your list in 1) I agree that SVGImage, Animation, Filters and
ForeignObject probably need more effort and testing and they are
candidates to be disabled. This also matches what Firefox can do today.
However, the support of the <use/> element is very important. <use/> is
widely used in SVG content out there and I would welcome it if it could
make it into the next main Webkit version, even if this means additional
efforts from your side. I volunteer to do testing regarding the <use/>
element. Webkit would be the only major browser/UA that doesn't support
<use/>, which would be limiting content wise. This doesn't mean that
<use/> is correctly implemented everywhere.
Regarding 2) I also volunteer to do more testing. What is the timeframe
for releasing webkit? When do you need the testing? I guess ASAP? There
will also be more test cases in the upcoming SVG testsuite regarding the
Thank you for considering my feedback.
Maciej Stachowiak wrote:
> Hi Everyone,
> As part of our stabilization effort, SVG has been raised as an area
> of concern. Some of the newer SVG features have been sources of
> crashes, some of which could potentially be security issues (the ones
> that are buffer overruns).
> Specifically, here are some of the risks we see from SVG in our
> current state:
> * Non-security hole crashes in normal SVG content on the web - may
> affect user perception of quality, but SVG content is not yet very
> * Security holes - potentially exploitable buffer overruns and such.
> These are really bad, because anyone that shipped an engine exposing
> these would be forced to issue high priority security updates as they
> get discovered. SVG content being relatively rare will not help
> * Sites developing a dependency on WebKit-specific SVG bugs - we are
> not as worried about this, since there are a number of other SVG
> implementations out there, and Gecko at least has more market share.
> To address these concerns, a few of us came up with a plan which I'd
> like to propose now for discussion. I would especially like to hear
> from WebKit SVG hackers on this.
> 1) Disable newer/experimental features (we'd probably guard these
> with a single SVG_EXPERIMENTAL_FEATURES ifdef)
> * SVGImage -- already disabled
> * Animation -- not tested anywhere enough yet, and still noticably
> * Filters -- still unstable, and can cause problems with buggy
> graphics drivers which take down the whole machine
> * Use -- untested/unstable
> * foreignObject -- might have issues with html inside svg,
> particularly for hit testing, etc
> 2) Additional testing
> * Fuzz-test for custom parsers - the biggest security risk is
> buffer overruns in some of the custom parsers, so we'd like to
> develop a fuzz-testing tool for attributes that trigger these, and
> fix resulting crashes.
> * XSS testing - SVG has many elements that reference external
> content, these should be tested for cross-site scripting risk.
> * Additional ad-hoc testing - we will need community help with this
> * Look into generating new results for pixel tests and keep them
> passing, once experimental features are off on trunk.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
Institute of Cartography
CH-8093 Zurich, Switzerland
Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann at karto.baug.ethz.ch
More information about the webkit-dev