Copy NVS security and privacy considerations from explainer to spec

Closes #287.

no-vary-search.bs

@@ -339,3 +339,12 @@ Two [=URLs=] |urlA| and |urlB| are <dfn export>equivalent modulo search variance
         <td>`https://example.com/?a= &`
   </table>
 </div>
+
+<h2 id="security-considerations">Security considerations</h2>
+The main risk to be aware of is the impact of mismatched URLs. In particular, this could cause the user to see a response that was originally fetched from a URL different from the one displayed when they hovered a link, or the URL displayed in the URL bar.
+
+However, since the impact is limited to query parameters, this does not cross the relevant security boundary, which is the [=origin=]. (Or perhaps just the [=url/host=], from [[URL#url-rendering-simplification|the perspective of security UI]].) Indeed, we have already given origins complete control over how they present the (URL, reponse body) pair, including on the client side via technology such as {{History/replaceState()|history.replaceState()}} or service workers.
+
+<h2 id="privacy-considerations">Privacy considerations</h2>
+
+This proposal is adjacent to the highly-privacy-relevant space of [[NAV-TRACKING-MITIGATIONS#terminology|navigational tracking]], which often uses query parameters to pass along user identifiers. However, we believe this proposal itself does not have privacy impacts. It does not interfere with [[NAV-TRACKING-MITIGATIONS#deployed-mitigations|existing navigational tracking mitigations]], or any known future ones being contemplated. Indeed, if a page were to encode user identifiers in its URL, the only ability this proposal gives is to *reduce* such user tracking by preventing server processing of such user IDs (since the server is bypassed in favor of the cache).

no-vary-search.md

@@ -391,6 +391,6 @@ We're hopeful a response header will suffice, instead of needing to go this rout
 
 Security-wise, the main risk to be aware of is the impact of mismatched URLs. In particular, this could cause the user to see a response that was originally fetched from a URL different from the one displayed when they hovered a link, or the URL displayed in the URL bar.
 
-However, since the impact is limited to query parameters, this does not cross the relevant security boundary, which is the origin. (Or perhaps just the host, from [the perspective of security UI](https://url.spec.whatwg.org/#url-rendering-simplification).) Indeed, we already given origins complete control over how they present the (URL, reponse body) pair, including on the client side via technology such `history.replaceState()` or service workers.
+However, since the impact is limited to query parameters, this does not cross the relevant security boundary, which is the origin. (Or perhaps just the host, from [the perspective of security UI](https://url.spec.whatwg.org/#url-rendering-simplification).) Indeed, we have already given origins complete control over how they present the (URL, reponse body) pair, including on the client side via technology such as `history.replaceState()` or service workers.
 
 For privacy, as [mentioned previously](#carrying-data-that-is-or-can-be-processed-by-client-side-script-only), this proposal is adjacent to the highly-privacy-relevant space of [navigational tracking](https://privacycg.github.io/nav-tracking-mitigations/#terminology), which often uses query parameters to pass along user identifiers. However, we believe this proposal itself does not have privacy impacts. It does not interfere with [existing navigational tracking mitigations](https://privacycg.github.io/nav-tracking-mitigations/#deployed-mitigations), or any known future ones being contemplated. Indeed, if a page were to encode user identifiers in its URL, the only ability this proposal gives is to _reduce_ such user tracking by preventing server processing of such user IDs (since the server is bypassed in favor of the cache).