CloudServices/Notifications/Push: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
=Push=
=Push=
== Project Overview ==
== Project Overview ==
The next version of Notifications will focus on providing external sources a means to provide semi-anonymous data to a user, regardless of where the user is connected.  
Push notifications are a way for websites to send small messages to users when the user is not on the site. iOS and Android devices already support their own push notification services, but we want to make notifications available to the whole web.  


The input provided to the system will be one (or more) JSON formatted, valid Notification messages. These messages are verified, handed to the Post Office for dissemination to the Distribution nodes, based on user preferences. The Distribution nodes then broadcast the properly addressed notifications as appropriate to the channel type they represent.
Intro Blog: http://jbalogh.me/2012/01/30/push-notifications/


Message processing should be simple, fast, and able to handle a large amount
of traffic in the most efficient manner possible.


[[https://wiki.mozilla.org/File:Push_Whiteboard_20110726.jpg whiteboard]]
== Get Involved ==
=== Code Repository ===
=== Code Repository ===
''Stable'' - TBD
''Devel'' - https://github.com/jbalogh/push
 
''Devel'' - https://github.com/jrconlin/moz_push
 
''IRC'' - TBD
 
''Email'' - TBD
 


== Requirements ==
== Requirements ==
Line 46: Line 34:
A user no longer wishes to receive alerts for a given notification. The user  
A user no longer wishes to receive alerts for a given notification. The user  
loads their admin and control panel and disables the queue. The user can either temporarily silence a given notification queue (in which case, notifications are still collected, but not immediately alerted to the user) or delete the queue (in which case, incoming notifications are rejected, existing notifications are removed, and the queue is no longer associated with the user.)
loads their admin and control panel and disables the queue. The user can either temporarily silence a given notification queue (in which case, notifications are still collected, but not immediately alerted to the user) or delete the queue (in which case, incoming notifications are rejected, existing notifications are removed, and the queue is no longer associated with the user.)
== Operational Requirements ==
The operational system is designed to run on a minimal configuration. Because of large scale cost issues, the Mozilla hosted system will not be using constant connections in order to provide real-time message updates, but will instead rely on polling. Smaller sites (with under one million subscribers) may wish to take advantage of the long session Server Sent Event based notification system.
For production the system currently uses:
1. a Redis based index system (for queue management, token resolution, and housekeeping)
2. a file, stored in a shared directory based on the user's token, containing the message body.
For non-production systems (or smaller footprint installs) you may wish to use the mongo storage option, which stores all index data and messages into a simple mongo db.
== Releases / Roadmaps ==
TBD
== Design ==
=== Input ===
The input process should be as simple and direct as possible. In this case, the Push input process receives a JSON token which follows the Notifications format:
    { "body": "{
        \"token\": \"Base64_Token\",
        \"timestamp\": CreationTimestamp,
        \"ttl\": SecondsToLive,
        \"ciphertext\": \"Base64_EncryptedMessageBody\",
        \"IV\": \"Base64_Nonce\"
        }",
      "HMAC": "Base64_HMACValueOfBody"
    }
Since the "token" content is enough to properly address the Push input packet, no other additional info is required.
The input process performs general validation including:
    * check message format (ensure it's a format valid Push input packet)
    * check HMAC
    * check the timestamp + TTL to verify the message is still valid.
 
The input process then sends validated, full Push input packet to the Post Office. Invalid input packet candidates are rejected with no error.
=== Post Office ===
Post Office is responsible for determining the routing of a Push input packet based on the token values of the message. It decrypts and validates the input packet, determines the user associated with the packet.
The Post Office only accepts valid JSON formatted Push input packets. Invalid input packets are ignored.
The Post Office outputs the data block to the Distribution utility including:
* user's mozilla ID
* ciphertext
* domain origin of input packet
=== Distribution ===
The distribution mechanism looks up the registered distribution channels assigned by the user, and then sends the ciphertext to the appropriate channels with associated destination info. (e.g. user has registered to be notified via iOS, Jabber, and Android when receiving an update from gmail.com)
The secondary notification system is TBD.
=== Support Systems and requirements ===
====Input====
It has been requested that the Push system integrate with the CherryPicker project. This integration would use CherryPicker to monitor incoming mail messages, discover messages of interest and pass them to the Push Input node.
Questions:
* What information will come out of CherryPicker (ideally, just the JSON elements)?
* How will CherryPicker pass it's content to the input system (RPC, REST, command line, socket)?
* Can we trust the origin of the message, and if so, how should we pass that info to the Post Office?
* What other inputs would be useful/should we consider?
====Post Office====
Post Office will have to resolve a user from the token. This means that the user data must be feed and coordinated between the Post Office instances.
Notes:
* This will continue to use the existing architecture as much as possible. the *MQ will be used mostly for internal routing and will be d-emphasized as a client connector.
====Distribution====
Distribution will need to have:
* User Distribution registration and management
* simple Distribution rule engine
* Config Data storage (redis?)
In addition, the framework will have to be able to support multiple output formats, including potential candidates like Jabber, Server Sent Events, etc.
== Push v. 0.5 Technical Overview ==
=== Definitions: ===
Client – A third party requesting the ability to send or receive notifications from a User via the User Agent.
Distributor – A centralized hub which coordinates communication between the Clients and the User Agent
User – The final consumer of push notification (generally presumed human)
User Agent – The application acting on the User's behalf (generally presumed to be the browser)
=== Overview: ===
Push allows for small, semi-anonymous messages between a Client and a User Agent via a Distributor. The User Agent can be one or more devices, allowing the push notification to reach the User Agent where-ever or whenever they connect to the web. The notification content is secured from tampering and unauthorized viewing by encryption with keys provided by the User Agent to the Client.
Clients receive a token representing a party that wishes to be notified of an event. When an event of interest occurs, the Client notifies the Distributor, which then passes the encrypted push notification to the User Agent for processing.
=== Components: ===
==== User Agent Configuration: ====
The first requirement of the system is that the User Agent register with the Distributor. This may be accomplished in any suitable manner, however once the User has properly authenticated against the Distributor, the User Agent makes a <tt>new_subscription</tt> request. This call will create a new subscription with the Distributor system (or return the subscription information for a previously created session for the user).
The returned information will contain the subscription ID, which will allow the User Agent to connect to the Distributor for Notifications. (The method of distribution is dependent on the method used to connect, ex. SSE would use “http://$host/feed/$ID”, direct AMQP would use the ID as the Queue Name, etc.)
Once the association is made to the User Agent, the Distributor can begin sending any new or previously unread messages.
==== Client Javascript: ====
See (lib/main.js for most code related to the client)
The User Agent contains an injected element called <tt>navigator.pushNotifications</tt> . This currently has a single method exposed to Clients <tt>requestPermissions(''params'', ''callback'')</tt>. The “params” argument contains server provided elements such as the application name (? Is this an echoed element that needs filtering/validation ?) & the account id ('account'). The publishing site and port is recorded by the plugin and stored as the 'host'. The <tt>navigator</tt> element is either browser native or injected from the notifications plug in.
Once auth has completed, the server args are passed to the Client element for processing.
==== Server Distribution: ====
A server wishing to notify a client of a new notification has several methods available to do so, however for this discussion we'll focus on the PostOffice process.
A server composes the notification as a JSON packet containing whatever content the client should expect. (Remember, notification content is specific to the client.) It then serializes the JSON and encrypts using the key previously provided by the client and stores in a wrapper JSON object as the “cyphertext” element. The following exploded object shows the structure of the notification JSON object:
{"body": "{\"timestamp\": 1312243342,
            \"token\":\"+rQAeMokXWNS14YFnJCaqoz51MngCMuVmHQ15sauyLA=\", 
            \"IV\": \"MnegZvCCMZK5W2BbPqPc9g==\",
            \"ciphertext\": \"mary had a little lamb. She had it with mint jelly\",
            \"ttl\": 300}",
  "HMAC": "b03d25f5753e935bdabd1b6eca361ca9"}
In case it's not clear, “body” is a serialized JSON string containing the elements:
'''Timestamp''': the UTC timecode for when the notification was created.
'''Token''': the subscription ID (previously sent to the server during user facing notification auth)
'''IV''': decryption information (e.g. public key for AES)
'''ciphertext''': the notification content string to decrypt and use.
'''Ttl''': the number of seconds past the timestamp for the notification to live or be valid. Notifications past expiry will be deleted or ignored.
The HMAC is hash result based on the previously sent HMAC key (also included by the client in the post auth response).
The serialized JSON string can be sent to the PostOffice URL via a POST call, with the notification as the POST body.
== QA ==
== Support ==
== Localization ==
== Security & Privacy ==
== Legal Considerations ==
== Other Notes / Whiteboards ==

Revision as of 18:49, 3 February 2012

Push

Project Overview

Push notifications are a way for websites to send small messages to users when the user is not on the site. iOS and Android devices already support their own push notification services, but we want to make notifications available to the whole web.

Intro Blog: http://jbalogh.me/2012/01/30/push-notifications/


Code Repository

Devel - https://github.com/jbalogh/push

Requirements

  • Transparency: Process MUST be transparent to user. For example, other than clicking "Yes" or "No" to a dialog of the web app requesting to send notifications, the user should not be aware of the underlying mechanics of the process.
  • Security: From the point a message leaves the sender until it arrives at its intended recipient, all communications may not be easily readable by unauthorized persons (e.g. anyone besides the sender and the recipient). By "easily" we mean it should not be trivial to decrypt a message, but take a long enough time and resources so that such effort is not viable. Encryption is optional, but the key should be provided by the client service.
  • Anonymity: Web apps MUST not know anything about user (insofar as the communication between the web app and server is concerned; if the user is logged in to GMail and signs up for notifications, then obviously Google can associate the resulting subscription with the user who created it).
  • Portability: Service MUST work with any device that supports the protocol.
  • Control: The user should be able to disable or delete any created notification channel. Upon deletion, the user should not see any additional messages sent to that channel. The sender should be notified that messages to that channel are no longer being accepted.

Use Cases

Email Notice - A webapp provider wishes to communicate with their audience. The provider has a set of user tokens for their customers. They then send messages to token@mozillamessaging.com (domain tbd). Notifications parses the message, wraps the message in a useful wrapper, and then relays the message to the registered user address, thus providing the user the ability to quiet noisy providers, drop compromised addresses and otherwise manage their message delivery.

In addition, these alerts may be passed on to other devices/platforms that are running the webapp. (Note, some care should be exercised to prevent user from being "spammed" by these sorts of notifications. e.g. Same Notifications appearing on every device, email and other notification system they possess.)

Event Alert - A user wishes to receive alerts when an event of interest is about to happen. The user signs up with a service, and the service receives a user token. At a significant time, the service then sends a JSON notification to that user token, which causes the notification to appear on any browser that the user is currently using.

Cancel Alert - A user no longer wishes to receive alerts for a given notification. The user loads their admin and control panel and disables the queue. The user can either temporarily silence a given notification queue (in which case, notifications are still collected, but not immediately alerted to the user) or delete the queue (in which case, incoming notifications are rejected, existing notifications are removed, and the queue is no longer associated with the user.)

Retrieved from "https://wiki.allizom.org/index.php?title=CloudServices/Notifications/Push&oldid=393962"