New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interaction with SOP #211
Comments
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. |
We have the following text in the specification:
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. |
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.
The text was updated successfully, but these errors were encountered: