CloudServices/Notifications/Push/Security

Push notifications are a way for websites to send lightweight messages to users when the user is not on the site. They are similar to push notifications for iOS or Android devices.

Apps will send messages to a backend Mozilla service, which will queue messages until a user comes online. A user can have many devices; her queues will be synced between devices.

Diagram

Players

• Device: Firefox running on a desktop or phone; a user can have multiple devices
• Push Service: Mozilla servers managing notification queues
• App (Server): Third-party application backend sending notifications to a user
• App (Client): Third-party website requesting notification permissions

The API

An App (Client) requests permission to use push notifications:

 navigator.notifications.requestPermission(callback)

If the user accepts, the Device runs callback with a URL pointing to a queue on the Push Service. The App (Client) is responsible for sending the queue URL to the App (Server) for future notifications.

The Device is responsible for creating a queue:

 POST push.mozilla.org/queue

It returns a unique URL for an App (Server) to talk to a Device.

The App (Server) sends messages to the queue:

 POST push.mozilla.org/queue/<queue>
 <message>

The Device pulls messages from the queue and displays them for the user:

 GET push.mozilla.org/queue/<queue>

Security Considerations

A mailbox URL is an opaque random string that lets an App (Server) communicate with a Device.

All communication with the Push Service will be over https.

App (Server) trust

• Authentication: provision an API key for the app which must be sent with all requests
• Authorization: match the API key to the expected mailbox domain

Device trust

• Authentication: provision a device token the first time we need to set up a mailbox
• Authorization: only display messages for mailboxes matching the token

Spoofing

• Include origin domain when displaying messages
• Enforce same-origin policy for action URLs

Message Encryption (optional)

Along with a mailbox URL, the Device will call the requestPermission callback with a secret key. If the App (Server) stores both the URL and the secret key, it can use symmetric encryption to encrypt the message, which will be decrypted on the client.

Security Checklist

These questions should be answered by the defenses listed above.

• How does the push service know it's talking to the right device?
• How does the push service know this message is really from <domain>?
• How does the user trust that a message is from <domain>?
• How does a site prevent the push service from reading its messages on the server?

Prior Art

Apple

• Push Notification Service
• Security Architecture
• Devices send a device certificate to the Push Service
• App (Server)s send a provider certificate (provisioned by Apple) to the Push Service

Android

• Google Cloud-to-Device API
• Devices are authenticated by the user's Google credentials.
• App (Server)s store a RegistrationID (for the app) and a ClientLogin token (for the user) and must include both when sending messages.

Urban Airship

• Urban Airship Authentication
• App Servers send an ApplicationKey: Secret (provided by UA) pair to the Push Service