Endpoint to proxy to other push servers

[p1gp1g]

UnifiedPush uses web push to get a decentralized push infrastructure for mobile. This is perfectly fine to use a self-hosted push server (autopush being one of them) with most applications, but it may be different with some others:

1. some (web) apps may use the push server domain to fingerprint the user
2. other apps restrict which push server they allow. This is done by simplicity, developers want to avoid any kind of SSRF, and they don't necessarily know there could be some other push servers than the big ones. For example:
   • Matrix's sygnal gateway
   • Firefox sync account
   • ntfy
   • And many more proprietary apps (a few of them are listed in this issue)

As a solution, we can set a public service that works as a proxy for web push requests. The targeted endpoint would be encrypted, the proxy wouldn't have to store anything, and the requests' body length and content-encoding would be checked.

This solution would fix the first point: we can use the proxy with apps that we don't want to fingerprint us (mostly on web).
Regarding the second point, it depends. If the proxy is on a new domain that isn't already allowed, we need the different applications to change their code to allow this new service (and I didn't imagine there were that many apps doing that kind of allow-list).

Therefore if we had an endpoint on autopush to forward web push requests, autopush could be used for that purpose too. I don't think I'd need a lot of capacity, as nothing needs to be stored.

If that's OK, we could even benefit from Mozilla's hosted server already being in all application allow lists (for apps that have one): fixing the 2 issues in a row. In this case, I would be very happy to implement the feature. I don't expect it to be very complex.

And, if you think it is unlikely to be merged, do you think we could have a subdomain CNAMEd to a domain we own ? Most of the allow lists seems to use wildcards, it would fix the 2nd issue on many apps, but not all.

┆Issue is synchronized with this Jira Task

[p1gp1g]

I also see 2 other advantages:

• Firefox on Android team preferred to not merge UnifiedPush support unless they know if there is enough demand, but that isn't really measured, except some imprecise data here and there (number of push on a push servers, number of registration on app servers, etc). This would help knowing a bit more on the subject
• If we decide to support aes128gcm only, we can respond with 501 for push notifications following the old draft (aesgcm), this may send a signal to these applications to finally migrate to the nearly 10 yo standard :)