Fix links, add more details, copy editing

index.bs

@@ -638,19 +638,21 @@ Security and Privacy {#security-privacy}
 The Open Screen Protocol allows two networked user agents to discover each other
 and exchange user and application data.  As such, its security and privacy
 considerations should be closely examined.  We first evaluate the protocol
-itself using the W3C [[SECURITY-PRIVACY-QUESTIONNAIRE]].  We then examine
-whether the security and privacy guidelines recommended by the
-[[PRESENTATION-API]] and the [[REMOTE-PLAYBACK] are met.
+itself using the W3C [[SECURITY-PRIVACY-QUESTIONNAIRE|Security and Privacy
+Questionnaire]].  We then examine whether the security and privacy guidelines
+recommended by the [[PRESENTATION-API|Presentation API]] and the
+[[REMOTE-PLAYBACK|Remote Playback API]] are met.  Finally we discuss recommended
+mitigations that implementations can use to meet these security and privacy
+requirements.
 
 Threat Models {#threat-models}
 --------------------------------
 
 ### Passive Network Attackers ### {#passive-network-attackers}
 
 The Open Screen Protocol should assume that all parties that are connected to
-the same LAN as the user agents, either through a wired connection or through
-WiFi, are able to observe all data flowing between Open Screen controllers and
-receivers.
+the same LAN, either through a wired connection or through WiFi, are able to
+observe all data flowing between Open Screen controllers and receivers.
 
 These parties will be able collect any data exposed through unencrypted
 messages, such as mDNS records and the QUIC handshake.
@@ -660,10 +662,10 @@ flows on the QUIC connection, or by observing cryptographic timing.
 
 ### Active Network Attackers ### {#active-network-attackers}
 
-In addition, all parties with access to the LAN will be able to manipulate data
+In addition, all parties connected to the LAN will be able to manipulate data
 exchanged between controllers and receivers.  They will be able to inject
-traffic into both parties and attempt to inititate new QUIC connections.  These abilities
-can be used to attempt the following:
+traffic into existing QUIC connections and attempt to inititate new QUIC
+connections.  These abilities can be used to attempt the following:
 
 *   Impersonate a new receiver or one already trusted by the user, in an attempt
     to convince the user to authenticate to it.
@@ -672,44 +674,41 @@ can be used to attempt the following:
     from the application state of the presentation or remote playback.
 
 One particular attack of concern is misconfigured or compromised routers that
-expose local network devices to the Internet.  This vector of attack has been
-used by remote parties to take control of printers and smart TVs by connecting
-to local network services that should normally be inaccessible from the
-Internet.
+expose local network devices (such as Open Screen Protocol controllers and
+receivers) to the Internet.  This vector of attack has been used by malicious
+parties to take control of printers and smart TVs by connecting to local network
+services that would normally be inaccessible from the Internet.
 
 ### Denial of Service ### {#denial-of-service}
 
-Parties with access to the LAN may attempt to deny access to receivers by
-controllers, or vice versa.  For example, an active attacker my attempt to start
-a large number of QUIC connections on a receiver in an attempt to block
-legitimate connections or exhaust available resources on the presentation
-display.  They may also multicast spurious DNS-SD records in an attempt to
-exhaust the cache capacity for mDNS listeners.
+Parties with connected to the LAN may attempt to deny access to Open Screen
+Protocol controllers and receivers.  For example, an attacker my attempt to open
+a large number of QUIC connections to a receiver in an attempt to block
+legitimate connections or exhaust the receiver's system resources.  They may
+also multicast spurious DNS-SD records in an attempt to exhaust the cache
+capacity for mDNS listeners, or to get listeners to open a large number of bogus
+QUIC connections.
 
 ### Same-Origin Policy Violations ### {#same-origin-policy-violations}
 
 The Presentation API allows cross-origin communication between controlling pages
 and presentations with the consent of each origin (through their use of the
-API).  This is similar to cross-origin communication via {{Worker/postMessage}}.  The
-Open Screen Protocol does not convey origin information between controllers and
-receivers.
+API).  This is similar to cross-origin communication via {{Window/postMessage()}}
+with a target origin of `*`.  However, the Presentation API does not convey
+source origin information with each message.  Therefore, the Open Screen
+Protocol does not convey origin information between controllers and receivers.
 
 The [=presentation ID=] carries some protection against unrestricted
-cross-origin access, but authentication of the parties connected by a
-{{PresentationConnection}} can be done at the application level.
-
-### Third Party Tracking ### {#third-party-tracking}
-
-The Open Screen Protocol does not give third party origins additional access to
-presentations or remote playback state.
+cross-origin access; but, rigorous authentication of the parties connected by a
+{{PresentationConnection}} must be done at the application level.
 
 Open Screen Protocol Considerations {#security-privacy-questions}
 -----------------------------------
 
 ### Personally Identifiable Information & High-Value Data ### {#personally-identifiable-information}
 
-The following data exchanged by the protocol can be personally identifiable and
-thus is high value data:
+The following data exchanged by the protocol can be personally identifiable
+and/or high value data:
 
 1. Presentation URLs and availability results
 1. Presentation IDs
@@ -720,7 +719,7 @@ thus is high value data:
 
 Presentation display friendly names, model names, and capabilities, while not
 considered personally identifiable, is important to protect to preserve the
-integrity of the discovery process.
+integrity of the discovery and authentication process.
 
 The following data cannot be reasonably secured and should be considered public
 and untrusted data:
@@ -733,29 +732,34 @@ and untrusted data:
 
 Access to origin state across browsing sessions is possible through the
 Presentation API by reconnecting to a presentation that was started by a
-previous session. This sceanrio is addressed in
+previous session. This scenario is addressed in
 [[PRESENTATION-API#cross-origin-access]].
 
-Presentation display availability and remote playback availability are states
-that may be available cross-origin depending on the user's network context.
-Exposure of this data to the Web is also discussed in
+Presentation display availability and remote playback device availability are
+states that are available cross-origin depending on the user's network
+context.  Exposure of this data to the Web is also discussed in
 [[PRESENTATION-API#personally-identifiable-information]] and
 [[REMOTE-PLAYBACK#personally-identifiable-information]].
 
 ### Origin Access to Other Devices ### {#origin-access-devices}
 
-By design, the Open Screen Protocol allows access to presentation displays from
-the Web.  By implementing the protocol, these devices are knowingly making
-themselves available to the Web and should be designed accordingly.
+By design, the Open Screen Protocol allows access to presentation displays and
+remote playback devices from the Web.  By implementing the protocol, these
+devices are knowingly making themselves available to the Web and should be
+designed accordingly.
 
-Below, we discuss mitigation steps to prevent malicious use of presentation
-displays.
+Below, we discuss mitigation steps to prevent malicious use of these devices.
 
 ### Incognito Mode ### {#incognito-mode}
 
 The Open Screen Protocol does not distinguish between the user agent's normal
 browsing and incognito modes, and should operate identically regardless of which
-mode is using it.
+mode is in use.
+
+It's recommended that controllers 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 between a user's
+normal profile and their incognito profile.
 
 ### Persistent State ### {#persistent-state}
 
@@ -769,7 +773,8 @@ UI of the user agent during the display selection or display authentication
 process.  It can be an implementation choice whether the user agent clears or
 retains this data when the user clears browsing data.
 
-TODO: File an issue to discuss
+Issue(132): [Privacy] Fate of metadata / authentication history when clearing
+browsing data
 
 ### Other Considerations ### {#other-considerations}
 
@@ -786,9 +791,8 @@ following:
 Presentation API Considerations {#presentation-api-considerations}
 -------------------------------
 
-[[PRESENTATION-API#security-and-privacy-considerations][Presentation API
-Security and Privacy Considerations]] place these requirements on the Open
-Screen Protocol:
+[[PRESENTATION-API#security-and-privacy-considerations]] place these
+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
@@ -810,9 +814,9 @@ The Open Screen Protocol addresses these considerations by:
 Remote Playback API Considerations {#remote-playback-considerations}
 ----------------------------------
 
-The [[REMOTE-PLAYBACK#security-and-privacy-considerations][Remote Playback API
-Security and Privacy Considerations]] also state that messaging between local
-and remote playback devices should also be authenticated and confidential.
+The [[REMOTE-PLAYBACK#security-and-privacy-considerations]] also state that
+messaging between local and remote playback devices should also be authenticated
+and confidential.
 
 This consideration is handled by requiring mutual authentication and a
 TLS-secured QUIC connection before any remote playback related messages are
@@ -831,7 +835,7 @@ before user-mediated authentication takes place.
 Passive attackers may also attempt timing attacks to learn cryptographic the
 cryptographic parameters of the TLS 1.3 QUIC connection.
 
-TODO: Investigate mitigations for this.
+Issue(130): [Security] Review attack and mitigation considerations for TLS 1.3
 
 ### Local active network attackers ### {#local-active-mitigations}
 
@@ -840,7 +844,8 @@ user would normally trust.  The [[#authentication]] step of the Open Screen
 Protocol prevents a man-in-the-middle from impersonating a controller or
 receiver, without knowledge of a shared secret.  However, it is possible for an
 attacker to impersonate an existing, trusted display or a newly discovered
-display that is not yet authenticated by convincing the user to authenticate it.
+display that is 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:
 
@@ -867,7 +872,7 @@ The active attacker may also attempt to disrupt data exchanged over the QUIC
 connection by injecting or modifying traffic.  These attacks should be mitigated
 by a correct implementation of TLS 1.3.
 
-TODO: Protect against TLS replay, esp. if we enable early data.
+Issue(130): [Security] Review attack and mitigation considerations for TLS 1.3
 
 ### Remote active network attackers ### {#remote-active-mitigations}
 
@@ -877,7 +882,7 @@ Protocol implementations that are only intended to work on the LAN should filter
 packets from non-local IP addresses.  Implementations can also use the ARP cache
 to detect attempts to spoof local network IP addresses.
 
-TODO: Fill in more details here.
+Issue(131): [Security] Mitigations for remote network attackers
 
 ### Denial of service ### {#denial-of-service-mitigations}
 
@@ -898,8 +903,8 @@ like JSON and XML.  Still, implementations should be thoroughly tested using
 approaches like [fuzz testing](https://en.wikipedia.org/wiki/Fuzzing).
 
 Where possible, Open Screen Protocol implementations (including the content
-rendering components) should use defense-in-depth techniques like
-[sandboxing](https://en.wikipedia.org/wiki/Sandbox_(computer_security)).
+rendering components) should use defense-in-depth techniques like <a
+href="https://en.wikipedia.org/wiki/Sandbox_(computer_security)">sandboxing</a>
 to prevent vulnerabilities from gaining access to user data or leading to
 persistent exploits.