W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: SVG 1.2 Comment: B.2.3 Socket Connections

From: Denis Bohm <denis@fireflydesign.com>
Date: Wed, 3 Nov 2004 20:44:02 -0800
Message-ID: <001901c4c229$1de4fb50$71307f42@DRAGONFLY>
To: "Boris Zbarsky" <bzbarsky@MIT.EDU>
Cc: <www-svg@w3.org>


----- Original Message ----- 
From: "Boris Zbarsky" <bzbarsky@MIT.EDU>
To: "Denis Bohm" <denis@fireflydesign.com>
Cc: <www-svg@w3.org>
Sent: Wednesday, November 03, 2004 8:25 PM
Subject: Re: SVG 1.2 Comment: B.2.3 Socket Connections


> 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.

If there is a hole where remote users can attack a machine, then that
problem exists independently of any web applications.

> > 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...  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?

That is where the security model in the UA comes into play.  For example, in
Java unsecured applets can only connect back to their originating host.  If
the user approves it then it can allow connections to other hosts.  The user
is controlling the application.  It's no different than running any other
application on their computer - actually it's safer because the UA is making
sure the user is aware of the applications request to connect to another
computer.  So I don't see a problem.  This has already been thought out in
other contents and the SVG interfaces don't introduce any new issues.
Received on Thursday, 4 November 2004 04:46:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC