Re: Draft for note to send to Push API editors/authors

In general, specifying push server <-> app server protocol is out of scope of Push API spec.
But there are two questions which cannot be answered without referencing to that protocol:
1. Semantic question. What's the meaning of endpoint url? Is it a temporary (capability) url or a persistent link to message thread? And how to ensure that having this url is enough for app server to negotiate with push server?
2. Security question. I'm very concerned about possible data leaks since Web Application isn't the same as mobile application.
Let's imagine that webpage has an XSS vulnerability. Then someone may run an evil script which (a) asks a user for push permission - since a spec says "User agents may support prearranged trust relationships" then in some cases it might be done without any warning to user; then (b) send an endpoint url and push registration id to Evil Server, which (c) negotiates push server and establishes new push message channel. Since that moment Evil Server may send push messages to user. Same kind of attack may be performed with MitM.
The only way to prevent such an attack is to force push server check whether Evil Server is allowed to send push messages to particular web app. But since the protocol is unknown, we can't check. So, in my opinion, Push API must explicitly refer to push server <-> app server protocol. Same for push server <-> user agent protocol.

14.12.2013, 01:31, "Alex Russell" <slightlyoff@google.com>:
> On Fri, Dec 13, 2013 at 6:43 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Thu, Dec 12, 2013 at 8:35 PM, Alex Russell <slightlyoff@google.com> wrote:
>>> As discussed on today's call:
>>>
>>> https://github.com/w3ctag/spec-reviews/blob/master/2013/08/Push_API_initial_comments.md
>>>
>>> Thoughts?
>>
>> A big problem with https://dvcs.w3.org/hg/push/raw-file/tip/index.html
>> is it not defining the protocol between the push and app server.
>
> I'm willing to overlook that. I can imagine use-cases for the web papering over proprietary APIs and enabling interop in other ways. We've got a long history of that. But to the extent that's the goal, I think it should be done well.

-- 
Konstantinov Sergey
Yandex Maps API Development Team Lead
http://api.yandex.com/maps/

Received on Tuesday, 17 December 2013 13:53:28 UTC