<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2800.1555" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV>
<DIV><FONT face=Arial size=2>Hi Shannon,</FONT></DIV>
<DIV><FONT face=Arial size=2><FONT face=Arial size=2></FONT></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT face="Times New Roman" size=3>[It's hard to
determine the substance of your complaint. It appears you don't really
understand the Java, Flex or Silverlight implementations. They are all quite
restrictive, just in different ways:]</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT face=Arial size=2></FONT></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT face="Times New Roman"
size=3>Perhaps but they do not place restrictions/preconditions on the
content and format of what goes up and down the socket! </FONT></DIV>
<DIV> </DIV>
<DIV>[* Java raises a security exception unless the user authorises the socket
using an ugly and confusing popup security dialog]</DIV>
<DIV> </DIV>
<DIV>Oh really? Vista settings? New with Java 6_10? You may recall that in my
previous post, I gave links to two examples of a Java Applet that uses TCP
Sockets to communicate back to the codebase: -</DIV>
<DIV> </DIV>
<DIV>> <A
href="http://manson.vistech.net/t3$examples/demo_client_flex.html">http://manson.vistech.net/t3$examples/demo_client_flex.html</A><BR>>
<A
href="http://manson.vistech.net/t3$examples/demo_client_web.html">http://manson.vistech.net/t3$examples/demo_client_web.html</A><BR>>
<BR>> In both cases the Username is TIER3_DEMO and the password is
QUEUE.<BR>> <BR>> Obviously, you can "view source" for the HTML and
Javascript and the Java<BR>> Applet and MXML source can be found at<BR>>
<A
href="http://manson.vistech.net/t3$examples/">http://manson.vistech.net/t3$examples/</A><BR></DIV>
<DIV>Which one(s) raised the pop-up dialog and on what
Browser/OS/Settings?<BR><BR>[* Flex and Silverlight requires the remote server
or device also run a webserver (to serve crossdomain.xml). Flex supports
connections ONLY to port numbers higher than 1024.]</DIV></FONT>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Sure, and Silverlight will only let you connect to
a very narrow range of port numbers. There are many restrictions and
idiosyncrasies but, again, not on content. Look I don't like the fact that Flex
doesn't support UDP, or connection timeouts, or the OOB character which is why I
personally use Java Sockets and the FABridge to channel data too/from Flex for
presentation; but I'd much rather do it straight from
HTML/Javascript/WebSockets.</FONT></DIV>
<DIV><FONT face=Arial size=2><FONT face="Times New Roman"
size=3></FONT></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT face="Times New Roman" size=3>[The
crossdomain files for each platform have different filenames and appear to
already be partly incompatible between the two companies, hardly a
"standard".]</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT face="Times New Roman"
size=3></FONT></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT face="Times New Roman" size=3>Unlike one of
the many standards (and numerous implementations of) which can be found with
HTML, DOM, Javascript. . .please!</FONT></DIV>
<DIV> </DIV>
<DIV>[As someone who works in an ISP I assure you this is an incorrect
assumuption. Many ISPs run additional services on their webserver, such as
databases and email, to save rack hosting costs or for simplicity or security
reasons. I would not want one of our virtual hosting customers authorising web
visitors access to those services.]</DIV>
<DIV> </DIV>
<DIV>Different strokes for different folks eh? One size not necessarily fitting
all? Everyone else not in your boat?</DIV>
<DIV> </DIV>
<DIV>[It is also fundamentally flawed to assume services on ports greater than
1024 are automatically "safe".]</DIV>
<DIV> </DIV>
<DIV>I certainly agree, but if JAR or SWF file is connecting back to the
codebase/same-origin then what is the problem? Or if the System Manager at the
target node has authorized connections from Applets hosted on one of his
seperate sub-domains then what is the risk in that? (Apart from him perhaps
declaring his trust for code that he simply shouldn't)?<BR><BR>[Both Silverlight
and Flash/Flex are fundamentally flawed since they run on the assumption that a
file hosted on port 80 is an authorative security policy for a whole
server.]</DIV></FONT>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Maybe port level granularity would have been a
useful configuration option. But for two products that you have deemed
fundamentally flawed, they have gained a fair bit of traction. (And, unlike
WebSockets, they're out there. For better or worse.)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV>[These companies chose convienience over security, which quite frankly is
why their software is so frequently exploited. ]</DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Again, unlike the rock-solid, vulnerability-devoid
HTTP, HTML, DOM, Javascript. . .?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT face="Times New Roman" size=3>[However that's
between them and their customers, this group deals with standards that must be
acceptable to the web community at large.]</FONT><BR></FONT></DIV>
<DIV><FONT face=Arial size=2>Presumably the relevance of these "standards" is
also of some issue to "the web community at large"? </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Anyway, good luck with that Genie/Bottle standard.
(Put it in formaldehyde and it'll sell :-)</DIV></FONT>
<DIV> </DIV>
<DIV>[If you are worried about the complexity of implementing the server end of
the service I can't see why, it's about 3-6 lines of output and some reasonably
straight-forward text parsing. It could easily be done with a wrapper for
existing services.]</DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Yes, I agree it's more inconvenient than
debilitating, but needlessly so.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT face="Times New Roman" size=3>[Other than
that it behaves as an asynchronous binary TCP socket. What exactly are you
concerned about?]</FONT><BR></FONT></DIV>
<DIV><FONT face=Arial size=2>Other than that, nothing.</DIV></FONT>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Cheers Richard Maher</FONT></DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=shannon@arc.net.au href="mailto:shannon@arc.net.au">Shannon</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=maher_rj@hotmail.com
href="mailto:maher_rj@hotmail.com">Richard's Hotmail</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=whatwg@lists.whatwg.org
href="mailto:whatwg@lists.whatwg.org">WHAT working group</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, September 22, 2008 12:09
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [whatwg] WebSocket support
in HTML5</DIV>
<DIV><FONT face=Arial size=2></FONT><BR></DIV><BR><BR>Richard's Hotmail wrote:
<BLOCKQUOTE cite=mid:BAY131-DAV959F02AF896D01F23C331FB480@phx.gbl
type="cite"><META content="MSHTML 6.00.2800.1555" name=GENERATOR>
<STYLE></STYLE>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>My particular beef is with the intended
WebSocket support, and specifically the restrictive nature of its
implementation. I respectfully, yet forcefully, suggest that the intended
implementation is complete crap and you'd do better to look at existing
Socket support from SUN Java, Adobe Flex, and Microsoft Silverlight before
engraving anything into stone! What we need (and is a really great idea) is
native HTML/JavaScript support for Sockets - What we don't need is someone
re-inventing sockets 'cos they think they can do it better.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Anyway I find it difficult to not be
inflammatory so I'll stop now, but please look to the substance of my
complaint (and the original post in comp.lang.JavaScript attached below) and
at least question why it is that you are putting all these protocol
restriction on binary socket support.</FONT></DIV></BLOCKQUOTE>It's hard to
determine the substance of your complaint. It appears you don't really
understand the Java, Flex or Silverlight implementations. They are all quite
restrictive, just in different ways:<BR><BR>* Java raises a security exception
unless the user authorises the socket using an ugly and confusing popup
security dialog<BR>* Flex and Silverlight requires the remote server or device
also run a webserver (to serve crossdomain.xml). Flex supports connections
ONLY to port numbers higher than 1024. The crossdomain files for each platform
have different filenames and appear to already be partly incompatible between
the two companies, hardly a "standard".<BR><BR>Both Silverlight and Flash/Flex
are fundamentally flawed since they run on the assumption that a file hosted
on port 80 is an authorative security policy for a whole server. As someone
who works in an ISP I assure you this is an incorrect assumuption. Many ISPs
run additional services on their webserver, such as databases and email, to
save rack hosting costs or for simplicity or security reasons. I would not
want one of our virtual hosting customers authorising web visitors access to
those services. It is also fundamentally flawed to assume services on ports
greater than 1024 are automatically "safe".<BR><BR>These companies chose
convienience over security, which quite frankly is why their software is so
frequently exploited. However that's between them and their customers, this
group deals with standards that must be acceptable to the web community at
large.<BR><BR>The current approach the HTML spec is taking is that that policy
files are essentially untrustworthy so the service itself must arbitrate
access with a handshake. Most of the details of this handshake are hidden from
the Javascript author so your concerns about complexity seem unjustified. If
you are worried about the complexity of implementing the server end of the
service I can't see why, it's about 3-6 lines of output and some reasonably
straight-forward text parsing. It could easily be done with a wrapper for
existing services.<BR><BR>Other than that it behaves as an asynchronous binary
TCP socket. What exactly are you concerned
about?<BR><BR>Shannon<BR></BLOCKQUOTE></DIV></BODY></HTML>