Subject: Re: [hybi] Anti-patterns (was Re: I-D Action:draft-ietf-hybi-thewebsocketprotocol-01.txt)

From: "Shelby Moore" <[email-masked]>
Date: Thu, 2 Sep 2010 15:01:51 -0400

> Please don't add versioning to the protocol.  Versioning is a
> anti-pattern for the web.
>
> FTR, that statement is false.  There is a very small group of
> inexperienced developers that think client-side rendering of
> uncontrolled content somehow defines universal principles for
> all software engineering.  The rest of us use whatever techniques
> we can to reduce entropy.

Hi Dr. Fielding,

I respectfully note the relevant fact that you are apparently VP for afaik
the most popular web server on the planet. And I use Apache and appreciate
its existence. Thank you for your efforts.

Let's talk about anti-patterns, and I assure you this isn't "Quixote
ripostes".

In my logic (feel free to retort/clarify), your comparison of
client-server and P2P architecture in your dissertation contains egregious
errors which enlighten our designs to degenerative evolution[4].

We know from nature[1], that systems self-organize via evolution and that
the reason evolution converges so fast amongst the frightening chaos of
astronomical random possibilities, is because the number of mutations (the
population of offspring) is very large for each generational step. With
small populations that do not grow exponentially, evolution loses its
efficacy[2] and Raison d'être.

In your "desireable architecture properties" comparison tables to P2P, you
claim[4] that client-server is extremely more scalable and equivalently
evolvable. Granted you do assert that P2P is more extensible, but I think
that misses the critical distinction below.

Perhaps one could claim client-server is more scalable because the current
network is asymmetrically skewed to more download than upload bandwidth,
but I understand this is an artifact of client-server, not a cause of it.

The client-server architecture's monopolistic dominance (and the incorrect
security models[3] that promulgate because of the myopia towards others
architectures) violates the E2E (end-to-end) principle of the original
internet (i.e. IPv4 before NATs and firewalls). This has eliminated 99% of
the possible permutations of connections between peers (forcing the coding
of programs with same patterns/footprint as viruses, employing unreliable
tunneling through firewalls and NATs, artificial barriers that were never
supposed to exist in IPv4).

I assert that the population of mutations (possibilities) for network
interaction has been dangerously reduced, so that the evolution of the web
is threatened to degenerate. So I can not see how you claim that a
centralized architecture evolves equally well to P2P, not even close by
orders-of-magnitude.

As for scalability, an architecture which can not evolve in real-time, can
not scale to real-time change[1]. So I find your claim regarding superior
scalability for client-server to be completely opposite of the facts of
preponderance of evolutionary science.

[1] http://esr.ibiblio.org/?p=2491#comment-276759

