Mozilla Services

WebPush does more than let you know you’ve got an upcoming calendar appointment or bug you about subscribing to a site’s newsletter (particularly one you just visited and have zero interest in doing). Turns out that WebPush is a pretty good way for us to do a number of things as well. Things like let you send tabs from one install of Firefox to another, or push out important certificate updates. We’ll talk about those more when we get ready to roll them out, but for now, we need to know if some of the key bits work.

One of the things we need to test is if our WebPush servers are up to the job of handling traffic, or if there might be any weird issue we might not have thought of. We’ve run tests, we’ve simulated loads, but honestly, nothing compares to real life for this sort of thing.

In the coming weeks, we’re going to be running an experiment. We’ll be using the Shield service to have your browser set up a web push connection. No data will go over that connection aside from the minimal communication that we need. It shouldn’t impact how you use Firefox, or annoy you with pop-ups. Chances are, you won’t even notice we’re doing this.

Why are we telling you if it something you wouldn’t notice? We like to be open and clear about things. You might see a reference to “dom.push.alwaysConnect” in about:config and wonder what it might mean. Shield lets us flip that switch and gives us control over how many folks at any given time hit our servers. That’s important when you want to test your server and things don’t go as planned.

In this case “dom.push.alwaysConnect” will ask your browser to open a connection to our servers. This is so we can test if our servers can handle the load. Why do it this way instead of a load test? Turns out that trying to effectively load test this is problematic. It’s hard to duplicate “real world” load and all the issues that come with it. This test will help us make sure that things don’t fall over when we make this a full feature. When that configuration flag is set to “true” your browser will try to connect to our push servers.

You can always opt out of the study, if you want, but we hope that you don’t mind being part of this. The more folks we have, and the more diverse the group, the more certain we can be that our servers are up for the challenge of keeping you safer and more in control.

One of the common questions we get working on the Web Push backend team, is “How do I broadcast a Push message to all my customers?” The short answer is, you don’t.

In the early days, I used say that Web Push is more like a doorbell than a walkie-talkie. Web push is designed to send a timely message of interest from a website to a specific customer. Like a doorbell, it’s pretty much a one to one thing.

There’s a lot you can do once you make the decision to make things one to one rather than one to many. For instance, it’s very easy to do end-to-end encryption. When you encrypt a message you make it so that only a certain number of people can read it. Ideally, a message should be readable by just two people, the person who created the message and the person who receives the message. Right now, a message is encrypted by you for your recipient and Mozilla can’t read it. We don’t have and will never see the key.

You can share the message with a group by sharing the key, but with every share, you run the risk of the key leaking to someone you don’t want to have it. On my wall at work, there are two pictures. One is of the TSA luggage security keys, the other is of a Yale 1620 key. The second one you may not have heard about. The 1620 is the master firefighter key for much of New York City, and many firefighters and building supervisors have a copy. Technically, it’s against the law to have an unauthorized copy, but that doesn’t stop many folks from acquiring a copy or some publications from printing very high definition versions so you can make them at home with a blank and a metal file. It’s a good example of having encryption that’s not really encryption. We want to avoid that kind of situation.

There are other issues at hand with doing a “broadcast”. One of the bigger ones is that “broadcast” has already been solved, every time you go to a web page. Web pages can be delivered securely via any number of means, and there are a whole host of existing protocols and procedures in place that make delivery fast and safe. How a browser knows to check a given page is a bit fuzzy, but again, there are hosts of protocols and functions in place to make that as lightweight as possible.

An important consideration for broadcasts (and one to one messages too): when do they need to arrive? Now? Soon? What does that mean really mean in the context of your app? Our system tries hard to deliver messages quickly, but we will never deliver them instantly. Likewise, there are all sorts of reasons that a device may not get a message quickly. The device may be off, out of range, or traveling and have no net access for the next few hours. Once a device is back online, it will try to reconnect and retrieve messages, but even this is essentially polling, and again, there are long established methods for doing these sorts of things. Determining how soon is “now” may help determine when your app really needs to poll for the broadcast elements.

