Subject: Re: [hybi] New port and Tunneling?

From: "Shelby Moore" <[email-masked]>
Date: Tue, 17 Aug 2010 07:23:50 -0400

I have edited my prior reply[1], not to add or change any point, but to
clarify some ambiguity and compact my verbage...(refer back to the prior
reply for some nuances that have been compacted out of this current reply)

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

Apology for the reading load of my messages, I anticipate it will soon
taper down, as my main points are clearly communicated to the list.  Then
I can comment more infrequently if I see something sufficiently important
that others did not point out after some time.

below...

> On 16 aug 2010, at 20.18, Shelby Moore wrote:
>
>> Some Benefits of port+tunnel (other benefits have already been
>> mentioned)
>>
>> =====
>> P2P:
>>
>> Perhaps a big bonus of port+tunnel, is we could then allow P2P
>> connections for WebSockets. That would be a huge, super huge feature.
Success rates are apparently around 69%. Fall back to Comet/BOSH to an
HTTP server for the remaining 31% (similar rates of fall back be
necessary
>> for other proposed transports too).
>>
>> The Same Origin Policy does (and SHOULD) not apply to cross-site
communication when the HTTP cookies and/or any form of HTTP session
persistance are not involved[1].
>>
>> [1]
>> http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_XMLHttpRequest
>>
>> That may be a controversial statement, but I am able to explain in
exhaustive detail if any one doubts it.  Summary is that since the user
trusts the page he/she is viewing and that is communicating, the user
trusts that viewed page to not load resources which would be malicious,
and thus the only vulnerability that is not the responsibility of the
other site involved in communication, is the one where the other site
can
>> be tricked into doing something on the user's credentials for that
other site.
>>
>
> I'm not sure what the point is here. Yes, you are correct in that the
SOP no longer applies to WebSockets, but this has been true from the
get-go.
> However, the _origin policy_ still applies very much. Mostly because
even if the _user_ might think one thing, neither browsers nor
enterprises expect most users to know any better.
> Since browsers are, more and more,
> becoming execution environments that automatically run the executable
code they download, this is a very important point of restriction. Web
pages should not be able to arbitrarily initiate connections anywhere
they want, as that opens up malicious attack vectors.

SOP = same origin policy

I will phrase this generally for all potential protocols, not just HTTP.

Status quo should remain, where "cookies" (i.e. any client-side persistent
user data) are (at least by default) inaccessible if they were not created
by *.domain of the current page (i.e. window.location.*).

There are only two categories of SOP attacks (all attacks fall under these
two):

1. Cross-domain requests where "cookies" for the domain, receiving the
request, are automatically included in the request.

2. Cross-domain requests that load malicious resources (e.g. usually
scripts) from foreign domain into current domain.

