Sadly, for third parties, we have neither implemented yet.

Hey Yusuf, what's the latest on this one?

On initial investigation, this looked like already handled on lower levels (CCT uses the message port service that is the main arbiter of message ports and postMessage calls), so the low level pieces we are using should already respect these.

But I want to do a full confirmation before I close this bug.

Follow-up q: if a page is X-Frame-Options: SAMEORIGIN, do we allow postMessage iff the sender has DAL-verified as that origin?

Rick, can I get some help on this? it would be a good introduction for any future strict CSP work here. I don't want to bother you too much with this so please feel free to point me to the right source/contact etc.

1) If X-Frame-Options forbids postMessage, what would be the way to check that? I wonder if it would be disabled from message_port_service directly which handled vending message ports for all cases (including app->web)
2) Sam's question. I am not very sure what it completely means if X-Frame-Options in SAMEORIGIN and what that should entail. Any pointers about that would be greatly appreciated.

/cc mkwst who is the expert on this stuff.  Definitely send questions his way.

I don't really understand the question: `X-Frame-Options` governs the origins that can load a given page into an `<iframe>` or `<frame>` (as does the `frame-ancestors` CSP directive). It's not clear to me what relationship that has with CT. Can you clarify the scenario you're concerned about?

CT has added a way for the client Android app to have a postMessage channel with the tab they open. In the case where the page loaded has a X-Frame-Options set to not get any postMessage, we want the API to still honor this.

I feel like one of the causes of confusion here is that I am not really sure what that particular X-Frame-Options is. (Just that a site can declare it somehow and not get postMessages, I think? sbirch@ maybe you know more about this then I do?)

So the question is at what level this is being enforced. Basically we are creating two  MessagePorts from MessagePortService and sending one to the main frame. We are trying to understand if we have to do anything special here for the rule to be enforced.

`X-Frame-Options` governs the origins that can load a given page into an `<iframe>`. `X-Frame-Options: SAMEORIGIN`, for instance, prevents `evil.com` from framing `example.com` (but would allow `example.com` to frame `example.com`).

XFO does not affect `postMessage`, except insofar as it makes it marginally more difficult to get a window handle to which messages could be posted. For example, `https://evil.com/` could call `var w = window.open('https://example.com'); w.postMessage('whatever', 'https://example.com/');` without issue (assuming they could cause the user to click in order to bypass the popup blocker.

Thanks a lot mkwst@.

sbirch@ does this address your concerns? Since we are only allowing a channel with the main frame in the API, there should be no concerns around what other frames can be or what they can do with the API (Communication with any other frames is completely at the main frame's discretion. We don't provide any additional Android/custom tabs specific hooks)