search

w3c / push-api

Push API
https://w3c.github.io/push-api/
Other
146 stars 40 forks source link

Interaction with SOP #211

Closed martinthomson closed 7 years ago

martinthomson commented 7 years ago

The data that the browser provides an application comes from a service. We sort of assume that the browser is at some point going to start enforcing origin isolation, but never really point out the place where that happens.

From Stephen Farrell's review of the protocol parts.

martinthomson commented 7 years ago

Critically, we might explain why the data we receive from a push service can be safely treated as same-origin and therefore provided to the origin that the message was sent to.

beverloo commented 7 years ago

We have the following text in the specification:

A push subscription is a message delivery context established between the user agent and the push service on behalf of a webapp. Each push subscription is associated with a service worker registration and a service worker registration has at most one push subscription.

It defines the association between a push subscription and a service worker registration. The registration has a scope url that is an absolute URL that includes the origin. The availability of this data on the client-side is therefore restricted to that origin.

Whether the data send over the push subscription strictly comes from an application server for that origin is an unknown. If foo.com shares their private key with bar.com so that the latter can send messages on their behalf, there's nothing we can do about it. However, we can reasonably assume that this happened at the discretion of foo.com.

Does this cover what you'd like to see explained in the spec? I'll propose something if so.