RE: Agenda, 5 June 2014 SVG WG / WebAppSec WG telcon

Hi Brad, Erik, all,

On  Wednesday, June 04, 2014 3:55 PM
Hill, Brad wrote: 
-----------
By way of context for the SVG folks:

CSP is "Content Security Policy".

http://www.w3.org/TR/CSP
and
http://www.w3.org/TR/CSP11

In short, CSP allows setting a policy in an HTTP header that determines
things like where a resource may load other resources from, and whether
certain features like inline scripting, inline css and eval() are allowed.
It's goal is to reduce the damage that content injections (like XSS) can do.
------------

This morning, after seeing your note about CSP, I googled it and found a
couple of different meanings in computing, but rapidly converged on the
relevant one;)

I looked, with my typical naiveté at the mission of the CSP WG and generally
got the idea that the interest is more in shoring up security than in
enabling new capabilities, but there are a couple of things I wonder if
could possibly be considered as a part of the interaction (which I
understand could be quite interesting) between SVG and other things.

Might these topics be within the scope of discussion? I am not really
suggesting that they should be since I know how charters and the like make
the Matryoshka dolls that are web specs (much to the delight of those who
have the keys) canonically compartmentalized and optimally orthogonal (in
the sense of Ulam, Voronoi, Lobachevsky and Euclid). No, I'm just asking if
this is part of the envisioned realm of discussion. 

1. I gather that an SVG doc when loaded (as src) of an HTML <img> has its
script disabled for security reasons. But this is not true for <embed>,
<iframe> and <object>. In fact, my recent experiments suggest that if the
SVG contains script, then at least some browsers refuse to render it, not
merely disabling script, but going much further and declaring the entire
entity to be unsafe. Does that need to be?

2. Experiments that I did a couple of years ago failed when I tried to draw
SVG within <canvas>, thenceafter trying to read the pixels. I was told by
folks who apparently understand such things that that was by design: one
could use such a thing to intercept keystrokes and the like. On the other
hand, I thought I had good reasons to want to do it, and was later told by a
fellow with deep credentials in SVG that he was doing it. Sorry for the
sketchy details... I would have to do more homework to present more clarity.

3. I have recently been trying to use code involving
window.URL.createObjectURL(files[0]); to allow users to incorporate local
imagery into an svg app. It's something I used to do back more than a decade
ago when the term "web application" was viewed by many as an oxymoron. It
works fine, again now, I'm happy to say (after years of being disabled for
security reasons), but when I then try to serialize the user's resultant
work, to save it as an SVG doc, I wanted to rewrite the blob obtained by the
local file upload with a reference (other than the blob id) so that the
resultant doc might then load into a browser and work --
svgimage.setAttributeNS(xlink,"xlink:href",localfilenamewithoutpath). It
seems that my attempt to do this has been anticipated and pre-empted by
someone very vigilant to make sure I don't do anything naughty. 

I guess, in addition to these sorts of little questions, the bigger question
would be whether the aim is to enable good stuff currently blocked as well
as to clamp down on bad stuff currently enabled?

I must say by way of offering ammunition to the clamping side of such
discussions, that I've been rather amazed and pleased at how many things
work, as within iframes (with either SVG or HTML) inside of foreignObjects
inside of SVG inside of HTML [1,2]. Usually when I get excited by new
capability it means that there is something dreadfully wrong;)

Cheers and regards,
David

[1] http://cs.sru.edu/~ddailey/fading/slides/SVGoverIframe2.htm 
[2] http://cs.sru.edu/~ddailey/fading/slides/SVGforeignObject2.htm

Received on Thursday, 5 June 2014 03:03:44 UTC