- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 5 Oct 2012 15:06:53 -0700
- 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