W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: CfC: publish FPWD of Push API; deadline October 12

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 5 Oct 2012 15:06:53 -0700
Message-ID: <CA+c2ei-XMJRsfOPrkMvAdm0No=726rLr3QR5QpO5QwLWzJhdDg@mail.gmail.com>
To: Arthur Barstow <art.barstow@nokia.com>
Cc: "public-webapps@w3c.org" <public-webapps@w3c.org>
Hi All,

As usual, this is not the official mozilla position, as there is no such thing.

Several of us at at mozilla has been looking at push quite a bit
lately. We still don't have a clear idea of exactly what we think a
push system should look like. However we are concerned that a system
like the one in http://dvcs.w3.org/hg/push/raw-file/default/index.html
would be hard to implement at internet scale in a manner which keeps
it stable enough to be reliable for webapp developers.

First of all the fact that a single message from the application
server to the notification server can cause millions of messages from
the notification server to end-user devices makes us concerned that
it's too easy to DoS the notification server.

Second, using a message passing mechanism puts a lot of responsibility
on the notification server to never lose any messages. In the event of
a server crash or server overload the current solution seems to have
no way for the notification server to avoid dataloss.

As points of reference, both Apple and Google has been creating
similar Push solutions for iOS and Android respectively. Both of these
systems have struggled with scalability. The result for Apple was to
delay their solution for a year. The result for google was to
deprecate the system and they are working on designing something new.
The system proposed here is more powerful than both Apple's and
Google's system.

Finally we also have some security concerns. The messages passed
through the current API will likely very often end up being cleartext.
Application developers certainly can make sure to always encrypt the
messages on the server and then manually decrypt them in the client
(using for example the new crypt API). The API already requires
passing two cryptographically strong tokens to the API. Requiring
developers to also decrypt the message in the client means involving a
third cryptographically strong token. This is a lot for developers to
get right and if they don't, there's a risk of privacy or even
security problems.

These are all hard problems to solve, and so far we do not have a
counter proposal. But I figured that I should raise these concerns
since they seem relevant.

I'm also very aware that in the past I have pointed at message-passing
based protocols in the past as mozilla experiments. However lately we
have started at looking at alternatives due to the scalability issues
discussed above. Letting people know about this is another reason I'm
writing this email.

But since we don't have a counter proposal, and since I personally
generally think that people should be allowed to publish working
drafts, I don't oppose this FPWD.

But I can't say with certainty at this time that this is an API that
we're planning on implementing.

/ Jonas

On Fri, Oct 5, 2012 at 4:38 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
> The Push API Editors would like to publish a First Public Working Draft of
> their spec and this is a Call for Consensus to do so, using the following
> spec as the basis <http://dvcs.w3.org/hg/push/raw-file/default/index.html>.
> This CfC satisfies the group's requirement to "record the group's decision
> to request advancement".
> By publishing this FPWD, the group sends a signal to the community to begin
> reviewing the document. The FPWD reflects where the group is on this spec at
> the time of publication; it does _not_ necessarily mean there is consensus
> on the spec's contents.
> If you have any comments or concerns about this CfC, please reply to this
> e-mail by October 12 at the latest. Positive response is preferred and
> encouraged and silence will be considered as agreement with the proposal.
> -Thanks, AB
Received on Friday, 5 October 2012 22:07:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:47 UTC