Original text:
this section provides more background on the existing Web security model. <del> In this model, then, the browser acts as a TRUSTED COMPUTING BASE </del>  (TCB) both from the user's perspective and to some extent from the server's.  While HTML and JavaScript (JS) provided by the server can cause the browser to execute a variety of actions, those scripts operate in a sandbox that isolates them both from the user's computer and from each other, as detailed below. <del> Conventionally, we refer to either WEB ATTACKERS, who are able to </del>  induce you to visit their sites but do not control the network, and <del> NETWORK ATTACKERS, who are able to control your network.  Network </del>  attackers correspond to the RFC3552 "Internet Threat Model".  Note <del> that for non-HTTPS traffic, a network attacker is also a Web attacker, since it can inject traffic as if it were any non-HTTPS Web site.  Thus, when analyzing HTTP connections, we must assume that traffic is going to the attacker. </del>  3.1. user must explicitly select the file and consent to its upload. [Note: in many cases browsers are explicitly designed to avoid dialogs with the semantics of "click here to bypass security checks", <del> as extensive research shows that users are prone to consent under such circumstances.] </del>  Similarly, while Flash programs (SWFs) SWF can access the camera and microphone, they explicitly require that the user consent to that Moreover, the identity of the party the browser is connecting to is all that the browser can meaningfully enforce; if you are calling A, A can simply forward the media to C.  Similarly, if you authorize A <del> to place a call to B, A can call C instead.  In either case, all the </del>  browser is able to do is verify and check authorization for whoever is controlling where the media goes.  The target of the media can of course advertise a security/privacy policy, but this is not something 4.1.3. <del> Now that we have seen another use case, we can start to reason about the security requirements. </del>  As discussed in sec.same-origin, the basic unit of Web sandboxing is the origin, and so it is natural to scope consent to origin. The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com <del> The attacker forges the response apparently from http://calling- </del>  service.example.com/ to inject JS to initiate a call to himself. Note that this attack does not depend on the media being insecure. site, that JavaScript is executed in the security context of the page finer-grained.  This could lead to compromise of a call even if the parent page is safe.  Note: this issue is not restricted to PAGES <del> which contain untrusted content.  If a page from a given origin ever loads JavaScript from an attacker, then it is possible for that </del>  attacker to infect the browser's notion of that origin semi- permanently. triggering a key continuity warning is to tell the browser that "this is a call to user Y" where Y is confusable with X.  Even if the user actually checks the other side's name (which all available evidence <del> indicates is unlikely), this would require (a) the browser has </del>  trusted UI to provide the name and (b) the user to not be fooled by similar appearing names. cannot interfere.  In order to facilitate that, it will be necessary to provide features whereby the site can verifiably give up access to the media streams.  This verification must be possible both from the <del> local side and the remote side.  I.e., I must be able to verify that the person I am calling has engaged a secure media mode (see </del>  sec.malicious).  In order to achieve this it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the