My first point is that #1 can be configured to never happen and thus SOP
would not need to be enforced (instead page scripting can explicitly pass
"cookie" data in requests, and servers can refuse to use any "cookie" data
inserted automatically by the browser). There would be an exception for
pages that don't want to use scripting, and for that exception SOP would
need to be enforced irrespective of what I write below.  Also PHP
programmers should be aware that sessions automatically load cookies (and
besides PHP session ids are apparently hackable, http://samy.pl/phpwn ).

My second point is that SOP also need not be enforced because of #2, if
the user has agreed to trust the current page (domain). This is because
the current page is entirely in control of what is loads. If the current
page decides to load an untrusted script that violates and removes this
control, then the fault/responsibility is the current page (not the
browser and not the bad script). There are numerous ways the user could
express this trust, and the browser should decide its implementation of
that. Pages would need a way to request that the browser turn off SOP. I
would expect that most domains would offer two versions of each page (or
site), one that does not turn SOP off and thus is by default trusted by
all users, and another that turns SOP off and (carefully) adds features
for users who trust the page (or site). The reason that more granularity
for the tradeoff between features and trust, is more secure, is because
the power and wisdom of the free market is enabled and optimized (it is
because of Coase's Theorem[2], see my other example below).

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

My third point is that if WebSockets does not use HTTP, then #1 can't
happen because there are no HTTP cookies involved.

My fourth point is that SOP is a centralized "least common denominator" on
tradeoff between features and trust-based security.  Thus it is not the
optimum result for either features or security, because it is not as
granular as it could be.  I have explained above how to practically and
easily make it more granular.

My fifth point is to re-iterate (from my prior posts) the point that
centralized "least common denominator" security has a dead-end at
whitelisted communication everywhere, or failed filtering (I won't say
failed "security" because I don't view the centralized model as secure
because when users are forced to use less features, Coase's Theorem[2]
insures some will route around the barrier/extra cost). I had in past
given the simple example of HTML pages encrypting requests from the
browser over HTTP (port 80) using JavaScript, which would force the
enterprise proxies to either whitelist port 80 or lose their ability to
see the data and filter it.

And let me re-iterate the point[3] from my prior posts in this thread (and
HTTP Compliance), which I assume was ignored by this list, that any
collateral damage _outside_ the domain affected can be trivially erased by
the user with a simple and instantaneous reset of their client machine,
running a disk image restoration engine such as Baseline Shield with an
exception drive/folder for persistant file changes. And this paradigm
travels with the user, unlike the current proxy firewall paradigm of the
enterprise. And that firewall/filtering paradigm has already nearly closed
(whitelisted or eliminated secure communications on) every port except 80
and soon 80 will be forced closed (or the filtering will have a hole), as
per the example I gave in prior paragraph.

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

---

From: "Shelby Moore" <[email-masked]>
Date: Tue, 17 Aug 2010 07:59:50 -0400

> scripts) from foreign domain into current domain.

Clarify that to be "There are only two categories of SOP applicable
cross-domain attacks for accessing network resources (all such attacks
fall under the above two)".

Of course SOP still has to always apply to script access to the
client-side resources (e.g. to cookies, frames, etc). Someone could argue
for more user trust granularity for client-side-resources SOP, but I would
retort that it would be unreasonably complex for users to manage N-tuples
of domains that are trusted with respect to each other.

The reason #2 does not involve N-tuples complexity is because the domain
of the current page is entirely in control of when it initiates access to
network resources.  Whereas for client-side resources, the domain is not
in control of when its resources are accessed-- the browser is the
gatekeeper.

---

From: "Shelby Moore" <[email-masked]>
Date: Tue, 17 Aug 2010 13:07:11 -0400

> in control of when its resources are accessed-- the browser is the

#1 is CSRF:

http://en.wikipedia.org/w/index.php?title=Cross-site_request_forgery&oldid=377197816#Example_and_characteristics

#2 is not XSS:

http://en.wikipedia.org/wiki/Cross-site_scripting

Rather #2 needs a name, perhaps XSSR(equests), since it is only concerned
with vulnerabilities that derive when a malicious resource (script) is
requested by the trusted domain.

CSRF
====
When I wrote "'cookies' (i.e. any client-side persistent user data)", I
put it in quotes and defined it broadly because I didn't mean only HTTP
cookies. I meant any way for the server to have persistance with the
client that would be used by the server to do side-effects, and that would
include Flash LSO objects, DOM storage, IP address (if only storing or
dislaying this is probably safe side-effects), etc.. And I disagree with
Wikipedia in that don't think just having the server check Referrer closes
the security hole.

The following are not CSRF as I have defined CSRF above and attacks due
other unrelated vulnerabilities (disagree with Wikipedia for conflating
them with CSRF):

http://en.wikipedia.org/w/index.php?title=Cross-site_request_forgery&oldid=377197816#Other_approaches_to_CSRF

---

From: Adam Barth <[email-masked]>
Date: Tue, 17 Aug 2010 15:25:38 -0700

Shelby,

You seem deeply confused about how browser security works.  I'm sorry
that I don't have a good reference to offer you to help you sort out
your confusion.  However, much of what you've written on this subject
is just plain incorrect.  (By the way, disagreeing with Wikipedia
usually isn't the best way to convince others that your definitions
are widely accepted.)

Adam

On Tue, Aug 17, 2010 at 10:07 AM, Shelby Moore <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: "Shelby Moore" <[email-masked]>
Date: Wed, 18 Aug 2010 03:19:49 -0400

Hi Adam,

Please skip down the numbered point first, to see your gross
mis-understandings.

Sincerely thanks for expressing your opinion. I appreciate it. I have
opened your web page ( http://adambarth.com ) and I understand you are a
PhD with some focus on cross origin security (my credentials are mentioned
below). Could we Skype for 20 mins, because it might be much more
efficient to resolve this? Or a private email discussion? Then one of us
can come here and admit defeat after we hash it out. I have no problem
with accepting when I am wrong, but I need to understand first. And I am
reasonably confident (you will read why below) that in this case the
misunderstanding is predominantly on your side. Let me see if I can clear
this up below. If you prefer to debate on this public list, that is fine
with me. If you prefer to ignore me or make only sweeping statements with
no specific debate, then I will consider you have lost the debate. Let's
try not to get personal and inflamed, and let us stick to the facts.

After sending this email, I am going to take some time to read some of
your publications, so I can understand better your expertise. I will show
you that respect/appreciation and give my time to understand you (for my
own benefit of course). I appreciate if you would allocate just a little
time to steering this thread to a successful conclusion (one way or the
other), without just a sweeping statement of expert authority (those often
are correct, but just once in a while they are gross errors). I do
understand that it is not a free market if I demand your time, so I will
understand if you decline.

We will probably discover that we are both correct, and we just didn't
understand the nuances of what each other. It is important that we
discover in what ways we are both correct, so that we are clear on the
nuances. We must respect each other, and assume intelligience until
clearly proven beyond any reasonable doubt otherwise. If we merely talk
past each other (because we are too lazy or too busy or too
arrogant...myself included), then understanding will fail. You obviously
take browser security very seriously as I do too. So unless you think I am
a total idiot (without even giving me an interactive dialogue to show you
otherwise), I can't imagine why you wouldn't want to at least make a
modicum of attempt at mutual understanding. But then again, I am confident
enough to go on without you and the list too (I love free markets).

Unfortunately, you didn't provide much specific information about your
misunderstandings, that could help me know if you are correct or not.
Based on the incorrect statements you made, I am nearly certain you just
broadstroked this without really understanding my points.  I will detail
as follows:

1. Contrary to your allegation, my prior points did not summarize the way
browser security currently works in every instance (e.g. XMLHttpRequest,
SOP applied to client-side resources, etc), rather to point out a way it
should work (in fact does work now! see below), if it was (is!) done
optimally. And my analysis was only focused on the aspect of SOP applied
specifically to browser network resource requests, i.e. when/should/does
the browser restrict network resource requests to SOP. Please re-read the
prior sentence a few times to remember the narrow focus.

Also I humbly suggest that you remember that SOP is never an avoidable
restriction for network script requests from the browser, because SOP is
not applied to the <script> tag (oh maybe there is a case that I am not
aware but it isn't common because I haven't seen it yet). So actually I
was explaining how the browser works now with respect to <script>. Then I
explained why that is optimal (in opposition to the current wrongheaded
trend to move away from that, wrongheaded is proven factually below). I
was explaining this in order to show that we do not need to apply SOP to
WebSockets. I was NOT explaining how the ENTIRE browser security system
works now. And I can assure you that my statements were correct and
factual (notwithstanding any mis-interpretations, grammatical errors, and
typos).

2. Your allegation that I am in conflict with Wikipedia is incorrect.
Wikipedia has a section "Other approaches to CSRF":

I agree that those are valid vulnerabilities. Wikipedia is even saying
that they are not exactly "CSRF".  Rather than create a name for them
(since Wikipedia is not allowed to create new things, only state what is
already), they have no place to put those vulnerabilities, so they stuck
them under a new name "Other approaches to CSRF". They are not CSRF
exactly. It is up us experts to give those a proper category of their own
with a name. I humbly suggest that you notice that CSRF contains the word
"Request". I will understand if you didn't notice that word in the
acronym, but then it would help if you did not speak as absolute authority
or expert, when apparently you are failable. My point is that CSRF
involves vulnerabilities that initiate from "Cross Site Request Forgery",
and that means they must initiate from "Request Forgery", and the
vulnerabilities in that section do not (as Wikipedia also states).

When I wrote "disagree", I meant I disagree with them being characterized
as "approaches to CSRF", because by the time the requests have been issued
in those vulnerabities, then request itself is no longer cross origin
(Cross Site). The request itself it not the vulnerability in those cases,
but rather the injection method is the vulnerability with the request as a
payload. As a cross origin security expert, I hope you can appreciate the
distinction and offer me a little due respect for my astute observation.

=======================
Now let's see if I can re-summarize the main thrust of my prior posts
below, in order to coax some initial "a ha, that is what he meant"
understanding from readers, that might motivate them to go back and
re-read my prior posts to have new epiphenies.

I am pointing out that all (cross site or same site or whatever) network
requests from the browser can be classified into 2 types of
vulnerabilities (ignoring vulnerabilities due to bugs in the browser or
server itself). And be clear that I mean where the request itself is the
vulnerability, not where the request was a payload of a prior
vulnerability (avoiding conflation is critical for correct analysis).
Those boil down to:

#1 Hijacking user data in a request, or more generally any request that
causes unintended side-effects on server state-machine.
#2 Requesting malicious resources (e.g. scripts).

Those 2 correspond to the prior 2 categories from my prior posts.

#1 is mis-classified (by you "experts") to be a SOP problem, when in fact
it is a bug in the server code. Any one who has any significant real world
experience in web programming security (I have 13 years as hands on CTO
with millions of users), knows that the server must always be secure from
any possible state-machine of its inputs. To require the client to help
the server be secure, is the antithesis of security.  That is why I said
the solution is for the browser to never rely on persistent data on the
client, if it wants to be secure. That is just common sense.

#2 afaik is not precisely categorized with any name. It falls I guess
under the general term XSS, but I am being more specific and talking about
the vulnerability of the request itself. I understand that not conflating
vulnerability categories, is the first fundamental step that an expert
researcher must do. With respect to the request vulnerability, there is no
vulnerability if the origin which is doing the requesting does not choose
to request untrusted resources. SOP is not the same as trusted. Yes the
same origin is trusted, but it is not the only origin that might be
trusted. To restrict #2 to SOP in all scenarios, is least common
denominator and not optimal. I proposed an easily granular solution that
would work very well in the marketplace. I am confident my solution will
win and I plan on implementing it soon, unless someone can explain why I
am wrong.

Good day.

---

From: Adam Barth <[email-masked]>
Date: Wed, 18 Aug 2010 00:55:26 -0700

Thanks for your detailed response.  I think I understand your
perspective better now.  Unfortunately, whether or not we judge the
fault to lie with the server, browser vendors still take it upon
themselves to avoid these issues.  For some perspective on why this is
the case, you might enjoy reading this post:

http://www6.ietf.org/mail-archive/web/hybi/current/msg02400.html

Kind regards,
Adam

---

From: "Shelby Moore" <[email-masked]>
Date: Wed, 18 Aug 2010 04:14:09 -0400

> your publications, so I can understand better your expertise.

Thank you for providing public copies of your research papers.

Now I am going to teach you (arrogant? maybe, but not desired, just the
way it is[1]).

I just read the following (in this order):

1) Beware of Finer-Grained Origins
Collin Jackson and Adam Barth
In Proc. of Web 2.0 Security and Privacy 2008 (W2SP 2008)
http://www.adambarth.com/papers/2008/jackson-barth-b.pdf

I agree with you. Sub-origin is brittle. Proliferating granularity that
does not match the user's capability to manage trust, is self-defeating
because of Coase's Theorem (nature routes around any artificial
barrier/cost). The user will always try to maximize his desired trust.
Thus trust granularity must correlate with the user's trust, not with any
other centralized trust paradigm. This is precisely why I pointed out that
SOP != trust in my prior posts of this thread. You got the problem
correct, but (at least in that paper) you didn't quite grok that Coase's
Theorem is the generalization and thus what the general solution must be.
Also we must understand the human limitations to manage complexity and
that is why my proposed improvement to whitelisting SOP was designed to
minimize the complexity and maximize the type of trust granularity that is
meaningful to the user.

