W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2005

[whatwg] web-apps - TCPConnection

From: Ted Goddard <ted.goddard@icesoft.com>
Date: Thu, 27 Oct 2005 15:38:55 -0600
Message-ID: <C4855C9F-FF08-4397-82ED-D520C0CF3AA0@icesoft.com>

On 26-Oct-05, at 12:17 PM, Ian Hickson wrote:

> On Mon, 17 Oct 2005, Ted Goddard wrote:
>> Rather than invent another protocol, this seems like an
>> excellent application for BEEP:
>> http://www.ietf.org/rfc/rfc3080.txt
> Good lord, that protocol is FAR more complicated than it needs to  
> be. And
> it doesn't address several of the security issues that are critical  
> here,
> such as severly limiting what the initial packets can contain, and
> ensuring that the remote host is expecting a connection initiated  
> by a Web
> page of the specified domain.

It may be a bit complicated, but BEEP is well suited to exchanging
messages over a variety of transports.  The flow control mechanism
proposed in doesn't allow for pipelining, for instance
(remember kermit?).

Mike Dierken proposed an HTTP server in the the UA.  If BEEP is too
complex, at least a pair of HTTP connections could be effectively
used for messaging, and would use a well defined protocol with readily
available and mature implementations.   Providing a back-channel to
the browser will revolutionize web applications, so it's worth making
fairly robust.

>> Restricting connections to the originating host only has shown
>> to be fairly effective so far, and it's quite easy to see how
>> allowing arbitrary connections (no matter what port they are on)
>> could be used to stage attacks on remote servers.  Are connections
>> to arbitrary hosts worth the risk?
> With the protocol as currently designed, connections can only be
> established to hosts that are expecting connections from the page's
> domain, which massively minimises the risk. (At the moment, it isn't
> possible to connect to remote hosts from other domains anyway, but I
> imagine we'll relax this in due course.)

DNS spoofing aside, that's reasonable ... Broadcasting over TCP/IP

IP Multicast would allow multiple UAs on the same host to interact.
In particular, this would allow the technology to be demonstrated
on a standalone laptop ...  How about IP multicast rather than
UDP to

Received on Thursday, 27 October 2005 14:38:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:43 UTC