Hi,
I know I've already replied to this post once, but I came across the following
link the other day and thought that it might help update some people, or at
least remove some misconceptions, about Policy Files for cross-domain Socket
access : -
http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html
It's dated 14 April 2008, and has some interesting stuff that I (and evidently
others) was not aware of: -
1) Port level granularity eg:
<allow-access-from domain="swf.example.com" to-ports="123,456-458" />
2) Standardizing a port number for the serving of policy files (Couldn't see
SSL option)
Adobe has filed with IANA, the Internet Assigned Numbers Authority, to reserve
port 843 for the purposes of serving socket policy files. By introducing a
centralized location for socket policy files, Flash Player enables a system
administrator to define what ports are available through one master policy that
overrides any other policy file on the host. If Flash Player 9,0,124,0 cannot
retrieve a master policy file from port 843, then it requests a socket policy
file on the port where it is trying to connect. However, if a policy file is
available from a service on TCP port 843, then Flash Player considers that to
be the authoritative set of permissions for that system.
3) Lots of other useful stuff that I feel the WebSocket people are dismissing
too lightly
I'm not saying that Adobe/Flex, SUN/Java, and Microsoft/Silverlight can't all
be wrong, but I just really hope that isn't one of these Web "standards" where
some one is being different just for the hell of it.
It's good to talk.
Cheers Richard Maher
----- Original Message -----
From: Shannon
To: Richard's Hotmail
Cc: WHAT working group
Sent: Monday, September 22, 2008 12:09 PM
Subject: Re: [whatwg] WebSocket support in HTML5
Richard's Hotmail wrote:
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.
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.
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:
* Java raises a security exception unless the user authorises the socket
using an ugly and confusing popup security dialog
* 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".
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".
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.
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.
Other than that it behaves as an asynchronous binary TCP socket. What exactly
are you concerned about?
Shannon
