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
<use/> element.
Thank you for considering my feedback.
Andreas
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
common.
* 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
unstable
* 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.
Thoughts?
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
--
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093 Zurich, Switzerland
Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: [EMAIL PROTECTED]
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