[2] Evolution works via annealing in the N-dimensional solution space of
fitness, which is why stochastically large populations are critical for
evolution to not get (gradient search, i.e. Newton's method) stuck in
local minima (valley) of the global solutions space. We know the brain
learns via stochastic annealing also. It is also why when ice forms via
slow cooling, it has less cracks. Etc, etc, etc.

[3] http://esr.ibiblio.org/?p=2491#comment-276953

[4] Roy Thomas Fielding, Architectural Styles and the Design of
Network-based Software Architectures, 2000

3.6 Peer-to-Peer Styles:
http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_4

3.4 Hierarchical Styles:
http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_6

---

From: "Shelby Moore" <[email-masked]>
Date: Thu, 2 Sep 2010 16:23:21 -0400

Add:

I mean that as no disrespect to Dr. Fielding, who has imho done an
enviably awesome job at organizing the network architecture concepts we
need to categorize. But unfortunately, imo he has that critical error in
the specific conclusions he made within his otherwise afais (so far)
excellent framework.

And the problem is that much of the work that is being done here and else
where is influenced by errors of that genre.

Specifically, imo the entire cross-protocol and same-origin policy (SOP)
language needs to be stripped out of the draft. Imo, it is worse than
useful.

I have no disagreement that SOP does apply to client-side resources (in
client-server architecture). All client-side resources loaded by a page
should only be available to that page (i.e. that origin). Do not think
that I am against SOP for that specific purpose.

However, SOP has no applicability to network requests because the origin
server is completely in control of the network requests it will initiate
from the client. The only exceptions are bad scripts that are injected at
the discretion of the origin server (or bugs in the browser). The argument
others make is that users can not reason about which origins allow bad
network requests, thus we have to protect users from themselves.

First, that is a centralized model of security, so I suggest you read what
I wrote about evolvability and scalability to dynamic change. Hackers
invoke dynamic change. As Adam said, we don't find out about new attacks
until (even up to years) after they occurred. So the hackers route around
the useless barriers that we call security (Coase's theorem), while the
useful features are not available to the good programmers. The hackers
will always work harder than the useful programmers, so if we apply these
incorrect security models, then we trend towards no programming features
at all (no evolution, death).  I wrote about the read security we should
be doing that can really stop the hackers without blocking any
features[5].

Forcing browser features to be crippled by the need to protect against
every server programming mistake ever made, is the direction that
cross-protocol security model leads[6].

Neither SOP for blocking network requests nor cross-protocol blocking,
offer any real security[5]. What they do is obfuscate the real bugs, so
that evolution is not able to fix them.  For example, if SOP stops an
origin from loading resources over the network from another origin, all
this does is removes features. It doesn't add any security, because if the
page is doing bad things, the user can clearly say "this is a bad page,
don't load it again" (word gets around, bad things lose popularity and
wither). Ditto if a bad page is attacking a protocol or different origin,
which as I explained is not security at all, because the bad page could
even attack its own protocol or origin server[6].

Afaiu, the Cathedral and the Bazaar model of "more eyeballs = shallower
bugs" is simply a statement of the way evolution works.  Read what I wrote
about Dr. Fielding's critical mistake below...

[5] http://www.ietf.org/mail-archive/web/http-state/current/msg00939.html

[6] http://www.ietf.org/mail-archive/web/hybi/current/msg03968.html

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 02 Sep 2010 14:41:37 -0600

> language needs to be stripped out of the draft. Imo, it is worse than

This is a concrete technical suggestion.  Does anyone else agree with it?

To keep traffic down, there is no need to reply to disagree for the moment,
unless there are several others that feel that the text should be removed.

-- 
Joe Hildebrand
(as chair)

---

From: "Shelby Moore" <[email-masked]>
Date: Thu, 2 Sep 2010 18:23:08 -0400

> unless there are several others that feel that the text should be removed.

I agree that if no one else offers support, then it is by defacto
disagreed with by the current members of this WG.

Note I am trying to incite some outsiders to care:

http://esr.ibiblio.org/?p=2491#comment-276993

But as I told Joe, I am not going to fight it here, I just want my
technical arguments on the record and not buried by the majority. Because
the majority here, who will get their desires any way, may or may not
reflect the majority opinion of those who will be using WebSockets for
applications and who may be very much under represented in this WG. I feel
I am here to defend the users' rights. All the best to all of you in your
efforts.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 2 Sep 2010 15:56:36 -0700

> its existence. Thank you for your efforts.

I am not the current VP, but you are welcome in any case.

> Let's talk about anti-patterns, and I assure you this isn't "Quixote

You do not seem to understand my turn of phrase.  Quixote battled valiantly
against imagined enemies, parrying imaginary attacks and attacking back
in return (ripostes), often to the surprise of those who were not attacking
him in the first place.  There is no grand battle to be led, nor princess
to save, in an attempt at design by committee.  Treating everyone around
you as combatants does not help your arguments.

> errors which enlighten our designs to degenerative evolution[4].

No, you just haven't read it carefully.

> efficacy[2] and Raison d'être.

Natural systems self-organize.  Software systems do not.

> that misses the critical distinction below.

No, I claimed that client-server improves scalability and evolvability
by deliberately (by design) separating concerns.  Those are a well-known
properties of applying a well-known software engineering principle.

There is no single P2P style. Peer-to-peer network-based applications
is just the absence of a (client-server) constraint.  There are some
peer-to-peer styles that do have other added constraints for layering
and evolvability, which are briefly described in my survey.  However,
they were not applicable to the Web and thus not applicable to the
rest of my dissertation.  You can believe anything you want about the
quality of my work, but you simply cannot genuinely claim that the Web
is not a client-server system or that the clear separation afforded by
using standard transfer protocols with defined semantics has not enabled
Web clients to evolve independently of servers (and of each other).

> but I understand this is an artifact of client-server, not a cause of it.

It depends on the applications for which the system is designed.
There is no such thing as an optimum system in the absence of
requirements.

> supposed to exist in IPv4).

You are simply wrong here.  The E2E principle only applies to transport
of bits.  No successful Internet application adheres to the E2E principle
because of the multi-organizational reality of the open Internet.  People
want their firewalls, need to scan for viruses, and have no desire to support
illegal copying across their network infrastructure.  That is why we have
MX hosts, http proxies, netnews hubs, etc.  Any application protocol that
does not support intermediation will be blocked by major networks as
soon as it is perceived as a threat (or just by default until it has
proven itself not to be a threat).  That's life.

