Re: CfC: publish FPWD of Push API; deadline October 12
On 10/5/12 7:38 AM, ext Arthur Barstow 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. Although there were no objections to this CfC, Jonas raised a number of concerns in http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0042.html. Although we will have an opportunity to discuss these comments in Lyon, I would like the spec Editors to add an Issue Block in the Security and Privacy concerns section and include a link to Jonas' comment. Bryan, Eduardo - I will contact you off-list about preparing the spec for FPWD. (See http://www.w3.org/wiki/Webapps/SpecEditing if you are unfamiliar with the W3C's TR publication process.) -Thanks, AB
RE: CfC: publish FPWD of Push API; deadline October 12
Hi Art, An issue has been added as requested in the current draft [1]. [1] http://dvcs.w3.org/hg/push/raw-file/default/index.html Thanks, Bryan Sullivan -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, October 15, 2012 4:15 AM To: public-weba...@w3c.org; SULLIVAN, BRYAN L; EDUARDO FULLEA CARRERA Subject: Re: CfC: publish FPWD of Push API; deadline October 12 On 10/5/12 7:38 AM, ext Arthur Barstow 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. Although there were no objections to this CfC, Jonas raised a number of concerns in http://lists.w3.org/Archives/Public/public- webapps/2012OctDec/0042.html. Although we will have an opportunity to discuss these comments in Lyon, I would like the spec Editors to add an Issue Block in the Security and Privacy concerns section and include a link to Jonas' comment. Bryan, Eduardo - I will contact you off-list about preparing the spec for FPWD. (See http://www.w3.org/wiki/Webapps/SpecEditing if you are unfamiliar with the W3C's TR publication process.) -Thanks, AB
Re: CfC: publish FPWD of Push API; deadline October 12
Art, I uploaded an update to the editor's draft [1] that aligned the three missing references with a respec biblio update pull request that is pending acceptance by Robin. So once biblio.js is updated, all of the references should work. [1] http://dvcs.w3.org/hg/push/raw-file/default/index.html Bryan Sullivan On Fri, Oct 5, 2012 at 4:38 AM, Arthur Barstow art.bars...@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 -- Thanks, Bryan Sullivan
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.bars...@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
Re: CfC: publish FPWD of Push API; deadline October 12
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.bars...@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
