Yes, earlier versions of the HyBi (websocket) protocol had
security problems (long since addressed) , and I would discourage
enabling of those versions in *public facing applications* ,especially
prior to the advent of data masking, unless one fully understands
and accounts for the issues with those early protocols.
Of course our goal in supporting older and non websocket protocols
in AsterClick has less to do with browsers and more to do with connections
with back end infrastructure, inter server communications and those
developers trying to make simple day to day connections with other
infrastructure
where neither the developer nor the other infrastructure knows
anything about HyBi.
We started the development of our infrastructure nearly two years
back when the websocket protocol was still largely just an idea, fully
knowing
that it was bleeding edge *ALPHA campaign* development and we would probably
get t-boned once or twice until the wire portion of the protocol stabilized.
In reality, things have turned out far, far ,far better than we expected
and really only a few items ever caused us to groan in all that time
1.) Handshakes - The little HTTP dance the server and client go
through
when "upgrading" from HTTP to HyBi or closing
the connection.
2.) Framing - The unseen gift wrapping each message between
the client and server is contained in.
3.) Funding - The donations that keep the computers both powered
and connected and the AsterClick team fed.
*Handshakes* : Almost any protocol involving ongoing communications
will have some
sort of opening dance, where the server and
client sort out the details
of a connection. We actually keep the
opening handshakes in
separate classes derived from a common base
so that if several versions
of a protocol share the same handshake
logic in spec they can do so in code.
This also means that for some back end
applications we can use
custom or abbreviated hand shakes or
dispense with them entirely
If I have a typical PHP,JAVA,C++ or other
developer working on perhaps
injecting a Jabber XMPP , RSS or other
source into AsterClick's
XML stream , I need not waste the time ,
money or system resources
in having that developer learn, create or
duplicate (HyBi) functionality
simply to merge some back end data or function.
*Framing:* Framing was a real head banger when it went from
simply
chr(0).utf8(message).chr(255) to being the
rather involved
animal it is. Of course it's been ~ten
versions
and many months since that transition with
no real problems
since , save knowing which version was
going to be in play after any
particular upgrade to the developers
version of the Chrome browser
we develop against.
This problem became largely moot as of
version ~8,
when the websocket (HyBi) protocol added
version
negotiation in the opening handshake
between the server
and client, so it matters not one bit what
happens in
version 18,19,20 etc. as we simply
negotiate a protocol
version common to both the server and client.
For those versions predating the
negotiation feature,
header sniffing and similar tactics are used.
With the current focus in the protocol
development
having nothing to do with the basic wire
protocol
but rather having moved onto dynamically
extending
the protocol with custom features we see no
issues
in going forward with mainstream development
which is why in our particular project we
are transitioning
to the *BETA campaign* which is of course
the last stop before
a production version.
*Funding: *As an open source project AsterClick relies on donations to pay
for lights,equipment,food and the like and
I would say of all the challenges
this project has faced , keeping the lights
on has been the most difficult.
I'm not going to put the beg on in this
message , although
I will mention that the email address on
this message does accept PayPal.
In *our point of view* If someone wants to create a back end AsterClick
client to
to tie in some pre-existing functionality such as injecting external
XML (Jabber XMPP ,RSS data ) or perhaps tie in their existing user
authentication system (A popular request), or whatever else, were not going
to impose 4300+ lines of specification as the price of admission.
A lot of people when hearing *WebSockets* have the term firmly
tied to web browsers, but this is simply because thats typically
the context in which WebSockets are discussed.
WebSockets do not need Web Servers,Browsers ,HTML, Javascript or
any of that to back up their value. Indeed one of the common use cases
for AsterClick involves none of those commonly seen companions
of the WebSockets discussion.
If after appraising the situation , it's more reasonable and cost
effective to connect an existing back end process as a websocket 0.0
client I'm going to make sure that option is there. If somebody
wants to use an older version in a public facing application
and has both recognized and accounted for the security issues
via other means , there too , I'm not going to stop them.
I most certainly will WARN them , but much like the
shell command "rm -f -r /" (don't type that unless your Bank of America ),
I'm not going to ban it's existence.
In the end though , I think the differences in our views
have more to do with our differing vantage points and goals
than anything else.
--Doc
On 10/02/2011 11:02 AM, Roger F. Gay wrote:
> But up to "version 8" there were security problems. What infrastructure? The
> standard isn't even final yet. I think anyone who was building their one
> infrastructure in advance of the standard would be aware that the websocket
> standard is not final and the need to update to the final standard. I don't
> mind a bit not supporting all the draft proposals. You'll notice also that
> the older ones are marked "obsolete." That's just the way I'll treat them.
> Especially since, at this point, the audience is made up of web-page builders
> and developers. As you know, quite a bit is done by trial and error. I mean -
> documentation only takes you so far. All development is that way. Being
> agnostic about the standard would open them up to errant coding.
>
[Non-text portions of this message have been removed]
------------------------------------
-----
To unsubscribe send a message to: svg-developers-unsubscr...@yahoogroups.com
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my
membership"
----Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/svg-developers/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/svg-developers/join
(Yahoo! ID required)
<*> To change settings via email:
svg-developers-dig...@yahoogroups.com
svg-developers-fullfeatu...@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
svg-developers-unsubscr...@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
