This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The current spec text suggest that "user agents MAY choose to only support the EME APIs and/or specific Key Systems (i.e. based on privacy and security risks) on secure origins". This formulation has the downside of imposing the cost of TLS on MSE while failing to foil a MITM from injecting EME usage into http origins. Specifically, with this formulation, a MITM gets to inject iframes that load an https page from a legitimately MITM-controlled domain into http pages. Furthermore, since the MITM also gets to transfer data between the http page (into which the MITM inject additional JavaScript) and the MITM-controlled https site, the MITM can associate whatever distinctive identifiers exposed to the MITM-controlled https site with the page that the iframe has been injected into. To address this problem, please require all the ancestor origins to be secure origins when the EME API is being limited to secure origins. (Start proposed spec text for a *normative* section) When the User Agent is limiting the support of the APIs described in this document or a specific Key System to secure origins, the secure origin requirement MUST apply not only to the origin calling the APIs described in this document but also to all the ancestor origins in the browsing context chain up to and including the top-level browsing context. Note: This ensures that a network attacker cannot work around the secure origin restriction by injecting an iframe with a attacker-hosted https-origin document into an http-origin victim page. Also, this makes it harder for a site to foil the intended privacy properties of the secure origin restriction by exposing EME messages to an insecure origin by using postMessage() to send data to an insecure-origin parent browsing context.
I oppose adoption of this proposal due since it would dictate policy for the use of EME, which IMO is the prerogative of users of EME, and not the EME specification. In other words, I believe EME should restrict itself to defining mechanism, and not policy. If it is desirable to define a normative policy or set of policies that can be optionally adopted for standardized uses by some EME user, then such policy(ies) may be defined in a separate document and adopted (or not) by EME users as they see fit.
(In reply to Henri Sivonen from comment #0) > (Start proposed spec text for a *normative* section) > > When the User Agent is limiting the support of the APIs described in this > document or a specific Key System to secure origins, the secure origin > requirement MUST apply not only to the origin calling the APIs described in > this document but also to all the ancestor origins in the browsing context > chain up to and including the top-level browsing context. Would it be possible / should we incorporate the language from https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use-powerful-features , which makes it clearer as to the algorithm necessary to process this? > > Note: This ensures that a network attacker cannot work around the secure > origin restriction by injecting an iframe with a attacker-hosted > https-origin document into an http-origin victim page. Also, this makes it > harder for a site to foil the intended privacy properties of the secure > origin restriction by exposing EME messages to an insecure origin by using > postMessage() to send data to an insecure-origin parent browsing context.
(In reply to Glenn Adams from comment #1) > I oppose adoption of this proposal due since it would dictate policy for the > use of EME, which IMO is the prerogative of users of EME, and not the EME > specification. The language Henri proposes is clearly conditional ("When you want to do X, you must do Y."), and justified ("Note: If you don't do Y, doing X doesn't really do X."). What are we doing when specifying a thing if not noting the guidelines, expectations, and consequences for its use?
(In reply to Mike West from comment #3) > (In reply to Glenn Adams from comment #1) > > I oppose adoption of this proposal due since it would dictate policy for the > > use of EME, which IMO is the prerogative of users of EME, and not the EME > > specification. > > The language Henri proposes is clearly conditional ("When you want to do X, > you must do Y."), and justified ("Note: If you don't do Y, doing X doesn't > really do X."). What are we doing when specifying a thing if not noting the > guidelines, expectations, and consequences for its use? In that case, I withdraw my opposition.
(In reply to Ryan Sleevi from comment #2) > (In reply to Henri Sivonen from comment #0) > > (Start proposed spec text for a *normative* section) This is helpful text, but we need to figure out how to integrate it. The proposed normative addresses a hole in a non-normative section. (The second proposed paragraph is a Note and thus non-normative anyway.) We seem to be heading towards moving more privacy and security considerations to normative text, so this issue may eventually go away. I hope we can normatively address these concerns in the algorithms (currently blocked by bug 26332). If that change is sufficient, non-normative text describing these requirements or a Note below the step explaining the behavior may be sufficient. For now, maybe we should integrate Henri's proposed text and add an Issue box to make the section normative. Maybe we need an umbrella bug for making (more of) the considerations sections normative. > > > > When the User Agent is limiting the support of the APIs described in this > > document or a specific Key System to secure origins, the secure origin > > requirement MUST apply not only to the origin calling the APIs described in > > this document but also to all the ancestor origins in the browsing context > > chain up to and including the top-level browsing context. > > Would it be possible / should we incorporate the language from > https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use- > powerful-features , which makes it clearer as to the algorithm necessary to > process this? Yes, we should reference a central definition of expected behavior. Does this algorithm cover the scenarios about which Henri is concerned? Note that the normative algorithm step that addresses origins currently references http://www.w3.org/TR/mixed-content/#authenticated-origin, which has since been removed from the Mixed Content Editor's Draft. I will update that step to use a newer reference. > > > > > Note: This ensures that a network attacker cannot work around the secure > > origin restriction by injecting an iframe with a attacker-hosted > > https-origin document into an http-origin victim page. Also, this makes it > > harder for a site to foil the intended privacy properties of the secure > > origin restriction by exposing EME messages to an insecure origin by using > > postMessage() to send data to an insecure-origin parent browsing context.
(In reply to David Dorwin from comment #5) > (In reply to Ryan Sleevi from comment #2) > > Would it be possible / should we incorporate the language from > > https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use- > > powerful-features , which makes it clearer as to the algorithm necessary to > > process this? > > Yes, we should reference a central definition of expected behavior. Does > this algorithm cover the scenarios about which Henri is concerned? While I can't speak for Henri, from what I read of what he said, this absolutely matches his proposal in a central fashion (with the added bit that the different sections address different concepts w/r/t browser context vs document, but the same behaviours across)
(In reply to Ryan Sleevi from comment #2) > Would it be possible / should we incorporate the language from > https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use- > powerful-features , which makes it clearer as to the algorithm necessary to > process this? I think it makes sense to reference that algorithm. It tries to do what I want. I'm not 100% sure it currently does what I want, but if it doesn't, it seems clear I should file a bug on that spec instead instead of proposing a different algorithm here. (Specifically, it's unclear to me what step 3 does if the branch in step 2 is not taken.)
(In reply to Henri Sivonen from comment #7) > I think it makes sense to reference that algorithm. It tries to do what I > want. I'm not 100% sure it currently does what I want, but if it doesn't, it > seems clear I should file a bug on that spec instead instead of proposing a > different algorithm here. (Specifically, it's unclear to me what step 3 does > if the branch in step 2 is not taken.) Ah, yes. That was silly. The new step 2 now sets `origin` even if the document isn't sandboxed: <https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use-powerful-features>. Sorry about that! More bug reports welcome; that spec is going into last call on Thursday, so right now is a _brilliant_ time to skim it and tell me how broken it is. :)
(In reply to Mike West from comment #8) > (In reply to Henri Sivonen from comment #7) > > I think it makes sense to reference that algorithm. It tries to do what I > > want. I'm not 100% sure it currently does what I want, but if it doesn't, it > > seems clear I should file a bug on that spec instead instead of proposing a > > different algorithm here. (Specifically, it's unclear to me what step 3 does > > if the branch in step 2 is not taken.) > > Ah, yes. That was silly. > > The new step 2 now sets `origin` even if the document isn't sandboxed: > <https://w3c.github.io/webappsec/specs/mixedcontent/#may-document-use- > powerful-features>. Sorry about that! > > More bug reports welcome; that spec is going into last call on Thursday, so > right now is a _brilliant_ time to skim it and tell me how broken it is. :) Hmm. Actually, my comment 7 might have been wrong regarding whether the algorithm is trying to do what I want. It loops up the browsing context chain only for srcdoc. I meant to loop up the chain for all docs and fail if anything in the chain is untrusted.
(In reply to Henri Sivonen from comment #9) > Hmm. Actually, my comment 7 might have been wrong regarding whether the > algorithm is trying to do what I want. It loops up the browsing context > chain only for srcdoc. I meant to loop up the chain for all docs and fail if > anything in the chain is untrusted. Best to file a new bug for that. I think I agree that that's what we should put in the spec, but it doesn't match Chrome's current behavior. I believe that's probably a reason to change Chrome, but we'll have to think about the impact (e.g. Netflix would break today).
(In reply to Mike West from comment #10) > (In reply to Henri Sivonen from comment #9) > > Hmm. Actually, my comment 7 might have been wrong regarding whether the > > algorithm is trying to do what I want. It loops up the browsing context > > chain only for srcdoc. I meant to loop up the chain for all docs and fail if > > anything in the chain is untrusted. > > Best to file a new bug for that. Bug 27302. > I think I agree that that's what we should > put in the spec, but it doesn't match Chrome's current behavior. I believe > that's probably a reason to change Chrome, but we'll have to think about the > impact (e.g. Netflix would break today). I take it that you are referring to Web Crypto. As noted in bug 27302, the reason for restricting Web Crypto and the reason for restricting most other APIs that need restricting is different, so it's not unreasonable to apply different levels of restriction.
I believe this issue is resolved by the fix for https://github.com/w3c/encrypted-media/issues/49, which references https://w3c.github.io/webappsec/specs/powerfulfeatures/#settings-secure via https://w3c.github.io/webappsec/specs/powerfulfeatures/#secure-context. Mike West: Please confirm that text addresses this. Henri: Do you agree? Anne: Do you have concerns? Does this really depend on 27190?
Yes. The "secure contexts" spec intends to check ancestors. bz has some issues with the current way we're doing that (see https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0012.html, for instance), but I think we'll work those out.
David, seems alright, provided user agents will actually ship this. As for the dependency, it's not a direct dependency, so I'll remove it.
Closing as fixed based on the last three comments.