1497430 - Implement `PushManager::supportedContentEncodings`

Status: RESOLVED FIXED

(Core :: DOM: Push Subscriptions, enhancement, P3)

Description

[Lina Butler (ex-Mozilla)]

http://w3c.github.io/push-api/#pushmanager-interface, https://github.com/w3c/push-api/pull/252

I think this was tricky when I first looked at it because `PushManager` is a JS-implemented WebIDL, and I ran into issues trying to expose a static array on the binding. But that was also a year and a half ago. :-)

We don't support `FrozenArray` yet, either; see bug 1236777. https://hg.mozilla.org/mozilla-central/rev/bc0196fd88e5 has a workaround we can use.

Comment 1

[Kagami Rosylight [:saschanaz] (they/them)]

Apparently the lack of this is blocking migration to aes128gcm. (See also https://bugzilla.mozilla.org/show_bug.cgi?id=1925631#c41)

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

Removing dependency on bug 1236777, we have an established workaround.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: Bug 1497430 - Implement PushManager.supportedContentEncodings r=#webidl

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cf836d486e02
Implement PushManager.supportedContentEncodings r=webidl,asuth

Comment 5

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/48847 for changes under testing/web-platform/tests

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: Bug 1497430 - Update meta

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ba5084eee7f1
Update meta CLOSED TREE

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/cf836d486e02

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 11

[amarc]

https://hg.mozilla.org/mozilla-central/rev/ba5084eee7f1

Comment 12

[Hamish Willee]

FF134 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/36922

My understanding is that

1. this is also shipped (not just implemented)
2. The preference dom.push.indicate_aesgcm_support.enabled isn't relevant to external developers
3. The underlying implementation is not as in the spec but this is invisible to developers - (i.e. not using FrozenArray but the values in the returned array are unmodifiable).
4. This work in web workers too?
5. What does the web application do with the information? (I don't understand the push API). It sounds like the push notifications come to a service worker encrypted with this algorithm using the key provided by the application in the subscription. IF that is correct, does the app have to do anything - i.e. does it have to decrypt the message or does that get done on its behalf somehow?

Is that all correct?

Comment 13

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Hamish Willee from comment #12)

FF134 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/36922

My understanding is that

1. this is also shipped (not just implemented)
2. The preference dom.push.indicate_aesgcm_support.enabled isn't relevant to external developers
3. The underlying implementation is not as in the spec but this is invisible to developers - (i.e. not using FrozenArray but the values in the returned array are unmodifiable).
4. This work in web workers too?

All yes.

5. What does the web application do with the information? (I don't understand the push API). It sounds like the push notifications come to a service worker encrypted with this algorithm using the key provided by the application in the subscription. IF that is correct, does the app have to do anything - i.e. does it have to decrypt the message or does that get done on its behalf somehow?

Is that all correct?

The app sends the info to the app server - and then the server decides which content encoding to encrypt push payload. Decryption happens in the browser side, not app side.

Comment 14

[Hamish Willee]

Thank you

What does the web application do with the information? (I don't understand the push API).

The app sends the info to the app server - and then the server decides which content encoding to encrypt push payload.

1. How?

TLDR: I "think" the answer is that it is up to the app to define its own protocol for sharing the encoding supported by the browser - the mechanism doesn't appear to be in the spec, it isn't in the subscription object (which you are supposed to send to the app server), so I don't see any other way the app server can get it.

The app server adds the info to each push request in each request to the push server as the Content-Encoding.

My guess is that the information is often hard coded, and not sent at all.

2. Decryption happens in the browser side, not app side.

So the app doesn't need this information except to send it ("somehow") to the application server. Right?

---

This is FYI only - my thinking that fed the TLDR above.

• I can see from Message Encryption for Web Push that the app server specifies the Content-Encoding: aes128gcm to use in push messages it wants sent to the app.
• But how does the application server get that information? The diagram in the intro shows that the UA sends the subscription to the application (and this is also mentioned in https://web.dev/articles/push-notifications-subscribing-a-user#send_a_subscription_to_your_server), but the PushSubscription does not appear to contain the algorithm used? So how can the application server find it?
• This isn't covered in https://github.com/w3c/push-api/issues/251 which added the method - it just says this method makes the information broadly available, not how the data gets back to the app server.

Comment 15

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Hamish Willee from comment #14)

Thank you

What does the web application do with the information? (I don't understand the push API).

The app sends the info to the app server - and then the server decides which content encoding to encrypt push payload.

1. How?

Via whatever way depending on the app server implementation. The only standard part here is that the server gets the content encoding support info, use the proper library to encrypt based on the support data (that follows RFC 8291), and then send it to the push endpoint URL (which is PushSubscription.endpoint, also being sent to the app server by whatever app server dependent way)

Think of something like:

// given `subscription` being PushSubscription:
fetch(`https://example.com/push/`, {
  method: "post",
  body: JSON.stringify({
    endpoint: subscription.endpoint,
    p256dh: subscription.getKey("p256dh"),
    auth: subscription.getKey("auth"),
    encoding: PushManager.supportedContentEncodings,
    /* ... some user data so that the server would know which user this is for */
  });
});

And then example.com will encrypt its push notification payload with the provided keys and support data and send it to the endpoint (and of course not immediately but when there's a need to push a notification to clients)

2. Decryption happens in the browser side, not app side.

So the app doesn't need this information except to send it ("somehow") to the application server. Right?

Yes.

Comment 16

[Hamish Willee]

Thank you! Really helpful - none of that was captured in our docs and now is.