2) Robust Defenses for Cross-Site Request Forgery
Adam Barth, Collin Jackson, and John C. Mitchell
In Proc. of the 15th ACM Conf. on Computer and Communications Security
(CCS 2008)
http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf

Sorry to say you committed the exact mistake in this paper as I predicted
you would make in my prior rebuttal post. NEVER is relying on the client a
security solution (e.g. Referrer for HTTPS, or Origin for HTTP). That is
the antithesis of security. The 100% solution to that CSRF login problem
is as I have implemented at AsiaDear.com . The server never uses any
persistent client data for login, except when index.php is requested, it
reads the cookie. But since index.php never accepts any GET or POST
inputs, then no server side-effects can occur when index.php is requested
and the cookie is injected from the client. Think about that deeply and
you will get the "a ha". The /rest/* APIs are always requested with the
session id GET/POST input to prove the user is signed in (non-geeks prefer
term "sign in" than "log in"), so there is no way to get that that session
id unless you can hack the browser (or inject into the index.php page
script with other category of vulnerability) because it is stored in the
script for index.php on the client. If the user is signed in with
"remember me" checked, and then you request one of /rest/* apis (try
user.php and photo.php), you will receive back "you were signed out". But
then if you do something at index.php, you see you are still signed in.
Exactly how it should work! Your suggested use of an Origin HTTP header is
wrong. Never should the server be programmed to rely on extra actors for
its state-machine. The entire Origin WG draft is wrongheaded (I can go
into that in great detail with you if you want).

3) Towards a Formal Foundation of Web Security
Devdatta Akhawe, Adam Barth, Peifung E. Lam, John C. Mitchell, and Dawn Song
In Proc. of the 23th IEEE Computer Security Foundations Symposium (CSF 2010)
http://www.adambarth.com/papers/2010/akhawe-barth-lam-mitchell-song.pdf

The problem with models is that if they conflate vulnerabilities, they do
not give correct insight. You've got so many fundamental flaws, that you
can't even begin to declare a model. It wasn't worth entirely wrapping my
mind around this paper, because for one you start by definining the
fundamental components in a way that conflates vulnerabilities. Sorry.

[1] http://esr.ibiblio.org/?p=1327 , Killing the Founder - Eric Raymond blog

---

From: Dave Cridland <[email-masked]>
Date: Wed, 18 Aug 2010 09:20:18 +0100

> Now I am going to teach you (arrogant? maybe, but not desired, just  

Is this really the best forum for this?

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: Wed, 18 Aug 2010 04:24:49 -0400

I will read it next, but quick reply to say:

1) Agreed, because if the browser has a bug that reveals my session id for
AsiaDear.com, my security is broken.  I have to rely on the browser for
persistance, but what I have done is made sure that only a bug in the
browser can do it, not some other type of vulnerability.

2) Apologize for the tone of my prior email about your research paper.  I
wasn't expecting that you would appreciate my points, but seems I wasn't
patient enough (past experience sorry). Also if you are approaching this
from a "what is practical in real world" perspective, I can understand why
your research would be less "idealistic" than my points.  Nevertheless, I
hope we can agree that it is a major win when we can be idealistic and
achieve the isolation of #1 above.

>>>>> of the current page is entirely in control of when it initiates
>>>>> access
>>>>> to

---

From: "Shelby Moore" <[email-masked]>
Date: Wed, 18 Aug 2010 04:39:56 -0400

> browser can do it, not some other type of vulnerability.

"not some other type of vulnerability."

Or of course any attack in the network between client and server. Moving
to HTTPS would help.

Or of course if any of my client side code has a vulnerability, such as
injecting XSS.

Or of course if my server has a state-machine vulnerability.

etc...

In terms of the point below, once a site does mashups that are not framed,
it gets very difficult to not introduce vulnerability.  Crockford has
proposed <module> with JSON inter-frame communication:

http://json.org/module.html

---

From: "Shelby Moore" <[email-masked]>
Date: Wed, 18 Aug 2010 05:01:50 -0400

> minimize the complexity and maximize the type of trust granularity that is

I think it is already well understood that any choices the user is given
about security are useless if the user can not correlate them to something
meaning.

My proposal to whitelist SOP does not good if that opens some
vulnerability that causes the problem to appear at another origin than the
one the user whitelisted.

I think my categorization of the request vulnerabilities into 2 major
categories, shows that the user will always associate the blame with the
origin that was whitelisted, so those 2 very specific vulnerability
categories.

The next question is how useful is it?

---

From: "Shelby Moore" <[email-masked]>
Date: Wed, 18 Aug 2010 05:08:04 -0400

> Is this really the best forum for this?

I don't know.  Is this the best forum for the following?

I raised the security issue specifically with respect to SOP on network
requests, because it applies to whether we could enable P2P with this
proposed WS over new port + tunnel, and whether we must apply SOP to
Websockets in any case.

And I don't know where to have that very narrow security discussion else
where amongst motivated participants?

Then again, maybe it is simply a punt for this WG and just specify that
the implementation must decide?  That way as the future understanding
morphs on SOP, then WebSockets standard won't be voided.  I had read a
little bit of HTML5 and seems to be conflating itself with the security
and forcing certain SOP paradigms?

---

From: "Shelby Moore" <[email-masked]>
Date: Wed, 18 Aug 2010 05:18:54 -0400

> The next question is how useful is it?

Argh, I am angry at myself for so many typos.  I need to take break.

The should be "meaningful" and "for those 2 very specific".

And I meant "My proposal to whitelist SOP with respect to network requests
only".  I am not proposing to whitelist SOP for client resource access,
etc...

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 18 Aug 2010 11:46:39 +0200

Hi Shelby,

this thread has been quite intense (45 mails, quite long mail, in less 
three days)

as chair I want to clarify that

- a P2P approach is not in scope of this wg (pleae read the charter and 
check what is really the focus of this wg: 
http://tools.ietf.org/wg/hybi/charters )

- the HTTP Upgrade handshake has been in the protocol proposal since the 
first version of the spec (before it become a wg item for HyBi wg),
   this wg has then decided that if the Handshake is based on Upgrade 
and then looks like HTTP, it needs to be HTTP but at same time have to take
   in consideration the security problem higlighted in the discussion.
   Instead of continuing to discuss theoretically about it, I have asked 
people to provide text for an HTTP Upgrade handshake that reflect the 
decision
   and the concerns of the wg.

- a TLS NPN approach as been proposed and several people, in the ml, 
have showed support for it.
   I have asked Adam to provide text describing/proposing an handshake 
solution using TLS/NPN
   he has kindly provided it in 
http://www.ietf.org/mail-archive/web/hybi/current/msg03228.html

I haven't seen any people in favor of your proposal, if you want still 
push for it then I suggest you
to write down a design of how your solution would work, with a full and 
complete technical description of the handshake:
describing what kind of NAT/Firewall you have in mind, how they are 
supposed to interact etc. etc.
(as Adam has provided for TLS/NPN)
so that people can eventually read your technical proposal and comment 
on the solution you are proposing.
You can send the solution in a mail or write down in a draft and submit 
it to the IETF and then advertise it
in this mailing list and then patiently wait for people to comment it if 
they are interested.

Note also that this is not the right place to discuss the Security 
issues academically;
this wg is to discuss and solve Security issues that can be generate 
from technical solutions within the current version of the 
WebSocketProtocol draft
or from alternative design solutions proposed.

regards
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Shelby Moore" <[email-masked]>
Date: Wed, 18 Aug 2010 06:03:04 -0400

That is reasonable and I have no objection.

Thank you all for reading.

I will take a break first before even if I proceed on submitting any draft
proposal as you have recommended.  I understand there is no interest in it
amongst this group, so seems I would probably be better to spend my effort
else where, perhaps just implementing it in marketplace instead if/when I
decide is the opportunity is ripe.  Nevertheless, sometimes it helps to
write things down formally for a group first.

The P2P would come automatically by implementing WebSockets as tunneling
port with SOP removed, so it doesn't matter if it outside the WG charter's
scope.  And <script> already removes SOP. So I am not sure it is academic,
but nevertheless I told you I would always comply with the wishes of the
group with respect to my interaction of the group.

So noted.  Cheers all.

---

From: "Shelby Moore" <[email-masked]>
Date: Mon, 23 Aug 2010 08:04:13 -0400

> http://tools.ietf.org/wg/hybi/charters )

Wasn't the original focus of WhatG (from which this WG derived) about
WebApps? If so, then why are we ignoring 99% of the internet as the
following explains?

http://www.ietf.org/mail-archive/web/hybi/current/msg03548.html

P2P peers (clients) are the majority of the internet, by an
order-of-magnitude at least (as compared to HTTP servers).

I understand that W3C WebApps is a forum for the wider scope, but should
why should we roll another thing just for a different port?  The vast
majority of what we are designing here would the same on another port, so
kicking this back up to W3C WebApps, defeats efficiency and optimal
encapsulation principles of design.