Much like a doorbell or Philips head screwdriver, Web push is a tool for a specific task. It’s possible to use it for other tasks, but it’s ill suited and there are far better tools available.

If you’re interested in some of the more technical details, you can read much of the lively discussion that was held among the working group, as well as a preliminary draft for a webpush-aggregation service.

This article is a continuing series about using and working with WebPush and Mozilla’s WebPush service. This article is not meant to be a general guide, but instead offer suggestions and insight into best using the service. Some knowledge of Javascript, Python, or other technologies is presumed.

Sending out push notifications to Customers is a great way to ensure that they’re up-to-date with information that is of importance to them. What’s also important is that your growing business use this service efficiently so you don’t wind up wasting money creating and sending out messages that no one will ever read. In addition, not honoring response codes could lead to your server being blocked or severely limited in how many Subscription Updates it may be able to send.

Mozilla’s WebPush server will let you know if a Customer has unsubscribed, but it’s important that you notice and act on these. I have created a simple demonstration program that can help you understand what you will need to consider when creating a Push Subscription service.

Definitions

First off, let’s refresh a few terms we’ll use in this article:

App – The javascript web application that receives the decoded Push Message.

Customer – The end recipient of the Push Message.

Push Message – The content of the Subscription Update to be provided to the App by the User Agent and potentially viewed by the Customer.

Push Server – The service located at the endpoint URL which handles delivery of the Subscription Update to the User Agent.

Subscription – A Customer request to be updated. A Subscription contains an endpoint URL, and a set of keys that are to be used to encode the Push Message.

Subscription Provider – The subscription provider sends out Push Messages to User Agents to be read by Customers.

Subscription Update – The message sent by the Subscription Provider to the Push Server.

User Agent – The Customer’s browser, specifically, code internal to the browser which processes and routes Push Messages to your App.

Sending Subscription Updates

Sending a Push Message is a fairly simple operation, and thanks to modern libraries, easily done. It’s important to pay attention to the returned result. When a Subscription Provider sends a Subscription Update, the Push Service returns a response code. In most cases, the response code will be either 201 (Message Created) or 202 (Message Accepted). There’s subtle differences between those, but those differences are not important right now.

What is important is to know that the Push Server will return an HTTP error code along with a body that has extra information about what may have happened.

A possible 404 return message body might look like:
{
'errno': 102,
'message': 'Request did not validate invalid token',
'code': 404,
'more_info': 'http://autopush.readthedocs.io/en/latest/http.html#error-codes',
'error': 'Not Found'
}

In this case, there was a problem with the URL. More than likely it was corrupted at some point. In any case, the URL is now invalid and should not be tried again. The Customer’s record can be safely removed from storage.

This is also true for 410 return codes. These are subscribers who no longer wish to receive your updates. A Customer may unsubscribe for any number of reasons, and you should respect that choice. You can always ask the Customer to resubscribe later.

The Demo App

As an example, I’ve created a very simple demonstration project that uses Python3. This project does require Python3 to take advantage of native async programming to speed up delivery and message handling. Follow the steps in the README file to get it started. You can then navigate to http://localhost:8200 to see the page.

The test page (located in the /page directory) is very simple and only starts the process of subscribing once the Customer has requested it. Clicking the one button on the page will automatically create a Subscription Request and offer some script snippets you can use to send messages to the App.

To see what happens when a user unsubscribes, disable the permissions using the page information pip:

If you try to send a Subscription Update to that customer again, you will receive an error and should drop the subscription. An example error from pusher may look like:

Failed to send to HMV192av: No such subscription
For more info, see: http://autopush.readthedocs.io/en/latest/http.html#error-codes
Dropping no longer valid user: HMV192av

In this case, the subscription for user HMV192av has been removed, and the record was dropped from the user database.

It’s important to only ask your Customers to subscribe once they understand what they’re subscribing to. A Customer who is asked to subscribe to WebPush notifications without being given a clear indication of what they’re being offered may click the “Always Block Notifications” option.

When a user blocks notifications from your site, you may never get a chance to ask them again.

Following these simple guidelines will ensure that both you and your Customers are happy using the WebPush service.