On Wed, May 6, 2015 at 12:23 AM, Shih-Chiang Chien <sch...@mozilla.com
> Just like Sean says, we can use Presentation API to open a window on remote
> device, so it's very similar to do postMessage() to a cross-origin document
> on another process.
> For the usability of Presentation API, we would like to allow web developer
> to create a receiver app (e.g. video player) that allows other websites to
> use it. We can imagine that this receiver app to use send/onmessage to
> implement the remote media control UI.
> If we simply follow the same-origin policy for postMessage, this means
> receiver app will not be able to communicate with the remote page which is
> not in the same origin.
> I'll suggest that we add one more |targetOrigin| parameter to
> session.send(), which similar to window.postMessage() .
> session.send(message, origin); // "*" can represent no origin check
> Therefore, UA can allow cross-origin communication but also prevent message
> to be delivered to unexpected endpoint.
>  https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
Yeah, I think this looks good.
As I understand it there are two separate concerns here.
1. Should we allow opening a cross-origin URL using the Presentation API?
I think this is similar enough to simply navigating to a cross-origin
URL, or opening a cross-origin URL in an <iframe>, that I think this
is totally fine.
It's possible that we should enable websites to opt out of being
displayed on a TV through a CSP directive, but I think we can worry
about that later.
2. Do we need a way to ensure that messages can be safely sent to a
As I understand it, the concern here is that website a.com
on a TV, and then uses session.send(message) to send it
some sensitive information.
However website b.com
might have navigated to website c.com
I think adding a second 'origin' argument to session.send() makes
sense, like in your proposal.
However we should think about how we should handle page navigations in
general. If page A opens page B on the TV, but page B does a
navigation to page C which A did not expect then it seems like things
could very easily break.
First off it seems like messages that A intended to go to B now might
end up going to C.
Second, messages that B meant to not receive but that should instead
be handled by C might end up going to B depending on how quickly C
The latter problem could be helped by enabling B to signal when it is
and when it isn't ready to receive messages, and then have browser
queue messages when the current page isn't ready to accept them.