Security review of Push API W3C Working Draft 23 June 2017

[magnus-git]

I am a member of the IETF Security Directorate and have been asked to review this document from a security perspective by Sam Weiler, as part of a W3C trial attempting to get broader security reviews of W3C specs before they are published as recommendations. These comments were written primarily for the benefit of said trial. Document editors and WG chairs should treat these comments just like any other comments.

Observations:

• The Security Considerations sections note that there's no way for the user agent to validate that a push message was sent by an application server having the same origin as the webapp since "the application server is able to share the details necessary to use a push subscription with a third party at its own discretion." Is this undesirable behavior? If so, I am a little puzzled by the statement since I thought the webapp's ECDH public key could be used for identification (e.g., if provided in the form of a certificate). I may miss some context here though.
• The text talks about no reuse of push endpoints for new push subscriptions etc., but seems to be silent on good practices for selecting good endpoints. For example, if a user agents selects them in a predictable manner, this would also seem to allow for situations of "cross-subscription" push messages? If that's the case, then maybe provide guidance on how push endpoints shall be generated?

Editorial:

• In the Security Considerations section, "necessary to to use" -> "necessary to use"

/M

[beverloo]

Hi Magnus, thank you for the review!

The Security Considerations sections note that there's no way for the user agent to validate that a push message was sent by an application server having the same origin as the webapp since "the application server is able to share the details necessary to use a push subscription with a third party at its own discretion." Is this undesirable behavior?

No, that's intended behaviour. Part of this is theoretical: there's no way for us to verify the originating origin or a push message if the application server decides to share their private key with other parties. Part of this is practical: there are valid use-cases for apps to do this, for instance a news feed aggregation client that receives updates from multiple agencies.

The text talks about no reuse of push endpoints for new push subscriptions etc., but seems to be silent on good practices for selecting good endpoints.

Good point! I've uploaded a PR to address this, and would appreciate feedback: https://github.com/w3c/push-api/pull/274

In the Security Considerations section, "necessary to to use" -> "necessary to use"

Also addressed in the PR.

[magnus-git]

Thanks Peter. On #274 , would it make sense to point to some existing resource providing guidance for how to generate such identifier? Perhaps just referring to the Privacy Considerations in RFC 8030 is sufficient, in addition to the text you suggested? One additional observation: Accepting a push subscription seems to enable the webapp / application server to remotely "wake up" the service worker and thus potentially incur network traffic and possible other resource usage for the user as a result. Perhaps the Security Considerations section should indicate the need to inform the user about possible consequences of entering into such an agreement?

[beverloo]

Thanks @magnus-git! I've updated #274 and uploaded #286 for your latest suggestion.

I don't think we can require the user agent to clearly inform the user about this. While I agree with this in principle, user studies that we've done showed that most users are not familiar with what background usage entails, which is why Chrome (and other browsers) use the Notification permission for the Push API. Obviously this will get coverage in privacy documentation, but that's a step beyond implementation.