Push API

Please use "Edit with form" above to edit this page.

Item Reviewed

Push API
Target	* https://www.dropbox.com/s/xa3gqxyd7ycpw0y/Push%20notification%20server%20APIs.docx Full Query ID Summary Priority Status 776501 [Security Review] Push Notification API P4 RESOLVED 1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

{{#set:SecReview name=Push API |SecReview target=* https://www.dropbox.com/s/xa3gqxyd7ycpw0y/Push%20notification%20server%20APIs.docx

Full Query

ID	Summary	Priority	Status
776501	[Security Review] Push Notification API	P4	RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

}}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

Background documentation:

• https://www.dropbox.com/s/xa3gqxyd7ycpw0y/Push%20notification%20server%20APIs.docx
• https://bugzilla.mozilla.org/show_bug.cgi?id=776501

Overview of feature:

• allow a Web App to recieve notifications via a push mechanism
• Carrier provides a Notification server which stores and forwards all the messages to client on behalf of the application server

Normal flow of actions
(see linked document above for further detail)

1. User powers on the handset
2. First app that wants a PUSH API
3. App asks gecko to listen to push messages
4. Gecko if not previously connected, registers itself as a UA with notification server
5. Gecko registers the Web App, (token and public key)
6. Notification server stores this information in database, and generates a url to send back to UA.
7. Gecko send url to Web App
8. Web App sends url to App server
9. When app wants to push, the app server sends a post to the URL provided

Actors & communication
Web App<-->Gecko<-->Notification Server (carrier)<--> Application Server (developer)

Communication Web App

     < - register(WAToken, pbk)->

Gecko (user agent)

   - https GET (retrieve UAToken)
   - web socket connection (Register UA, register  WA, getAllMessages, ACK)
   - udp datagram Wakeup packet

Notification Server

   - https POST API 

Application Server

What solutions/approaches were considered other than the proposed solution?

`

Why was this solution chosen?

`

Any security threats already considered in the design and why?

`

Threat Brainstorming

' {{#set: SecReview feature goal=Background documentation:

• https://www.dropbox.com/s/xa3gqxyd7ycpw0y/Push%20notification%20server%20APIs.docx
• https://bugzilla.mozilla.org/show_bug.cgi?id=776501

Overview of feature:

• allow a Web App to recieve notifications via a push mechanism
• Carrier provides a Notification server which stores and forwards all the messages to client on behalf of the application server

Normal flow of actions
(see linked document above for further detail)

1. User powers on the handset
2. First app that wants a PUSH API
3. App asks gecko to listen to push messages
4. Gecko if not previously connected, registers itself as a UA with notification server
5. Gecko registers the Web App, (token and public key)
6. Notification server stores this information in database, and generates a url to send back to UA.
7. Gecko send url to Web App
8. Web App sends url to App server
9. When app wants to push, the app server sends a post to the URL provided

Actors & communication
Web App<-->Gecko<-->Notification Server (carrier)<--> Application Server (developer)

Communication Web App

     < - register(WAToken, pbk)->

Gecko (user agent)

   - https GET (retrieve UAToken)
   - web socket connection (Register UA, register  WA, getAllMessages, ACK)
   - udp datagram Wakeup packet

Notification Server

   - https POST API 

Application Server |SecReview alt solutions=' |SecReview solution chosen=' |SecReview threats considered=' |SecReview threat brainstorming=' }}

Action Items

Action Item Status	None
Release Target	`
Action Items
'

{{#set:|SecReview action item status=None

|Feature version=` |SecReview action items=` }}