Original text:
2. <del> This section uses the concept of ICE agent as define in RFC8445.  In the remainder of the document, it is assumed that each browser execution context has its own ICE agent. </del>  2.1. 3.3. As noted in IPHandling, privacy may be breached if a web application <del> running in two browser contexts can determine whether it is running </del>  on the same device.  While the approach in this document prevents the application from directly comparing local private IP addresses, a successful local WebRTC connection can also present a threat to user are running on the same device. To avoid this issue, browsers SHOULD NOT register mDNS names for <del> WebRTC applications running in a third-party browser execution context (i.e., a context that has a different origin than the top- level execution context), or a private browser execution context. </del>  4. the addition of remote ICE host candidates with mDNS names generates mDNS queries for names of each candidate; <del> the removal of names could happen when the execution context of the ICE agent is destroyed in an implementation, and goodbye responses should be sent to invalidate records generated by the ICE agent in the local network (RFC6762, Section 10.1). </del>  A malicious Web application could flood the local network with mDNS messages by: <del> creating execution contexts that create ICE agents and start </del>  gathering of local ICE host candidates; destroying these local candidates soon after the name registration

Reviewer comments:
PR of
Anyone else want to take a look?
(browser) execution context -> browsing context
It was suggested to replace the name by "browsing context " in the PR of the security consideration. Execution or browser execution context is consistently used in the new commits, and I will create a PR for this if we decide to change the name.

Revised text:
2.  <ins> This section uses the concept of ICE agent as defined in RFC8445.  In the remainder of the document, it is assumed that each browsing context (as defined in Section 7.1 of HTMLSpec) has its own ICE agent. </ins> 2.1. 3.3. As noted in IPHandling, privacy may be breached if a web application  <ins> running in two browsing contexts can determine whether it is running </ins> on the same device.  While the approach in this document prevents the application from directly comparing local private IP addresses, a successful local WebRTC connection can also present a threat to user are running on the same device. To avoid this issue, browsers SHOULD NOT register mDNS names for  <ins> WebRTC applications running in a third-party browsing context (i.e., a context that has a different origin than the top-level browsing context), or a private browsing context. </ins> 4. the addition of remote ICE host candidates with mDNS names generates mDNS queries for names of each candidate;  <ins> the removal of names could happen when the browsing context of the ICE agent is destroyed in an implementation, and goodbye responses should be sent to invalidate records generated by the ICE agent in the local network (RFC6762, Section 10.1). </ins> A malicious Web application could flood the local network with mDNS messages by:  <ins> creating browsing contexts that create ICE agents and start </ins> gathering of local ICE host candidates; destroying these local candidates soon after the name registration