Why does chromium force a gcm_sender_id onto developers?

[Stefan Buhrmester]

Hi guys,

when using ServiceWorkers, I'm not able to "freely" use the pushManager API without also providing an `applicationServerKey` in the call to pushManager.subscribe or specifying a `gcm_sender_id` in the web application manifest file.

Chromium just refuses with the error message:

Uncaught (in promise) DOMException: Registration failed - missing applicationServerKey, and gcm_sender_id not found in manifest

Those seem to be Google-only requirements and it's blocking open development. Those requirements are completely arbitrary. Could the Chromium team please look into removing this? How to go about this?

Thanks,
Stefan

[Peter Beverloo]

Hi Stefan,

We indeed require a form of identification in order for a website to use push messaging. This is because the push service used by Chrome (Firebase Cloud Messaging) requires the subscription restriction portion of webpush-vapid, in order to not solely rely on endpoint secrecy for subscriptions.

https://webpush-wg.github.io/webpush-vapid/draft-ietf-webpush-vapid.html#rfc.section.4

If you're worried about any privacy implications of this, one option you have is to create a new P-256 key pair for each subscription and use that as the applicationServerKey when subscribing on the client.

Thanks,

Peter

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[Stefan Buhrmester]

Hi Peter,

thanks for the reply.

Why would it be bad to rely on endpoint secrecy for subscriptions? All the serviceworker APIs *already* require HTTPS and valid certificates which implies that the endpoint can be trusted. I can't think of an "attack-vector" (?) or a "bad thing" that making gcm_sender_id or applicationServerKey required would mitigate. Can you help me out?

I understand that the use of PKI for this API would make total sense if it hadn't https as a requirement.

Best,

Stefan

[Peter Beverloo]

On Wed, Jul 5, 2017 at 2:50 PM, Stefan Buhrmester <buh...@gmail.com> wrote:

Hi Peter,

thanks for the reply.

Why would it be bad to rely on endpoint secrecy for subscriptions? All the serviceworker APIs *already* require HTTPS and valid certificates which implies that the endpoint can be trusted. I can't think of an "attack-vector" (?) or a "bad thing" that making gcm_sender_id or applicationServerKey required would mitigate. Can you help me out?

There's quite a few reasons actually. It's certainly possible to make requests to non-HTTPS origins from a Service Worker and/or page, e.g. by requesting an image or by storing the value in a query string. Your HTTPS site might include scripts from some CDN that could be compromised. You'd also irrevocably lose control over all your subscriptions in case your database gets compromised.

Thanks,

Peter

[Stefan Buhrmester]

Hello Peter,

well... the fear of "losing control over something when it has been compromised" can never be mitigated... What if the google or mozilla push servers get compromised?

Do the current ServiceWorker implementations not have an API that allows the application developer to tell the user agent which push server to use, so we can run our own push servers?

Best,

Stefan

[Peter Beverloo]

On Wed, Jul 5, 2017 at 3:17 PM, Stefan Buhrmester <buh...@gmail.com> wrote:

Hello Peter,

well... the fear of "losing control over something when it has been compromised" can never be mitigated... What if the google or mozilla push servers get compromised?

Certainly, but that shouldn't stop anyone from finding mitigations for other parts of the system. In the Web Push model the push services are deliberately treated as untrusted, which is why we mandate encryption, among other things.

Do the current ServiceWorker implementations not have an API that allows the application developer to tell the user agent which push server to use, so we can run our own push servers?

No. You might find this discussion on the specification's GitHub repository relevant.

Thanks,

Peter

[Stefan Buhrmester]

Hi Peter,

thanks for the link to the discussion.

I understand your considerations for wanting to bundle push messages from different applications to save battery on user devices. But I think we should be allowed to implement our own push servers. Web Push Server operators gain a lot of leverage and nothing is keeping them from suddenly charge or disable service if they don't like someone's face.

It would be nice if the w3c could work towards allowing this.

Best,

Stefan

[Peter Beverloo]

Hi Stefan,

You're most welcome to file a specification issue -- at this point your concern no longer is Chromium specific, so that'd be a more appropriate forum indeed.

Thanks,

Peter