A Short Case for peer-to-peer Web Push

Gustav Corpas
2 min readMar 23, 2023
Photo by Jamie Street on Unsplash


Web push is a technology that can be leveraged by web apps, i.e. applications that run purely on the web. Through the Web Push API developers can push notifications to a users device if they have consented.

OBSERVE: The following is a rant on Web Push technology. It is probably only relevant to a few people, but I had to get it out of my mind…

Short introduction to the problem

The effects of GDPR as well as ethical and economic costs of running centralized servers will ( and has already ) increased the demand for peer-to-peer decentralized applications.

Currently all major web push services are using a CORS policy that makes it impossible for the browser to create and send a web push notification. This is stifiling innovation in the peer-to-peer space.

This is a call for web push services to implement a different CORS policy.

It is already possible for a client to build and share all the necessary web push things entirely in the browser via the Web Crypto API.

The only purpose of this CORS policy is to disallow browsers to initiate the push message.

Sharing and key generation can already happen entirely in the browser.

If this issue is not solved we may in the future see an increase in third party services acting as CORS proxies, or services more explicitly accepting JWT tokens to pass along to the web push service provider.

This is bad practise using unnecessary actors in the exchange.

Security concerns:

I am not a professional, but consider the following.

The main security concern is that the service worker can be leveraged to display notifications containing malicious content; e.g. links to other fraudulent sites.

Assuming a dishonest website there are no security gains from disallowing the browser to initiate push notifications, as the server holds the private VAPID keys to sign JTW tokens today.

Assuming an honest website owner there may be an increased implementation risk, as vapid keys need to be passed securely to other users. However, this is already possible today. Only the actual request to the push service endpoint is disallowed in browsers.

Also consider that notifications are tied to the application, and users can always revoke notifications form certain apps.

Forcing developers into insecure solutions based on unnecessary proxies is IMO much more damaging than embracing this trend and supporting developers with standardized libraries and good documentation.



Gustav Corpas

I write about technology and society. Or anything that is interesting to me.