Re: SVG 1.2 Comment: B.2.3 Socket Connections

At 10:25 PM 11/3/2004 -0600, Boris Zbarsky wrote:

>Denis Bohm wrote:
>
>>>The point is that once you've implemented this securely, it becomes less
>>>useful than URLRequest, since it can only access HTTP ports, but doesn't
>>>do HTTP. It seems bad to have a feature that is only useful if implemented
>>>in insecure ways.
>>I don't understand what your point is.  It seems to be that since some sites
>>will only allow HTTP requests that SVG should not implement a more powerful
>>network interface for anyone?
>
>Ian's point wasn't about sites but user-agents.  The point was that any 
>user-agent that does want to be used as an attack vector (thus possibly 
>opening its users up to legal action, as the attack will originate from 
>THEIR computer) will have to restrict this interface to HTTP requests or 
>otherwise severely limit its usefulness, to the point where it is no more 
>useful than existing methods of making HTTP requests, and possibly less useful.
>
>>The SVG socket interface is very useful as it allows two way asynchronous
>>communication.
>
>The problem is that it allows evil.com, say, to make it look like John 
>Smith, who was just looking at the nice SVG image on evil.com, was sending 
>spam through the mail servers run by randomisp.net...

But evil.com would have to hack randomisp.net site and inject its code 
there. Essentially, two things have to happen: hackable HTTP server and 
open SMTP server on the same machine. They do happen - and that is the 
problem, not Socket APIs.

>Since the socket connection is made from John Smith's machine, he could be 
>the one held responsible under the various anti-spam laws on the 
>books.  How do you envision UAs implementing this functionality without 
>causing problems like this for their users?

What if randomisp.net also allows sending mail through port 80 (Web Service 
or some sort of custom POST, etc)? Blocking ports on the client is not a 
good solution for broken server - it is a quick-and-dirty hack at best. You 
have to fix the server. (And good UA would allow you fine-grain security 
control, so you could configure access per server/signature basis). 
Quick-and-dirty solutions have their place, of course, - but that place is 
not in the standards - it is in UAs.

Peter


>-Boris

Received on Thursday, 4 November 2004 18:02:32 UTC