A javascript api for sending push notifications to others

[jimmywarting]

When you subscribe for push you receive a endpoint and keys for generating push and payloads.
You can forge a payload fully in the browser but not all endpoints don't respond with CORS headers.
(Got a 401 when i was sending a OPTION preflight to google)

That creates a problem: A browser is not able to send a push notification to another person

If two persons have exchanged subscription shouldn't they be able to ping eachother to initiate a conversation without having to go throught a backend signaling server?

I'm building a PWA and i want to host it on a static site like Github-Pages and do as little to no server stuff as possible. And a push subscription exchange only has to happen once - then you can store the subscription in localstorage or something and reconnect a friend later again and again without having to rely on a server.

function gotFriendsSubscription (friendsSubscription) {
  localStorage.myFriend = JSON.stringify(friendsSubscription)
})

async function initiateConversation (friendsSubscription) {
  const { pushManager } = serviceWorkerRegistration
  const pushSubscription = await pushManager.getSubscription()

  const sdp = await (
    // - create RTCPeerConnection
    // - create DataChannel
    // - wait for all iceCandidate to complete
    // - generate offer
    // - disable trickle
  )
  
  const payload = JSON.stringify({
    msg: "Hi lets start chatting",
    sdpOffer: sdp,
    // share my subscription so he can respond back with a sdpAnswer
    subscription: pushSubscription 
  })

  // My proposal:
  pushManager.send(friendsSubscription, payload)
  // maybe send some TTL ( time to live ) option
  // and maybe vapid is necessary also? don't know what should be required
  // its more about the concept then my api proposal
}

// sometime later
initiateConversation(JSON.parse(localStorage.myFriend))

with something like pushManager.send(subscription, payload) you can send message to a friends without involving a server - the browser will happily send that push message without worry about any CORS problem.

This could help to establish a WebRTC connection with disabled trickle option - gathering all IceCandidates and transfering them with just one single web push

[martinthomson]

Is the request for the specification to mandate the use of appropriate CORS headers so that push services could accept requests from arbitrary JS origins? If so, how does that interact with the expected VAPID keys?

[jimmywarting]

My request is for browser to be able to make a push request on my behalf given that i supply all the necessary parameters for generating a payload and sending it to a receiver.

But "mandate the use of appropriate CORS" could work too, it's just means more complicated work on my end to generate sign and what not, I don't remember what VAPID dose for you. was a long time ago since i did some development with WebPush and have forgotten all about it and how it works so i can't comment on VAPID. it was also with the older "aesgcm" encoding

All i want is for it to be possible to send a WebPush to a Friend without a backend server

[martinthomson]

I think that this is a common enough request. I don't think that it is appropriate to have the browser generate the message, as that can be trivially provided by a JSL. Recommending that servers allow POST requests via CORS is reasonable. @beverloo, @jrconlin, does this make sense to you? Do you think we need some way for the UA to request that the push service disable this allowance?

[jrconlin]

I think it's fairly reasonable for Push Subscription Servers to allow POST requests for subscription updates.

A few things:

1. I've built a few javascript WebPush test pages (although they use the older "aesgcm" encoding). The problem I tend to hit on are more around importing and deriving public keys inside of DOM level javascript. It works on Firefox, not so much on Chrome, but that's probably just my misunderstanding of Blink internals.

2. VAPID is how you identify yourself when you're pushing a subscription message. With firefox, it's optional. With Google, it's less optional. You can also use VAPID to create "restricted subscriptions" that are only valid if the same key is used to sign the VAPID header is used to lock the subscription. It's the application server key element of the .subscribe() call.

3. Push servers get a lot of trash like messages for expired push endpoints, badly formed messages, etc. One of the other goals of VAPID was to provide a way for you to say, "Hey, if you need to contact me, here's how you can." This can give our Ops folks a way to let you know there's a problem and let us help you fix it. So if you use some contact info like "bob@example.com" they're just going to black-hole all your data.

Does that help?

[beverloo]

This sounds like a reasonable SHOULD requirement to me too. I believe that we enable CORS on our endpoints.

[jimmywarting]

So what you are proposing is "A request should always be possible to make regardless if CORS are enable or not"? - essentially disable CORS (preflight) requirement for the endpoint?

[beverloo]

No, the proposal is for the specification to state that push services should send the appropriate headers so that you can send messages from JavaScript.

You'll still need code (perhaps a library) on your website to exchange the subscription and keying material between clients, and to encrypt the message prior to sending it.

[jimmywarting]

Gotcha

[evan-brass]

Until GCM supports CORS, you can see if http://cors-anywhere.herokuapp.com/ fits your needs. (https://stackoverflow.com/questions/36691533/how-to-send-push-notifications-in-chromeprogressive-web-apps)

[alastaircoote]

Just bumping this, curious to know if there is any further consensus. I've recently discovered that I can successfully encrypt a Web Push payload via the Web Crypto API but can't send in Chrome because of CORS issues. A quick examination:

• Mozilla (updates.push.services.mozilla.com): 👍
• Chrome and Opera (fcm.googleapis.com): 👎
• Edge (wns2-by3p.notify.windows.com) 👎

It would be great to get more consistency here, IMO true P2P sending is an interesting possibility.

[collimarco]

@alastaircoote What about the VAPID keys? You can't send them to the client for security reasons... So in my opinion Web Push is not made for P2P but it always requires a server.

[jrconlin]

I'm going to push back a bit on the VAPID requirement, mostly because VAPID is (supposed to be) Voluntary. It's also quite possible to generate VAPID headers on-the-fly, since they're bound to a given subscription, and that subscription may be as ephemeral as a test page. Heck, the body content of a push message is also optional, which means you don't have to have encryption if the body is empty, and the recipient would just get push event.

It's absolutely true that you don't want to expose the full subscription info block (the endpoint + encryption credentials) to anyone, since those could be used to send messages as the subscription provider. VAPID provides a bit of extra protection there since the Key should be generated externally. Technically, that can still be true if the VAPID key is generated outside of the web app, and the user trusts that the private key is never communicated outside of the app.

It's absolutely possible to generate the VAPID key in javascript using WebCrypto libraries.