Notification Management: Putting Users in Control Jim Fenton (@jimfenton)

The Nōtifs Vision ๏  Notifications are a “thing” -  Not well served by existing services,

especially email -  Growing usage, particularly mobile

๏  Looked at how we use email, SMS, etc. -  Optimize for this subset of these uses -  Runs alongside these services

๏  Applications => apps, so Notifications => nōtifs

Priorities

Categories

Official Approval

Internet of Things Social/Advertising

…and many more

What is a Nōtif? ๏  One-way

๏  Solicited, Opt-in

๏  Time-sensitive

๏  Perishable

๏  Short (typically)

NotificationAgent

PhoneCallSMS,

App push

GrowlManagement,Authorization

NotificationsAuthorization TableRules

Bank EmergencyServices Retailers

SocialMedia

ApprovalRequestsCalendar

For Notifiers: ๏  Direct feedback when nōtifs are accepted

on behalf of users

๏  No need for third-party bulk senders

๏  Spam-and phishing-resistant -  No junk mail folders to avoid

๏  Less clutter => more impact

For Users: ๏  Centralized management/unsubscribe

๏  Control over how (or whether) to be alerted when nōtifs arrive

๏  Spam and phishing-resistant

Spam and Phishing? ๏  No widely-used addresses

๏  Notifs are signed by the notifier domain -  Protects against theft of notifier’s database

๏  No From address => nothing to spoof -  From address in authorization, not message

Privacy ๏  Notifiers don’t get persistent contact info

๏  Addresses are unique, opaque -  (and in the background)

user@example.com

415 555-2368

🚫🚫

Alerts ๏  Users describe their push methods to

notification agent -  Cell phones (SMS), voice phones, email, app

push

๏  Rule sets decide if/how to alert the user -  Based on priority, category, notifier -  Can be time of day based

Opting In

NotificationAgent

UserNotifier

1. Request authorization to notify

2. Browser redirects toNotification Agent, User

agrees

3. Notification addresssent to Notifier

Cutting the Clutter ๏  Less nōtif clutter: Good for everyone -  Users get relevant nōtifs -  Nōtifs have more impact

๏  3 mechanisms: -  Update -  Deletion -  Expiration

๏  All best-effort

Update ๏  Notifier replaces a previous nōtif -  Tornado watch -> warning -  More info on wanted criminal -  Updated auction bid status -  Error in original nōtif

Delete ๏  An update that deletes the nōtif -  AMBER Alert: Child is found -  Requested approval no longer needed -  User left vicinity of location-triggered notif -  Alarm condition has been cleared -  Special offer sold out -  Voicemail has been collected

Expiration ๏  Timed automatic deletion -  Coupon expired -  Tornado warning expired -  Auction over -  Calendar event has passed

๏  Doesn’t require notifier activity

Running a Notification Agent ๏  Open-source implementations will be

available

๏  Comparable to running a website or blog -  Some will run their own -  Some will rely on commercial services -  Think Wordpress

๏  Outside commercial services can provide support for user alerts

Being a Notifier ๏  Simple enough for IoT devices -  Modest persistent storage and crypto

๏  No need for special ISP arrangements like static IP addresses

๏  Communicate with notification agents via Web API

๏  Toolkit libraries will make this easy

Nōtifs Summary ๏  Something I wish I had

๏  An API purpose-built for notification

๏  Vendor-independent

๏  Not burdened by legacy protocol requirements (like email)

๏  BUT: Deploying something new is hard