Reviewer comments:
(or attempts to at least).
NAME ready to merge
Need to work through Ben's . I'd like to have a brief discussion about a few points, though it's not clear that any change to the document will be required (details in the COMMENT section for all of these): Mutually-verifiable "secure mode" seems to require that the peer's browser be included in the TCB, which is a bit hard to swallow.  Are we comfortable wrapping that in alongside "we trust the peer to not be malicious"? It's not clear how much benefit we can get from *optional* third-party identity providers; won't the calling service have the ability to silently downgrade to their non-usage even if both calling peers support it? I mostly only have editorial comments, though there are a few that are more content-ful. The user can observe the javascript running the browser, though maybe this distinction is not necessary here. I note that the author of this document is listed as a coauthor on huang-w2sp; does the self-cite really add much authority to the summary of the guarantee? The use of ALL-CAPS to call out new terms feels a bit dated. nit: I know this is a web-centric document, but the privileging of https as the only "secure" traffic reads a bit oddly to me; something like "note that in some cases, a network attacker is also a web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer. TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker."  (A thought experiment might be to consider whether wss://traffic counts as "HTTPS traffic".) It might be appropriate to provide some example references in place of "extensive research". nit: the wording here is a bit odd, since in case (1) you're verifying you're talking to A, but you still control where the media goes (in terms of A or not-A; A can of course then forward on the media further). nit: "local" is perhaps overly restricting, depending on interpretation Maybe note that the "result" of the cross-site requests that is leaked is in the form of pixels and not structured data, but that does not change the information content. nit: I'm confused by "another" here. This seems to be relying on the reader to have some background knowledge and make some leaps of reasoning that may not be reasonable to expect. This is especially challenging because if the site (and/or its javascript) is in the path for binding a cryptographic identity to a real-world identity, then a malicious site can still get whatever keys it wants authorized. seem to be missing a word or two here. nit: "If any page" is more emphatic, I think. Do we want any discussion of the risks when metered bandwidth (pay per byte) is in use? There's probably some room to tighten up the verbiage here; e.g., "the site initiating ICE" is referring to a website that is using a browser API to request ICE against some remote peer (right?).  And "ICE keepalives are indications" is using Indication as the technical term for a message that doesn't get an ACK response, not in its common English usage. A one- or two-sentence summary of the impact of misinterpretation attacks is probably in order, instead of making us follow the reference (which isn't a section reference). nit: "employed" to obfuscate what, exactly? nit: "incorporated" into what? I think I'm a little confused about which legacy actors we're talking about.  Are we still considering the broader situation a webserver-mediated interaction between two browsers or brower-adjacent applications?  (E.g., a WebRTC client calling some other sort of video chat system?) nit: "threat is" Is "answered" supposed to be some interaction with the controlling site? Some rewording for clarity is probably in order; "ordinary operation" is of a website without WebRTC; "sites can cause the browser to provide IP addresses" is when the site uses the browser API to request ICE initiation; etc. [Obligatory note about "Forward Secrecy" vs. "Perfect Forward Secrecy"] To be clear, the authentication that the calling service provides is a binding between identity and the public keys that are input to the key exchange mechanism? nit: "browser to use trusted UI" It's not clear that third-party identity providers actually provide downgrade-resistance -- can't the site mediating the calls just decline to acknowledge that a third-party identity is/was available for the peer? This seems to require extending the TCB from just the local browser to the remote browser as well, which is ... a stretch. (Also, do we really need the first person?) The coordinates for [OpenID] don't seem quite right.

Revised text:
this section provides more background on the existing Web security model.  <ins> In this model, then, the browser acts as a Trusted Coomputing Base </ins> (TCB) both from the user's perspective and to some extent from the server's.  While HTML and JavaScript (JS) provided by the server can cause the browser to execute a variety of actions, those scripts operate in a sandbox that isolates them both from the user's computer and from each other, as detailed below.  <ins> Conventionally, we refer to either web attackers, who are able to </ins> induce you to visit their sites but do not control the network, and  <ins> network attackers, who are able to control your network.  Network </ins> attackers correspond to the RFC3552 "Internet Threat Model".  Note  <ins> that in some cases, a network attacker is also a web attacker, since transport protocols that do not provide integrity protection allow the network to inject traffic as if they were any communications peer.  TLS, and HTTPS in particular, prevent against these attacks, but when analyzing HTTP connections, we must assume that traffic is going to the attacker. </ins> 3.1. user must explicitly select the file and consent to its upload. [Note: in many cases browsers are explicitly designed to avoid dialogs with the semantics of "click here to bypass security checks",  <ins> as extensive research cranor-wolf shows that users are prone to consent under such circumstances.] </ins> Similarly, while Flash programs (SWFs) SWF can access the camera and microphone, they explicitly require that the user consent to that Moreover, the identity of the party the browser is connecting to is all that the browser can meaningfully enforce; if you are calling A, A can simply forward the media to C.  Similarly, if you authorize A  <ins> to place a call to B, A can call C instead.  In either cases, all the </ins> browser is able to do is verify and check authorization for whoever is controlling where the media goes.  The target of the media can of course advertise a security/privacy policy, but this is not something 4.1.3.  <ins> Now that we have described the calling scenarios, we can start to reason about the security requirements. </ins> As discussed in sec.same-origin, the basic unit of Web sandboxing is the origin, and so it is natural to scope consent to origin. The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com  <ins> The attacker forges the response from http://calling- </ins> service.example.com/ to inject JS to initiate a call to himself. Note that this attack does not depend on the media being insecure. site, that JavaScript is executed in the security context of the page finer-grained.  This could lead to compromise of a call even if the parent page is safe.  Note: this issue is not restricted to PAGES  <ins> which contain untrusted content.  If any page from a given origin ever loads JavaScript from an attacker, then it is possible for that </ins> attacker to infect the browser's notion of that origin semi- permanently. triggering a key continuity warning is to tell the browser that "this is a call to user Y" where Y is confusable with X.  Even if the user actually checks the other side's name (which all available evidence  <ins> indicates is unlikely), this would require (a) the browser to use the </ins> trusted UI to provide the name and (b) the user to not be fooled by similar appearing names. cannot interfere.  In order to facilitate that, it will be necessary to provide features whereby the site can verifiably give up access to the media streams.  This verification must be possible both from the  <ins> local side and the remote side.  I.e., users must be able to verify that the person called has engaged a secure media mode (see </ins> sec.malicious).  In order to achieve this it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the