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

Hi Jonas,

Thanks for your feedback. See comments inline.

Regards,
Eduardo.

On 6 oct 2012 at 00:06:53, Jonas Sicking wrote:
> 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.
>
One of the merits of the proposed solution is that it is a distributed architecture. There is not a single push server for the whole internet but instead a variety of servers may arise independently deployed by any kind of player (browser vendors, handset manufacturers, MNOs, app developers, etc), each of them dealing with as many users as it can/want. This plays in favor of scalability.

> 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.
>
Of course push servers should have policies that prevent non appropriate behavior by apps. We see multicast messages as an optimization to allow sending a single message to several webapp instances rather than having to send individual messages from the app server to the push server. However those servers having problems with this approach may decide not to offer this capability.

> 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.
>
No push notification server ensures delivery at 100%, not even messaging services. Moreover the intent of this framework is to notify (e.g. "You have new mails", "You have to update") rather than dealing with the whole communication between app server and webapp.

> 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.
>
As explained above, the distributed architecture will facilitate scalability.

> 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.
>
It is up to the app developers to encrypt the information E2E. I don't see it is such a big burden on the app developers. They may though decide it is not important for them.

> 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.
>
Any additional input from your side to enhance the solution is welcome.

> 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
>>

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Tuesday, 9 October 2012 06:15:23 UTC