This in no way detracts from the very real benefits of adhering to
the E2E principle at the transport layer and out on the wider Internet
between organizations.  Nevertheless, it should be recognized that
rigid belief in that principle has long hindered deployment of IPv6.
NATs and other network barriers are a desirable thing for users,
regardless of how many problems they cause for our protocols, and
we need to learn to work with them instead of decrying their faults.

> centralized architecture evolves equally well to P2P, not even close by

None of the browser software that existed when I started that work was still
in use by the time I finished it.  In contrast, I don't know of a single
P2P system that has evolved past the first version written by a single
developer.  They tend to be tightly coupled (not necessarily because
of the interaction style -- most CS systems are that way too).

One way to solve that problem is self-descriptive messaging within
stateless protocols across multiple transport mechanisms with
message-based (not connection-based) encryption applied only when
necessary.

> [1] http://esr.ibiblio.org/?p=2491#comment-276759

Again, your assertion does not match reality.  The architecture does not
need to evolve in real-time if it has already been designed to be scalable.
That is the whole point of scalable architectures, load balancing,
MapReduce, etc.  Meta-architectures and introspection are an interesting
technique in the lab, but generally fail to evolve fast enough for the
kind of load spikes seen on the Internet.

> slow cooling, it has less cracks. Etc, etc, etc.

Evolution of software happens by choice as organizations and people evolve,
not as a natural mutation effect like that in biology.  There are distinct
differences between the social sciences and the biological sciences.

This topic has again diverged from the work of hybi.  Please stop hijacking
the threads.

....Roy

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 02 Sep 2010 17:09:07 -0600

On 9/2/10 4:56 PM, "Roy T. Fielding" <[email-masked]> wrote:

> This topic has again diverged from the work of hybi.

Agree that this has nothing to do with the work at hand.  Anyone feeling the
need to reply to this part of this thread, please sit on your hands and
think of a way to turn your argument into proposed text for the draft.

-- 
Joe Hildebrand

---

From: "Shelby Moore" <[email-masked]>
Date: Thu, 2 Sep 2010 20:45:58 -0400

Joe Hildebrand wrote:
> Agree that this has nothing to do with the work at hand.

I will demonstrate otherwise below...

======================
Roy T. Fielding wrote:
[snip]
> think of a way to turn your argument into proposed text for the draft.

I will below make specific points as to how this applies to question of
whether the SOP and cross-protocol language should be in the draft.

[snip]
> I am not the current VP, but you are welcome in any case.

Thank you and also for clarifying.

[snip]
> you as combatants does not help your arguments.

Imagined applies. I didn't. Factual technical debate (without pedantic
obfuscation) applies. So I think we can agree to not discuss these
imaginary emotions further.

> No, you just haven't read it carefully.

Or perhaps you can entertain the possibility that I did read it carefully,
and we have a different perspective of reality.

> Natural systems self-organize.  Software systems do not.

First it is not correct to imply that running software can not
self-organize without programming change. There are genetic and generative
algorithms that can be programmed.

Second, I understood even before your reply, that you are making a
distinction between the programming of software and the executing
software-- the Cathedral model.

I suggest to you that is has already been proven that lowering the cycle
costs for the feedback synergy loop between what software is doing and the
programming (i.e. Bazaar and peer programmer model) squashes the Cathedral
model in the reality of the free market:

http://www.catb.org/~esr/writings/cathedral-bazaar/

And WebSockets is about applications, application programmers, and end
users. That is an evolutionary feedback system.

> properties of applying a well-known software engineering principle.

Improves scalability and evolvability within specific chosen limitations,
naming the inability to scale and evolve with a centralized server. And
the users don't have atomic control of the server, thus it is not as
generally scalable and evolvable as a system where the users have atomic
control over their interaction with each other.

I understand that you could make the point that users can not interact
with each other until someone programs the feature to do so, and thus you
could make the incorrect conclusion that servers can scale and evolve as
well as P2P.  However, the basic presumption of the WWW is that user is
the programmer.  HTML was specifically designed for the amatuer
programmer. And WebSockets opens a whole new world of possibilities
especially if we don't force users to interact with a server. Rather
spontaneously users could start interacting with each other.

Users do via social networks and they get quite frustrated that the
central server does not let them do what they want to do. I was apparently
the first one who revealed to the disgruntled users that facebook privacy
thing that users were complaining about (I can provide a link for proof).
The users thought they could hide their friends from their other friends,
but they didn't realize it wasn't doing what they thought it was doing. 
Facebook had so many different layers and ways to obfuscate (and I
theorize that it is because their $billions valuation model is based on
making sure all your friends find each other whether you like it or not).
A few months after that, the ground swell of discontent reached the news.

