Re: [hybi] Insight you need to know: Browsers are at fault when servers crash

"Shelby Moore" <> Thu, 19 August 2010 08:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3C6F3A6819 for <>; Thu, 19 Aug 2010 01:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jc98pmOVssMU for <>; Thu, 19 Aug 2010 01:56:27 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id B9A593A6908 for <>; Thu, 19 Aug 2010 01:56:27 -0700 (PDT)
Received: (qmail 19800 invoked by uid 65534); 19 Aug 2010 08:57:02 -0000
Received: from ([]) (SquirrelMail authenticated user by with HTTP; Thu, 19 Aug 2010 04:57:02 -0400
Message-ID: <>
Date: Thu, 19 Aug 2010 04:57:02 -0400
From: "Shelby Moore" <>
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: Re: [hybi] Insight you need to know: Browsers are at fault when servers crash
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Aug 2010 08:56:29 -0000

> Well one optimization is why are allowing these WebSockets to connect to
> ports that are assigned to other legacy protocols by the IANA?  What
> benefit does that give WebSockets?  Seems an optimization would be to
> not do that.

"and TCP ports are not in fact protocol identifiers, despite some
traditions that conflate the two concepts"

> The server must anticipate the entire state-machine of its inputs.  The
> only way the browser can give the server bugs is when the server is not
> prepared for every possibility in its state-machine. The big caveat is
> that due to being a Turing machine means we will never be prepared for
> every possibility.

Yes browsers can be at fault when servers fail, even with the perfect
implementation server-side.  Example follows.

Filed a proposal:

Referenced Adam's research paper on CSRF.

The above is much more coherently written, and removes my erroneous
attacks on Adam's research. Turing machine complete, Liskov Substition
Principle, Coase's Theorem, Linksky Substitution Principle, and Godel's
Theorem insure that we can't have absolute certainty that we can isolate
all attack vectors at the server.[1]

However, we can access probabilities, and thus prioritize where we apply
security so as to reduce conflation errors that accumulate as brittle
complexity inertia. I still assert that I believe the priority should be
that protocols should be responsible for their user authorization, not
conflating the intermediary software (e.g. browser) that sits between the
(potentially malicious) user and the poorly designed (incorrect or no
authorization) protocol. Conflating responsibility leads to that brittle
complexity inertia, that ultimately dead ends in total disconnection
(whitelist) from the network. Conflation is an evil (failure directed)
result of being surety for another entity. If I make a promise for
another, I have bound the other and so on in domino effect towards
eventual gridlock.

I am still unsubscribed from this list, but I thought it was helpful to
post these clarifications.

(contains my one line layman's summaries of each of those fundamental