Hi, Andreas-
I agree that 'use' is very important, but would favor dropping it (for
now) rather than introduce a potential security hole in Safari. I don't
want people to get a bad taste for SVG, and I don't want people to
suffer for its inclusion.
I guess the pertinent questions are:
* Why is 'use' causing a problem? Is it buffer overrun? How exactly
can it be exploited? What would be the effect of the exploit? Is this
a crasher, or a security hole?
* Is there another way that 'use' could be implemented reasonably
quickly, which would cause less harm? MozSVG does a rather funky thing
with 'use' element; according to tor, by "doing an anonymous clone of
the referenced subtree". This causes some small CSS cascading problems
and is not according to spec, but seems like it would be easy and
secure, and would at least give almost all the functionality to authors.
* If 'use' is left out, when would be the next opportunity for inclusion?
Regards-
-Doug
> 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 at 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: neumann at karto.baug.ethz.ch
> www: http://www.carto.net/neumann/
> SVG.Open: http://www.svgopen.org/
> Carto.net: http://www.carto.net/
>
--
Regards-
-Doug
Research and Standards Engineer
6th Sense Analytics
www.6thsenseanalytics.com
mobile: 919.824.5482
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