Servers suck but they are anti-freedom. Period. We need servers, but as
little as possible. The sooner we flatten back out the internet, the
faster it can evolve.

> There is no single P2P style.

That is a good thing for evolution.  I hope there will be a quadrillion
styles.

> Peer-to-peer network-based applications
> is just the absence of a (client-server) constraint.

I guess I agree with that, and I assume you agree that P2P can cooperate
with a server.

>  There are some

If your work was only intended to classify what was, and not include what
could be, then I agree that you probably had limited data to work on P2P.
And I agree the client-server model predominates now.

But think what is fundamentally driving WebSockets? It is not just the
need for real-time push, but it is fundamentally that the client is
growing more important than the server! The code in the client is now
becoming sophisticated enough that the server must treat the client as a
peer!

Ah ha!!!

Hmmm. The web is moving towards P2P and we better get out of the way,
because it is going to squash us whether we like it or not.

Nature (evolution) won't put up with any rigor mortis.

And folks is why we need to remove the SOP (same-origin policy) and
cross-protocol language from the draft of WebSocket.  Factor in everything
I will write below too.

> There is no such thing as an optimum system in the absence of

I agree, but please realize the fundamental requirement that is driving
the need for WebSockets.  "push" is myopic, the generative essence is that
the client is becoming fatter (running more code) and becoming a peer.

> because of the multi-organizational reality of the open Internet.

Baloney I am right.

Gnutella, Kareeza, etc are not successful?  Millions of users use them.

What about Skype and Yahoo Messenger? I think Skype has like 100 million
users and apparently being bought by the company that employs our Chair.

>  People
> want their firewalls, need to scan for viruses,

Yeah because for at least 11 years we have refused to do real security and
encrypt data on the client side:

https://bugzilla.mozilla.org/show_bug.cgi?id=19184
http://www.ietf.org/mail-archive/web/http-state/current/msg00939.html

Instead we give them half-baked insecurity of perimeter walls and vacuum
cleaners.

> and have no desire to
> support
> illegal copying across their network infrastructure.

There are legitimate uses for sharing files.  Skype is a legitimate
application.  Yahoo Messenger is a legitimate application.  Between those
you've probably touched 30 - 50% of the users of the internet.

> That is why we have

Threat to some vested interests yes, but not a threat to the users.

And guess who will win that eventually? The users and nature. Every time. 
<joke>The georgia guidestones notwithstanding.</joke>

I should tell you about an irrefutable mathematical proof I came across
recently, but I am afraid it would be too shocking, so I will never
mention it on this list.

> between organizations.

It does detract from what nature wants, which is unfettered E2E
interaction.  Vested interests can stick dikes into for a while, but the
leaks are going to overcome them, or we will shut the whole thing down in
process of hardening the perimeter.  Eventually the hackers are going to
attack your whitelisted itermediation so that you have to whitelist
everything, that is where the current model ends up.

>  Nevertheless, it should be recognized that

I have no problem with NATs and firewalls, if they will expose an API so
that the user can tunnel his/her application through unfettered and with a
single click of the mouse. But I know that won't happen, because no one
wants to give the users control over themselves. They are just sheep to be
controlled by the middle men. The internet itself is evolving into a MITM
attack model where the attacker are the people who claim to be protecting
us.

> of the interaction style -- most CS systems are that way too).

You are unaware then of Skype, Yahoo Messenger, etc..

> message-based (not connection-based) encryption applied only when

Okay sure, I can support that. Anything that gets the ball rolling towards
what nature and users want.

> Again, your assertion does not match reality.

I assert you are not knowledgeable about the architecture of Skype then.

>  The architecture does not

And P2P is more scalable, because multiple atomic processes interacting is
always more scalable than a centrally managed one.

> MapReduce, etc.

Those are attempts to granularize the processes into more atomic actors.

But they still funnel through a trunk of control (who can program them,
i.e. lack of diversity/mutations that evolution requires).

>  Meta-architectures and introspection are an interesting

I am not thinking about only load scaling.  I am thinking about fitness
scaling of any attribute, i.e. what ever is important to users, e.g.
features we can't even imagine and some we can imagine.  The whole point
of evolution is that we don't know all the ways it will evolve yet.

> Evolution of software happens by choice as organizations and people

Exactly!

> not as a natural mutation effect like that in biology.

