- From: Chris Lilley <chris@w3.org>
- Date: Sat, 4 Mar 2006 13:21:40 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: www-svg@w3.org, Jeff Schiller <codedread@gmail.com>
On Friday, March 3, 2006, 9:01:03 PM, Maciej wrote: MS> On Mar 2, 2006, at 10:14 PM, Chris Lilley wrote: >> On Thursday, March 2, 2006, 6:18:15 PM, Maciej wrote: >> MS> On Mar 2, 2006, at 6:39 AM, Chris Lilley wrote: >>>> Hello www-svg, >>>> Jeff Schiller <codedread@gmail.com> wrote: >>>>> I'm no security expert, but what about a script that requests a >>>>> connection to the localhost on various ports (i.e. FTP 21, etc) and >>>>> sniffs about the local host, then sends the data it finds back >>>>> to the >>>>> server through standard ports? Would that effectively open up your >>>>> computer by bypassing any firewall since the "attack" would come >>>>> from >>>>> within the localhost browser or do firewalls watch for that sort of >>>>> thing too? >>>> There are a number of different security models that might be >>>> used by >>>> different types of svg implementations. For example,[...] >> I encourage you to re-read this part. MS> I think there are 0 different security models that could safely be MS> used by a browser-hosted implementation of SVG that includes Connection. >> MS> As mentioned before on this list, this model is insufficient for a >> MS> raw socket API that is offered to arbitrary web content. >> MS> (1) The real restriction used by web browsers is not just host, >> but >> MS> host+port +scheme. (2) >> Yes, that would be another example. It does of course allow access >> to a >> range of other protocols, especially when used with a widely tunnelled >> port such as 80. MS> You took my remarks out of context. I was explaining reasons why your MS> proposed security model I don't propose a model MS> that a web browser might use would not in MS> fact be secure. The fact that browsers are more restrictive than your MS> proposed model for access methods other than Connection is one piece MS> of supporting evidence for why your proposed model I don't propose a model MS> won't work. But I MS> also mentioned in my point (2), which you omitted, that raw socket MS> access has additional security issues that even the narrower browser MS> access control model would not address. MS> You attempted to dismiss Jeff's security concerns, No, I attempted to discuss them with a range of example security models while being very clear that none of these models was mandated. MS> but in fact MS> security concerns about Connection are entirely valid. Your suggested MS> model I don't suggest using a particular a model MS> for web browsers is not Safe. >> MS> I think it is unwise to specify networking APIs for the web >> without >> MS> properly addressing the security considerations. >> So on the one hand you list an additional security model, >> demonstrating >> the point that there are a variety of models that may be used >> depending >> on circumstance; and on the other hand you seem to want one specific >> security model to be mandated? MS> Please don't put words in my mouth. I did not ask to mandata a MS> security model. Nor did I list an "additional" security model. Your MS> proposed model does not work, I am not trying to put words in your mouth. However, on that note, please be aware that I am explicitly not proposing a security model - either one model, or a list of allowd models.Your multiple references to "my proposed" model are, therefore, assigning to me a position that I have not taken. (Or putting words into my mouth, if you like). MS> and my point (1) was not intended to MS> state a model that works, but rather to illustrate flaws in your model. Since I don't propose a model, security being an orthogonal aspect, its not clear how you can find flaws in it. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Saturday, 4 March 2006 12:21:46 UTC