[Spec] Remove unneeded example in security section

This example describes a situation that's already prohibited by the processing
model. All the surrounding examples are of cases that aren't prohibited but
implementors should be aware of.

Remove the example and cleanup the non-normative description of this section.

Fixes WICG#180

index.bs

@@ -950,12 +950,19 @@ actor can determine that the text fragment was successfully found in victim
 page as a result of such a navigation, they can infer the existence of any text
 on the page.
 
-The following subsections restrict the feature to mitigate the expected attack
-vectors. In summary, text directives are invoked only on full (non-same-page)
-navigations that are the result of a user activation.  Additionally,
-navigations originating from a different origin than the destination will
-require the navigation to take place in a "noopener" context, such that the
-destination page is known to be sufficiently isolated.
+The processing model in the following subsections restricts the feature to
+mitigate the expected attack vectors. In summary, text directives are restricted
+to:
+
+* top level navigables (i.e. no iframes).
+    * ISSUE(WICG/scroll-to-text-fragment#240): This isn't strictly true, Chrome
+        allows this for same-origin initiators. Need to update the spec on this
+        point.
+* navigations that are the result of a user action
+* in cases where the navigation has a cross-origin initiator, the destination
+    must be opener isolated (i.e. no references to its global objects in other
+    documents)
+
 
 ### Scroll On Navigation ### {#scroll-on-navigation}
 
@@ -981,14 +988,6 @@ detectable and distinguished from natural user scrolls.
   of the fragment search based on the order of requests for DNS lookup.
 </div>
 
-<div class="example">
-  A malicious page embeds a cross-origin victim in an iframe. The victim page
-  contains information sensitive to the user. The malicious page navigates the
-  victim to a text fragment. Since a successful fragment match will cause
-  focus, the malicious page can determine if the text appears in the victim by
-  listening for a blur event in its own document.
-</div>
-
 <div class="example">
   An attacker sends a link to a victim, sending them to a page that displays
   a private token. The attacker asks the victim to read back the token. Using

index.html

@@ -813,7 +813,7 @@
   <div class="head">
    <p data-fill-with="logo"><a class="logo" href="https://www.w3.org/"> <img alt="W3C" height="48" src="https://www.w3.org/StyleSheets/TR/2021/logos/W3C" width="72"> </a> </p>
    <h1 class="p-name no-ref" id="title">URL Fragment Text Directives</h1>
-   <p id="w3c-state"><a href="https://www.w3.org/standards/types#CG-DRAFT">Draft Community Group Report</a>, <time class="dt-updated" datetime="2023-11-20">20 November 2023</time></p>
+   <p id="w3c-state"><a href="https://www.w3.org/standards/types#CG-DRAFT">Draft Community Group Report</a>, <time class="dt-updated" datetime="2023-11-22">22 November 2023</time></p>
    <div data-fill-with="spec-metadata">
     <dl>
      <dt>This version:
@@ -1809,12 +1809,25 @@ <h4 class="heading settled" data-level="3.5.1" id="motivation"><span class="secn
 actor can determine that the text fragment was successfully found in victim
 page as a result of such a navigation, they can infer the existence of any text
 on the page.</p>
-   <p>The following subsections restrict the feature to mitigate the expected attack
-vectors. In summary, text directives are invoked only on full (non-same-page)
-navigations that are the result of a user activation.  Additionally,
-navigations originating from a different origin than the destination will
-require the navigation to take place in a "noopener" context, such that the
-destination page is known to be sufficiently isolated.</p>
+   <p>The processing model in the following subsections restricts the feature to
+mitigate the expected attack vectors. In summary, text directives are restricted
+to:</p>
+   <ul>
+    <li data-md>
+     <p>top level navigables (i.e. no iframes).</p>
+     <ul>
+      <li data-md>
+       <p class="issue" id="issue-35f490f0"><a class="self-link" href="#issue-35f490f0"></a> This isn’t strictly true, Chrome
+allows this for same-origin initiators. Need to update the spec on this
+point. <a href="https://github.com/WICG/scroll-to-text-fragment/issues/240">[Issue #WICG/scroll-to-text-fragment#240]</a></p>
+     </ul>
+    <li data-md>
+     <p>navigations that are the result of a user action</p>
+    <li data-md>
+     <p>in cases where the navigation has a cross-origin initiator, the destination
+must be opener isolated (i.e. no references to its global objects in other
+documents)</p>
+   </ul>
    <h4 class="heading settled" data-level="3.5.2" id="scroll-on-navigation"><span class="secno">3.5.2. </span><span class="content">Scroll On Navigation</span><a class="self-link" href="#scroll-on-navigation"></a></h4>
    <p>A UA may choose to automatically scroll a matched text passage into view. This
 can be a convenient experience for the user but does present some risks that
@@ -1830,11 +1843,6 @@ <h4 class="heading settled" data-level="3.5.2" id="scroll-on-navigation"><span c
   page. The searched-for text appears nearby to a resource located on a unique
   (on the page) domain. The attacker may be able to infer the success or failure
   of the fragment search based on the order of requests for DNS lookup. </div>
-   <div class="example" id="example-4d0b486d"><a class="self-link" href="#example-4d0b486d"></a> A malicious page embeds a cross-origin victim in an iframe. The victim page
-  contains information sensitive to the user. The malicious page navigates the
-  victim to a text fragment. Since a successful fragment match will cause
-  focus, the malicious page can determine if the text appears in the victim by
-  listening for a blur event in its own document. </div>
    <div class="example" id="example-2e4f39df"><a class="self-link" href="#example-2e4f39df"></a> An attacker sends a link to a victim, sending them to a page that displays
   a private token. The attacker asks the victim to read back the token. Using
   a text fragment, the attacker gets the page to load for the victim such that
@@ -3146,6 +3154,9 @@ <h2 class="no-num no-ref heading settled" id="issues-index"><span class="content
       loaded. <a href="https://github.com/WICG/scroll-to-text-fragment/issues/186">#186</a> <a class="issue-return" href="#issue-b49aac41" title="Jump to section">↵</a></div>
    <div class="issue">Implementation note: Blink doesn’t currently set focus for text
   fragments, it probably should? TODO: file crbug. <a class="issue-return" href="#issue-e253a983" title="Jump to section">↵</a></div>
+   <div class="issue"> This isn’t strictly true, Chrome
+allows this for same-origin initiators. Need to update the spec on this
+point. <a href="https://github.com/WICG/scroll-to-text-fragment/issues/240">[Issue #WICG/scroll-to-text-fragment#240]</a> <a class="issue-return" href="#issue-35f490f0" title="Jump to section">↵</a></div>
    <div class="issue"> <a data-link-type="dfn" href="https://dom.spec.whatwg.org/#concept-cd-data">data</a> is not
 correct here since that’s the text data as it exists in the DOM. This
 algorithm means to run over the text as rendered (and then convert back