Wrong.  The network is alive. The ends contain intelligience aka humans.

>  There are distinct

We were having a great technical debate, then you add that slander to the
end ostensibly to try to coerce/embarrass me to not make future technical
input.

---

From: "Shelby Moore" <[email-masked]>
Date: Thu, 2 Sep 2010 22:07:16 -0400

The _ONLY_ positive scaling paradigm on the internet is the Bazaar...

[snip]

> self-organize without programming

[snip]

> users. That is an evolutionary feedback system.

The _ONLY_ positive scaling paradigm on the internet is the Bazaar!

Listen to this, especially around the 4:20:

http://www.catb.org/~esr/writings/cathedral-bazaar/linux1_d50_48kbs.mp3
(48kbps)
http://www.catb.org/~esr/writings/cathedral-bazaar/linux1_d50_96kbs.mp3
(96kbps)

[snip]

> spontaneously users could start interacting with each other.

Listen to the first 1.5 mins of the above audio, where it is explained
that half-amateur programmers bashing on code and releasing new
executables every day, evolves 6 months faster than cathedral models of
software evolution.

Heck as further evidence, we can't even produce a simple orthogonal
fragmentation framing and semantic message layer[7] in this WG without
getting bogged down in so many conflated issues (authentication,
cross-protocol security, encryption, etc) that have nothing to do with
WebSocket. First draft WebSocket, and leave those other things for the
market or a new WG to handle orthogonally. Don't conflate everything and
paralyze your evolution.  Smallest atomic things are the fastest.

[7] http://www.ietf.org/mail-archive/web/hybi/current/msg03901.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03919.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03854.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03833.html

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 02 Sep 2010 21:19:47 -0600

Perhaps I was unclear in my previous message.

None of this is proposing text to add/remove/change in the draft.  That is
not always required, but on this thread, it *is*, by chair fiat.

This thread is OFF-TOPIC.  We're not here to change the way that the world
works with this one protocol as the exemplar.  We're here to design a
client-server protocol that fits in to the existing web environment, with
current best practices for application-layer protocols.  That is why we
started, what we signed up for in the charter, and what we're going to
finish.

-- 
Joe Hildebrand
(as chair)

---

From: Dave Cridland <[email-masked]>
Date: Fri, 03 Sep 2010 09:23:40 +0100

> This is a concrete technical suggestion.  Does anyone else agree  
I think we do need to ensure that we can defend against  
cross-protocol attacks, and therefore that language (or something  
along those lines) needs to stay. It's a valid security concern, and  
we should offer mitigation for such attacks if desired.

I do note it may not always be desired; that is, it be actually be  
desirable to be able to offer websocket services which are accessible  
by hacky abuses of existing scripting interfaces in browsers.

For SOP, I think there is a case that it could be removed. There was,  
as I recall, a BOF at the last IETF concerning generalizing the SOP  
and other HTTP/Web security issues along these lines called HASMAT,  
and it seems to me that referring directly to that work might be a  
preferential option. Naturally, this depends on the progress of the  
HASMAT BOF, and I'm sadly ignorant of what's happening there.

I'd suggest that we as a group ask advice from our Area Director on  
the matter.

That said, it is currently informative text, as I understand it.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Shelby Moore" <[email-masked]>
Date: Sat, 4 Sep 2010 09:26:00 -0400

This is my last post in this thread, everyone else can have the last word.

Joe, I just got around to reading this, so I apologize if I have to
violate my private email where I wrote that I had no more need to post to
the list. I didn't expect you to miss my point, and I don't intend this as
disrespect to your authority but rather to clarify.

I did propose removing the SOP and cross-protocol security language from
the draft.

The relevance is that current best practice in the real world, is that
coorperative servers with <script> and <iframe> are used to violate SOP
and do cross-protocol communication, because Coase's Theorem can not be
violated. The users demand that the internet be E2E and they get it now by
proxy (and they are pushing for more). I postulate that if ever browsers
try to enforce SOP on <script> and <iframe> then you will see people use
flash, and if flash is closed to SOP, then you will see users (open source
community) make new plugins or simple make new browsers.

Btw, HTTP is already P2P because any client can run an HTTP server, only
E2E blocks it.

Anyone can fiat until they are blue in the face, but they will never beat
nature nor fundamental laws. They either bring their work in tune with
reality or they suffer in the market place. Btw, that fiat order has
already lost, and only the fools will let themself sink with the Titantic:

http://esr.ibiblio.org/?p=2507#comment-277125

Apologies perhaps I was unclear in my previous message(s).