The way the current specification is defined, a developer would call isRegistered and, if the application is already registered, they then call register to obtain the endpoint. The problem I see is that this results in a redundant query to local storage, one to check if the record exists (which is thrown away), and then, in most cases, one to obtain the record.

If we made it so that isRegistered returned the result of that query rather than true/false, it would still perform the service of checking to see if the endpoint already exists, but then it would save the developer from having to call register() regardless of the result. This has the added bonus of making the call to register() be more accurately descriptive, since it would only be used if you weren't already registered, and it would be used to perform the act of registration.

I suppose this implementation would also imply a name change from isRegistered to getRegistration or something.

Given the example in the specification:

navigator.serviceWorker.ready.then(function (serviceWorkerRegistration) {
  serviceWorkerRegistration.pushRegistrationManager.register(...);
});

This obviously is very verbose. We renamed "push" to "pushRegistrationManager" to avoid potential confusion with Array.prototype.push per a comment from the TAG.

A mid-ground would be to consider renaming this to "pushRegistration", as "manager" doesn't add any value in this case (there's only one active registration per SWR). However, there is a PushRegistration object as well, used by various methods on the PRM.

Straw man: Change the PushRegistration interface to be a dictionary instead. That way it doesn't have to be exposed on the global, and we can rename pushRegistrationManager to pushRegistration, avoiding developer confusion.

Currently for interfaces such as PushRegistration the spec uses a mix of a and code. Sometimes one, sometimes the other, sometimes both. This should be made consistent.

The specification does not define whether the push-register (or pushregistrationlost) event should be invoked when a user clears their browser cache/cookies.

While this is part of the larger question of Push + browser cache problem, it would be good to nail down for the push-register event and in the privacy section what the expected behavior is.

Straw-man: We must not invoke push-register (or pushregistrationlost) when the user clears their browser cache. The UA could provide for an interface themselves to clarify to the user that expected functionality might be lost.

As discussed here: https://github.com/w3c/push-api/pull/23/files#r17244274

The abstract has a few issues:

• It does not mention service workers though they are a critical dependency that shapes a large part of the API.
• It refers to a list of other specifications that are not normative. Most of them seem not very relevant to the reader, at least not when reading an abstract. Perhaps some of this can help clarify some details further down in the document.

I know that this was talked about previously, but I'd like to challenge that decision.

(I'm not clear whether the restriction is per origin or per service worker scope. I don't think that matters here.)

I have several reasons:

1. Origins can have multiple applications. Having them share a push notification registration is a significant burden on those applications. And even within those applications, separation of functions can be valuable. For example, an application as simple as gmail [sic] benefits from different notification channels for email, chat messages and calling, not to mention software update and a host of other things. Sure, the application can perform demux functions, but that creates a need for a centralized dispatcher: a function that the browser is performing anyway.
2. We have a request to support what GCM calls a collapse key. A function whereby only the last messages with the same key is delivered if a device is absent. This is much easier with the proposed protocol if multiple registrations (there, channels) can be created (it's basically a noop).
3. This has better privacy and security properties. A collapse key provides a way for the push server to identify correlation between unrelated events, which is unavoidable if you have the feature. However, with a special collapse key in addition to the registration, the push server is able to correlate un-collapsed messages for the same origin. Separate channels might still be activated by the same application server, revealing a correlation through the source IP of the push request, but that certainly isn't always the case. This also allows applications to more finely control disclosure of registration information.

The current text around permissions looks a little non-standard to me. Also, there is a limit to how much a spec should require around permission management and UX as it is normally a user-agent specific implementation detail.

Is there a way for a developer to detect what the current push service is for that device and use it show / hide push functionality based on what push services the back end supports?

For example, if my site supports push of GCM but not anything else, it would be ideal to hide the UI on other browsers / platforms which may support push but not GCM.

At the moment that only seems possible after the user has granted permission (unless I'm missing something).

We currently use a few variant terms for the same thing:

• Webapp server
• App server
• Application server

We should try to agree with the IETF Web Push Protocol WG on picking one and using only that one.

Currently PushRegistration, PushMessage, and PushRegisterMessage have an attribute named pushRegistrationId. This seems overly verbose to me. Suggestion: rename it to registrationId.

Currently Chrome only grants permissions for a combination of iframe + embedder.

Therefore if you ask say for geolocation from b.com as an iframe of a.com. The permission will only be granted for that combination and not when b.com is in an iframe of c.com or if you go directly to b.com as a top level domain.

In the context of push this will not work since a SW is only tight to its embedder.

I therefore propose that we only allow push permissions for top level domains. iframes will not be able to have the push permission granted.

Perhaps this is just a chrome specific thing and too much detail to have it added to the spec but at least this is probably how Chrome is going to have to ship this API.

I think the current sequence diagram in section 5 can be improved. Any ideas? I have a sample but not sure how to attach images to issues.

The endpoint is currently defined as type DOMString, which is an absolute URL. Any objections to actually making it of type URL?

The IETF Web Push Protocol (http://datatracker.ietf.org/wg/webpush/) is developed in collaboration with the Webapps WG to complement the Push API. It is not clear to me that it should at this time be a requirement for the push service underlying the Push API to support this protocol.

My suggestion: at this time, given the early stage of the Web Push Protocol development, I think it should be referenced in a non-normative section of the Push API spec.

@beverloo @martinthomson

During initial service worker registration it won't be active right away. It might fail to activate. One problem with this is that push events cannot be delivered to such a worker yet. To avoid potential message loss here, Push registration should reject if there is no active service worker yet.

Note that the Notification API has a similar requirement: https://notifications.spec.whatwg.org/#service-worker-api

@annevk @jakearchibald @beverloo - does this sound right?

Server requests client to refresh its registration, when it has detected the registration becomes invalid (e.g., server runs into specific error when trying to use the registration to perform certain actions), but not because the registration information has been lost.

Lost does not really reflect what happen, can we consider renaming pushregistrationlost to pushregistrationrefresh?

The WebIDL signature should become:
Promise<PushRegistration> unregister ();

This way, the page does not need to store the registration on the client. When it unregisters, it can take the registrationId from the PushRegistration and send it to the app server. The app server can then drop it from storage and stop sending messages to it.

@mounirlamouri

@mounirlamouri

Additional text for push client seems redundant.
Possible actions might be interpreted as the only available actions. Consider rephrasing.

As discussed here: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0438.html

I think it would be great to follow the pattern of ServiceWorker:

• unregister() should live in PushRegistration;
• unregister() should return a Promise that says whether the unregistration happened.

CC: @annevk and @jakearchibald

See w3c/ServiceWorker#489

@efullea @miguelgarciaarribas @martinthomson

How does the pushregistrationlost event use case work? The spec currently says to fire it Upon any event that makes a push registration no longer valid, e.g. push server database failure. Presumably the client would then reregister to recover from this failure.

If the push server suffers a database failure and loses registration data, how can it notify the (previously) registered client?

Do we have any use cases that make more sense? Or can we just drop the pushregistrationlost event from the spec?

The terminology for Promise currently mentions it should follow the definition available at:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects

Since Promises are used in normative parts of the specification, we should link to a published ES6 draft rather than a somewhat random page.

As suggested by Arthur Barstow, copy Bug #27108 from Bugzilla.

Shijun Sun 2014-10-20 15:52:24 UTC
Open a bug to track the topic on the mailing list.
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0179.html

When the "push client" can handle generic actions (such as posting a toast notifications) waking up the browser (or a subset of it) and let service workers to display each notification might not be the best practice from performance perspective, especially when the user does not want to pick up each incoming video call or read each incoming emails right away. The Push API spec should allow the web developers to have flexibility to leverage the generic actions, or rely on a service worker, or maybe do both.

I expect the generic message types should be scoped to a very small set. Toast notification with a text message and an optional image should be a good starting point. This will also lead to extensions to existing API. For example, we should allow a webapp to construct a PushRegistrationManager based on a valid registrationId it got previously. We should think through the details in the WG.

BTW, Martin Thomson mentioned another scenario [1] in the mailing list that can also benefit without having the service worker dependency.

[1] http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0140.html

Comment 1 Anne 2014-10-20 15:58:34 UTC
What's the problem with requiring a service worker?

Comment 2 Arthur Barstow 2014-10-20 16:05:48 UTC
[ Bryan, Eduardo, Michael - rather than track Push API bugs via Bugzilla and Github Issues, perhaps you should converge on one (probably Github). ]

Comment 3 Chris Wilson 2014-10-20 16:06:47 UTC
Even more directly - what's the Push "client", if not code inside the SW? How do you "handle" actions without somewhere to hang that code?

Comment 4 Shijun Sun 2014-10-20 16:15:24 UTC
(In reply to Chris Wilson from comment 3)

Even more directly - what's the Push "client", if not code inside the SW?
How do you "handle" actions without somewhere to hang that code?

Based on Fig. 1 of the spec, the client is implemented in the UA or the system it runs on.

There's no need to define and refer to "push service extension" though it seems fine to state that the user agent may allow the user to select which transport of push service is used.

After doing the threat analysis on the protocol pieces of this, the only major concern was the availability of push messages to the push server itself. Much of the rest of the system can be protected with HTTPS, but if we don't trust the push server, then there isn't anything we can do.

Applications are trivially able to provide confidentiality and integrity for push messages - they are talking to themselves, after all - but the path of least resistance is to send messages in the clear. We can do better than that.

The idea here is to include a WebCrypto key with each push registration created by the application. The browser will reject messages that aren't JSON Web Encryption objects that are encrypted and authenticated with the provided key.

Currently there's both data and pushRegistrationId on a push event. I see no real use case for the id. Is this a leftover from when the api supported multiple registrations / channels? Let's remove it.

If the author really wants to have the id it can be read from getRegistration and we can always add it back if we find a strong use case.

See w3c/ServiceWorker#501

See this discussion:
http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0077.html

I'm not sure we really need to define this at all. Is there already a reusable term for this?

Change references to webapp => service worker where it might be unclear that only Service Workers should use interfaces & get events etc. Other than register (because of the need for permissions UI), all interfaces and events to SW only

Issue originally posted by @johnmellor at
telefonicaid/WebAPISpecs#30

See issue and discussion there, but please post new comments here.

The current API defines push message as a DOMString. However, the proposed protocol exposes some meta-information that might be useful.

For instance, a pushed message could include an indication from the push server about the time that it received the message, which could be earlier than the time that it was delivered.

A generic metadata channel, such as HTTP header fields, might be the most capable interface in this regard. A subset of https://fetch.spec.whatwg.org/#responses might be appropriate.

Issue originally posted by @beverloo at
telefonicaid/WebAPISpecs#28

The Push API specification is a large mixture of spaces, tabs, different forms of indentation (4 spaces in WebIDL, 1 space in example code), has carriage returns, and so on.

While I by no means intend to kick off another tabs vs. spaces discussion, it would be nice if we could agree on what (I believe) to be the frequent preference for specifications: spaces for indentation, no tabs, use new-lines for line breaks, no carriage returns. WebIDL to be indented 4 spaces, example code to be indented 2 spaces.

As discussed on the mailing list [1], it'd be very helpful if PushRegistration can have a read-only attribute for ExpirationTime. Webapps can be more proactive if the ExpirationTime is set.

partial interface PushRegistration {
readonly attribute Date? expirationTime;
};

[1] http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0227.html

Push messages are severely space constrained (for good reason). This is worse if we adopt mandatory encryption (and we should).

This creates an incentive to find ways of packing data as densely as possible. That means binary payloads are quite desirable. Do we want to enable binary data delivery?

Obviously this creates some complexity for applications. Strings are still the most accessible form for messages. I see several options:

1. binary data only
2. deliver both, with a string value only populated if it can be decoded successfully
3. deliver either and deliver a signal in the protocol, just like in thewebsocketprotocol or WebRTC

My initial leaning is toward 2. I despise 3, though recognize that it may be necessary.

That link now just redirects to the current editor's draft so it doesn't add anything.

Currently, a registration looks like this:

interface PushRegistration {
    readonly    attribute DOMString endpoint;
    readonly    attribute DOMString registrationId;
};

Which is two values, which are used in two ways:

1. both together, they are used to send a message
2. registrationId is used to identify a registration in the API

Requiring two identifiers is a burden on the application when it comes to sending messages. The proposed web push protocol needs a single URI only. The push server can embed any information it needs in the URI.

Using the same identification that the push server uses in the API is also unnecessary. Other APIs, if they have some sort of identification, use identifiers that are minted by the browser. Given that we (currently) have only a single URI per origin, we don't need to perform this identification at all.

I'd like to propose the removal of registrationId.

Currently, the Push API just says to fire "a simple event named push" on the ServiceWorkerGlobalScope. And the Service Workers spec says the "user agent may terminate service workers at any time it has no event to handle."

But upon receiving a push event, web apps will often want to do asynchronous fetches etc, and the SW needs to remain alive until they complete. Service Workers use the event.waitUntil mechanism for similar purposes, but that's currently defined as: "when called in oninstall or onactivate, extends the lifetime of the event". Indeed, the install and activate algorithms explicitly include steps like "If event's extend lifetime flag is set, then: Wait until event's extend lifetime flag is unset. (...)".

We should update the wording of the SW spec, and add appropriate handling of extends lifetime to the push event and pushregistrationlost event algorithms to enable use of event.waitUntil.

However, we should probably also add text clarifying that the UA may (and is encouraged to) kill the Service Worker anyway if it executes for too long while handling a push event (unless the SW spec adds some generic text permitting that for all events).

See https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#extendable-event

If we have a case where a webapp wants to register for the push-api as spec'd here, and then display the notifications to the user using a HTML5 Notification style box, would the webapp have to request two separate permissions or is that "included" in the push-api permission request?

This seems like a fairly normal case, that would be nice not to bombard the user with multiple permission dialogs.

PushRegisterMessage => PushError with 'reason' attribute (enumeration). Now it covers at least 2 type of errors:
1- new registration is needed (e.g. due to fatal error at server),
2- "out of sync" , informational and does not imply registration has ended

Currently PushRegistration has an attribute named pushEndpoint. This seems overly verbose to me. Suggestion: rename it endpoint.

If we expose serviceWorkerRegistration.pushRegistrationManager.register then it's possible to call it before the worker is activated. However, no push related events can be delivered before the worker is activated: not for receiving push messages, not for indicating the push registration was lost, etc. The event for push registration lost could never be fired if a worker is unregistered before it is activated. In that case, the app server would be holding on to expired push registration details.

So should push registration always fail before worker activation, to prevent this event delivery problem from occurring?

@jakearchibald @beverloo

The spec currently says to fire a push event which has a PushMessage. This means that reading data from it looks like this:

var data = event.pushmessage.data;

It seems cleaner to just define PushEvent like this:

[Constructor(DOMString type, optional PushEventInit eventInitDict), Exposed=ServiceWorker]
interface PushEvent : Event {
  readonly attribute DOMString? data;
};

dictionary PushEventInit : EventInit {
  DOMString? data;
};

So the resulting javascript looks like this:

var data = event.data;