Introducing Nōtifs: User-controlled notifications

Every day, we receive many notifications. Some of these, such as tornado warnings, are very important and time-sensitive. Others, like notification of shipment of an order or a comment on a social networking discussion, are less so. Still others, perhaps a notification of a special offer at a store, are of casual interest.

We receive these notifications through a variety of mechanisms: email, text messages, push notifications on mobile devices, telephone, and postal mail. Services that originate notifications (“notifiers”) often have to support several mechanisms to send notifications and in many cases a given notification will be sent and received multiple times due to delivery uncertainties.

Nōtifs is a notification management service designed to help users subscribe to and manage the notifications they want, and for notifiers to have a reliable way to reach them. Compared with existing notifications media such as SMS and particularly email, nōtifs are resistant to abuse like spoofing and phishing and give the user complete control, including the ability to unsubscribe to any notification instantly.

Notification Agents

Cloud-based notification agents are at the heart of Nōtifs. Much like email servers, notification agents are decentralized and users can choose a commercially operated agent or operate their own. Agents act on behalf of the user by receiving nōtifs from notifiers and redistributing them to the user, sometimes as push notifications or in other cases to be retrieved like email.

Notifiers send nōtifs to the notification agent through a simple Web-based API. Unlike most currently-used methods of notifying users (notably email), the notification agent gives immediate feedback to the notifier whether the nōtif was accepted or not. Because nōtifs are opt-in and signed by the notifier, spam filtering is unnecessary: unauthorized nōtifs are simply rejected by the agent.

Upon receiving a valid nōtif, the notification agent stores it in its database and then uses a rule set to determine what else should be done. For example, when a burglar alarm system goes off, the agent might send an SMS to the user’s mobile phone and a phone call to their vacation home. The user specifies the rule set and methods for reaching them via a web-based interface. The stored nōtifs are also available for the user to view and manage over the web interface.

Modification, deletion, and expiration

A major goal of Nōtifs design is to provide a high “signal-to-noise” ratio. Since much of the noise consists of obsolete or irrelevant information, Nōtifs provides the ability for notifiers to modify or delete a previously-sent nōtif, on a best-effort basis. Notifiers are encouraged to include an expiration date/time in their nōtifs so that when the tornado watch ends or the sale at the store is over, the user doesn’t still have to review and delete the nōtif. Obviously, if push notifications are sent, those can’t be recalled, but at least the user isn’t burdened with deleting obsolete nōtifs from the agent.

Motivating Deployment

In order to achieve significant deployment, Nōtifs provides advantages to both the user and notifier compared with current notification options. These are:

For the user:

• Opt-in to each notification source over an intuitive web interface or mobile app
• Ability to deauthorize any notifier immediately
• Rule-based push notifications that can be customized as the user’s situation changes
• Ability to generate nōtifs from legacy sources such as email, SMS, and RSS feeds
• Ability to label nōtifs using names that are meaningful to the user, as opposed to domain names, etc.

For the notifier:

• Immediate feedback on whether a nōtif has been accepted and will be presented to the user
• REST API compatible with many languages and libraries
• Greater user impact by presenting the user with only relevant information
• Ability to reach the user over multiple push media through a single service
• Ability to reach users directly, without the use of a sending provider
• Feedback about users who deauthorize, avoiding wasted effort sending unwanted nōtifs, enabling possible follow-up via other media to encourage re-engagement

Security and Privacy

Use of Nōtifs does not reveal any information about the user to the notifier other than the name of the notification agent. Nōtifs authorizations are each represented by a random 124-bit random ID that specifies the identity of both the recipient and sender to the agent. If the user wants to receive email or SMS notifications of certain classes of nōtifs, those addresses are revealed to the user’s agent, but need not be revealed to the notifier. The notifier does not need to store any other user-identifying information to send nōtifs, although in many or most cases they will have other information about the user.

The 124-bit address IDs, provided they are sufficiently random, provide sufficient security against attempts to “spam” users by guessing their addresses. But since notifiers may be subject to breaches that might reveal these addresses, nōtifs are cryptographically signed as well. The agent obtains the public key for verifying these signatures from the notifying domain’s DNS, in a manner very similar to DKIM signatures used for email. If a breach does occur, the notifying domain can change the public keys so that user reauthorization is not required.

More information

More information on Nōtifs is to come; to stay informed, contact me at notifs@bluepopcorn.net.

Update 10/31/2014: Slides from a presentation on Nōtifs that I gave at the Internet Identity Workshop this week can be found on Slideshare.