Comments from Gerv

• Is the "body" plain text or HTML, or something else?
• 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)?
• What are the rules, if any, about cookie-sending and Referer and Origin when the actionURL is accessed?
• Are there maximum lengths for any of the fields?
• What about icons of multiple sizes?
• 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?
• Are there rules or guidelines to avoid accidentally clashing replaceIDs, such as a "org.mozilla.notification-somerandomstring" convention?
• 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?

Responses from Sicking:

• plain text
• We can definitely make it optional. I wonder if we should return a set of capabilities along with the URL to let the page know what parts are supported. This will work well when we expand the API to support things like setting "badge numbers" for apps etc.
• Setting the Referer to the origin of the site making the request seems like a good idea. Cookies and Origin would be sent as normal (which means that no Origin header is sent).
• Yes, we should impose some limit to be determined.
• Good question, I don't have a good answer.
• Inline icons would be too expensive to push for each notification. One option would be to require that icons are provided when the notification URL is originally requested. That way we could handle multiple sizes too.
• replaceIDs are scoped to within the origin, so sites can use whatever scheme they want.
• How do we handle this for the Notification API?

Comments from Hixie

• How does this handle a user who uses two different Web browsers? (e.g. IE at work and Firefox at home)

Responses from Sicking

• UAs should allow setting custom notification services. For example, in Firefox we would by default deliver messages through a Mozilla server, but allow users to choose other notification delivery providers. By choosing the same delivery provider in all browsers, it should be quite possible to make it work. The main problem would be making sure that the delivery provider knows your identity in all browsers, possibly by making you log in when you first set up the service.

Comments from Ben Bucksch

• How is the privacy impact of following the user (IP addresses, usage times) reduced to the absolute minimum possible?
• Why the middle man Mozilla? Decentralization is a core principle of the Internet.

-- Ben Bucksch

• We "only" leak that information to the delivery service. I can't think of a way to allow the delivery service to send messages to the client without knowing the clients address. Suggestions welcome.
• Nothing in the API or protocol forces this to go through Mozilla. We can easily let the user choose any delivery service. However we need to go through a delivery service rather than having each website send messages to the device directly in order to reduce IP address/phone number/usage time leakage.

-- Sicking

We don't "need" to go through Mozilla or anybody. When I browse the web, I already contact servers directly and they already see my IP address. Moreover, the server sees every webpage I visit and when. I can only prevent that by using a proxy all the time, but then the proxy can monitor me, and I'd rather avoid that. We have a similar tradeoff here. I argue the sensibility of my Internet usage times is less sensitive than the information which concrete webpages I visit, and the latter already leaks.

This is changing core principles ("decentralization") of the Internet, and I don't see a good justification for that. You are basically forcing a proxy on everybody. If we wanted that, we'd all use HTTP proxies already.

-- Ben Bucksch

Ben, you're missing the point of this feature. We already have decentralized data pipes: XHR, WebSockets, EventSource. This feature allows web services to "push" notifications to a client without having to worry about whether the client is on- or off-line. It's "store and forward", sort of a one-way micro e-mail (or app-specific SMS?). This feature is more interesting for mobile web apps than browser web sites, and it would be easy to imagine that the default middleman for a B2G device could be the carrier rather than Mozilla (and the carrier already knows where you are).

-- Dan Veditz

Comments from Ryan Schipper

• 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.
• The designers should also consider verifying the integrity and source of notifications received by the browser.

Comments from JR Conlin

A few extra notes based on some design pushes from outside (notably privacy and federation)

The RequestURL requires an optional (UseEncryption) boolean flag argument to indicate if the notification will be encrypted. If this value is set to "true", the PushURLResult will include a keyBundle object (to be used by the encryption libraries)

The keyBundle would also be returned by the getCurrentURL() result, should it have already been defined.

the request.response object would also optionally contain the following fields: pushServer: URL for the UserAgent to poll when looking for notifications from a server (this allows for federation to non Mozilla servers) pushWebsocket: Websocket address for Notifications. Please note, for domains other than those owned by mozilla, the pushServer and pushWebsocket should be domain constrained much as XHR calls are, for obvious security reasons.