Address more comments

index.bs

@@ -852,10 +852,10 @@ The Open Screen Protocol does not distinguish between the user agent's normal
 browsing and incognito modes, and agents that follow the specification
 behave identically regardless of which mode is in use.
 
-It's recommended that controllers use separate authentication contexts and QUIC
+It's recommended that user agents use separate authentication contexts and QUIC
 connections for normal and incognito profiles from the same user agent instance.
-This prevents Open Screen receivers from correlating activity among a user's
-profiles (both normal and incognito).
+This prevents Open Screen agents from correlating activity among profiles
+belonging to the same user (both normal and incognito).
 
 ### Persistent State ### {#persistent-state}
 
@@ -892,9 +892,10 @@ requirements on the Open Screen Protocol:
 1.  Presentation URLs and presentation IDs should remain private among the
     parties that are allowed to connect to a presentation, per the
     cross-origin access guidelines.
-1.  Controllers and receivers should be notified when multiple connections have
-    been made to a presentation, per the user interface guidelines.
-1.  Messaging between presentations and controllers should be authenticated and
+1.  Controllers and receivers should be notified when connections representing
+    multiple user agent profiles have been made to a presentation, per the user
+    interface guidelines.
+1.  Messaging between controllers and receivers should be authenticated and
     confidential, per the guidelines for messaging between presentation
     connections.
 
@@ -927,7 +928,7 @@ device capabilties using the Open Screen Protocol.  The main strategy to address
 this is data minimization, by only exposing opaque public key fingerprints
 before user-mediated authentication takes place.
 
-Passive attackers may also attempt timing attacks to learn cryptographic the
+Passive attackers may also attempt timing attacks to learn the
 cryptographic parameters of the TLS 1.3 QUIC connection.
 
 Issue(130): [Security] Review attack and mitigation considerations for TLS 1.3
@@ -943,8 +944,10 @@ not yet authenticated and try to convince the user to authenticate it.
 
 This can be addressed through a combination of techniques.  The first is flagging:
 
-* Flag advertised displays whose friendly name, public key fingerprint, or
-    IP:port collide with an already trusted display.
+* Flag an advertised display whose public key fingerprint collides with that
+    from an already-trusted display that is concurrently being advertised.
+* Flag an advertised display whose friendly name differs from the one previously
+    advertised under a public key fingerprint.
 * Flag already-trusted displays whose metadata has changed.
 * Flag agents that fail the authentication challenge a certain number of times.
 

index.html

@@ -1403,7 +1403,11 @@
   <div class="head">
    <p data-fill-with="logo"></p>
    <h1 class="p-name no-ref" id="title">Open Screen Protocol</h1>
+<<<<<<< HEAD
    <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2019-03-05">5 March 2019</time></span></h2>
+=======
+   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2019-03-22">22 March 2019</time></span></h2>
+>>>>>>> Address more comments
    <div data-fill-with="spec-metadata">
     <dl>
      <dt>This version:
@@ -2177,10 +2181,10 @@ <h4 class="heading settled" data-level="8.2.4" id="incognito-mode"><span class="
    <p>The Open Screen Protocol does not distinguish between the user agent’s normal
 browsing and incognito modes, and agents that follow the specification
 behave identically regardless of which mode is in use.</p>
-   <p>It’s recommended that controllers use separate authentication contexts and QUIC
+   <p>It’s recommended that user agents use separate authentication contexts and QUIC
 connections for normal and incognito profiles from the same user agent instance.
-This prevents Open Screen receivers from correlating activity among a user’s
-profiles (both normal and incognito).</p>
+This prevents Open Screen agents from correlating activity among profiles
+belonging to the same user (both normal and incognito).</p>
    <h4 class="heading settled" data-level="8.2.5" id="persistent-state"><span class="secno">8.2.5. </span><span class="content">Persistent State</span><a class="self-link" href="#persistent-state"></a></h4>
    <p>An agent is likely to persist the identity of agents that have successfully
 completed <a href="#authentication">§6 Authentication</a>.  This may include the public key fingerprints,
@@ -2217,10 +2221,11 @@ <h3 class="heading settled" data-level="8.3" id="presentation-api-considerations
 parties that are allowed to connect to a presentation, per the
 cross-origin access guidelines.</p>
     <li data-md>
-     <p>Controllers and receivers should be notified when multiple connections have
-been made to a presentation, per the user interface guidelines.</p>
+     <p>Controllers and receivers should be notified when connections representing
+multiple user agent profiles have been made to a presentation, per the user
+interface guidelines.</p>
     <li data-md>
-     <p>Messaging between presentations and controllers should be authenticated and
+     <p>Messaging between controllers and receivers should be authenticated and
 confidential, per the guidelines for messaging between presentation
 connections.</p>
    </ol>
@@ -2246,7 +2251,7 @@ <h4 class="heading settled" data-level="8.5.1" id="local-passive-mitigations"><s
 device capabilties using the Open Screen Protocol.  The main strategy to address
 this is data minimization, by only exposing opaque public key fingerprints
 before user-mediated authentication takes place.</p>
-   <p>Passive attackers may also attempt timing attacks to learn cryptographic the
+   <p>Passive attackers may also attempt timing attacks to learn the
 cryptographic parameters of the TLS 1.3 QUIC connection.</p>
    <p class="issue" id="issue-5107ff88"><a class="self-link" href="#issue-5107ff88"></a> [Security] Review attack and mitigation considerations for TLS 1.3 <a href="https://github.com/webscreens/openscreenprotocol/issues/130">&lt;https://github.com/webscreens/openscreenprotocol/issues/130></a></p>
    <h4 class="heading settled" data-level="8.5.2" id="local-active-mitigations"><span class="secno">8.5.2. </span><span class="content">Local active network attackers</span><a class="self-link" href="#local-active-mitigations"></a></h4>
@@ -2259,8 +2264,11 @@ <h4 class="heading settled" data-level="8.5.2" id="local-active-mitigations"><sp
    <p>This can be addressed through a combination of techniques.  The first is flagging:</p>
    <ul>
     <li data-md>
-     <p>Flag advertised displays whose friendly name, public key fingerprint, or
-IP:port collide with an already trusted display.</p>
+     <p>Flag an advertised display whose public key fingerprint collides with that
+from an already-trusted display that is concurrently being advertised.</p>
+    <li data-md>
+     <p>Flag an advertised display whose friendly name differs from the one previously
+advertised under a public key fingerprint.</p>
     <li data-md>
      <p>Flag already-trusted displays whose metadata has changed.</p>
     <li data-md>