I posted about making push notifications for the web last week:
. It's been getting a
surprising amount of press. I didn't offer a place to give feedback,
so gerv asked me to start a thread here.
The idea: let websites/apps send small messages to users when they're
not connected to the website. I think this will be most useful for
telling users about events: "You broke the build", "Bret wants to
party tonight", "Your mom joined Farmville", etc. Push notifications
are already in iOS and Android.
Current status: I made a prototype server
) and some prototype patches
for fennec (https://github.com/jbalogh/mozilla-central/compare/master...c2dm
Neither of those are ready to ship; I just wanted to understand the
problem better. I've talked to dougt and the WebAPI team, and that
blog was the start of bringing in a wider audience.
How I'm expecting it to work in Firefox:
1. A website calls the DOM API to request push permission.
2. If the user consents, Firefox talks to the Notification Service and
gets a new URL for the user.
3. Firefox responds to the API success callback with that URL.
4. The site sends that URL to its backend for storage.
5. The website backend sends a message to the saved URL.
6. The Notification Service sends the message to that user's Firefox.
I want this to work wherever you have a Firefox agent, using Android's
push API for Fennec, Apple's service for Firefox Home, and whatever
scales best for B2G and desktop. To identify you across devices, I'm
looking to use https://wiki.mozilla.org/Identity/Features/Sign_into_the_browser
The Notification Service is a backend app Mozilla would run to proxy
messages from apps to users. The DOM API passes around URLs so that
users can run their own Notification Service, and so that other
browsers can set up their own.
Right now there's no way for sites to interact with notifications they
send. We could fire an event if the page is open, but we don't have a
way to run an event handler if the website isn't open.
Inline responses to questions from
> Is the "body" plain text or HTML, or something else?
Plain text. Existing systems (Growl, Android, Apple, Ubuntu) don't
support HTML, and I think that's a good constraint. It limits the
security space, the bandwidth usage, and keeps the system simple.
The Desktop Notification spec (http://www.w3.org/TR/notifications/
takes a less emphatic stance, saying "The user agent may ignore any
markup in this string and treat it as plain text."
> Are clients forced to support actionURL (the notification system currently used in Ubuntu, for example, specifically removed support for clicking on a notification to take an action)?
No. I'd really like to say yes, but I think all I can do is strongly
suggest that clients implement this.
I had a discussion with an engineer for Ubuntu (@sil) and it seems the
Ubuntu Messaging Menu would be a better fit for push notifications.
> What are the rules, if any, about cookie-sending and Referer and Origin when the actionURL is accessed?
I had not considered specifying any special rules. I would treat it
like opening a new tab, so cookies would be sent normally and there
would be no Referer.
> Are there maximum lengths for any of the fields?
Yes, but I don't know the numbers yet. Apple limits messages to 256
bytes and Android limits it to 1024. The limits are important for
> What about icons of multiple sizes?
That's a good idea, but it may be impractical. Do you have an idea how
to specify that so it's easy for developers and efficient on the
network? Which sizes will we allow?
> Does iconURL lead to a privacy issue because the site can see if the user has read the notification? Can we allow, or require, inline icons?
Yes, it leaks data that the user agent opened the notification, like a
beacon image in emails. However, I don't think we could get inline
icons while maintaining the small messages size.
> Are there rules or guidelines to avoid accidentally clashing replaceIDs, such as a "org.mozilla.notification-somerandomstring" convention?
Each website would have a private replaceID namespace, so there's no
possibility of collision.
> How can we mitigate the problem of one (authorized) site spoofing notifications that look like those from another site? Will the in-browser UI show the origin of the notification?
We may need to show the origin, as Chrome's desktop notifications
currently do. I think we would also want a same-origin restriction on
the iconUrl and actionUrl.
> How does this handle a user who uses two different Web browsers? (e.g. IE at work and Firefox at home)
I don't know a good way to handle this. It may be up to the website
developers to say "I already have a URL for you, should I replace it?"
I don't feel good about this.
Ben Bucksch wrote:
> How is the privacy impact of following the user (IP addresses, usage times) reduced to the absolute minimum possible?
The Notification service won't be talking to Firefox unless you give a
website permission to send you messages, so it won't be on without
> Why the middle man Mozilla? Decentralization is a core principle of the Internet.
If we didn't have a proxy, would each of your favorite sites keep a
connection open to your device so they could send you their messages?
Our proxy won't be the only one; it'll be the default for Firefox users.
Ryan Schipper wrote:
> From a security viewpoint, the obvious choice to prevent spoofing is digital signatures. However, client-side (in this case the notifying website) developers who aren't familiar with PKI often find it too complex, resulting in a lack of third-party API implementations (see OAuth!). If Mozilla intends to develop, distribute and support the client API themselves, this is less of an issue. If this is not the case, OAuth 2.0 has some non-PKI options. Implementing all of the OAuth 2.0 protocol may be too heavyweight, but it would at least offer some inspiration.
I've been struggling with a way for the Notification Service to trust
the site that is sending messages. Currently, we rely on a long,
random sequence of characters in the URL that should only be known to
Firefox and the third-party site.
I don't want to require that sites set up some sort of API key with
each notification service they want to talk to, since that would limit
the ability to decentralize and would be a large hurdle for
developers. Any ideas here would be fantastic.
> The designers should also consider verifying the integrity and source of notifications received by the browser.
All of the communication between Firefox and the Notification Service
will be over https.
Sorry about the length. I'm excited to hear feedback, on this list or
directly to me.