- From: <bugzilla@jessica.w3.org>
- Date: Fri, 08 Mar 2013 21:46:22 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21203 --- Comment #10 from Mark Watson <watsonm@netflix.com> --- (In reply to comment #9) > > Add a non-normative section under introduction saying that EME exposes > > information from the embedded media data to the embedding origin, so in > > order for the API to fire keymessage and keyneeded events, media data needs > > to be same-origin with the embedding page or use the crossorigin attribute > > on the media element and CORS headers on the media data response to > > authorize cross-origin information exposure. > > I want to make sure I understand which origins you are concerned about. > There are at least three domains (possibly more) that we are talking about > here. > > * The application domain > * The media data domain > * The key server domain(s) > > Are you looking for CORS compliance across all these domains? > > If so -- this runs into a problem I have brought up previously, namely that > the application may not know ahead of time what key server domain(s) will be > contacted. Can we exclude the key server domain(s) from this discussion? Communication with the key server (or indeed any other server) is not in scope of our specification. It's something the script may do according to the usual rules for scripts contacting servers. If you use XmlHttpRequest then the rules for that are documented in the XmlHttpRequest specification (and indeed do follow the same-origin policy, CORS etc.) Note that CORS does not require the origin of a script to know in advance which origins it will need to contact but rather requires those origins to authorize others to contact them (which they could do by advanced knowledge or through some kind of real-time authorization). -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 8 March 2013 21:46:27 UTC