Issue wording

spec.bs

@@ -2893,12 +2893,14 @@ CORP violation report=] algorithm, as leaving it unfenced may cause a privacy le
     1. If |url| is a [=urn uuid=] and |navigable| is a [=fenced navigable container/fenced
        navigable=]:
 
-       Issue: If a fenced frame generates a FencedFrameConfig using a config-generating API, and
-       then correctly guesses the urn:uuid of that config, it can currently navigate itself to that
-       config, even though this is meant to only allow embedders to navigate fenced frames to
-       configs. This algorithm should be patched to be able to take in a FencedFrameConfig and use
-       that as the check to determine if this path is followed. See:
-       [issue #194](https://github.com/WICG/fenced-frame/issues/194)
+       Issue: The above condition is not as tight as it needs to be. For example, if a
+       <{fencedframe}> generates a {{FencedFrameConfig}} using a config-generating API, and then
+       correctly guesses the config's [=fencedframeconfig/urn|urn:uuid=], it can theoretically
+       navigate itself to that config by passing the guessed urn into the navigate algorithm as a
+       [=URL=], via something like the {{Window/location}} API. This is bad, because the purpose of
+       a {{FencedFrameConfig}} is to ensure that only an embedder can navigate a <{fencedframe}> to
+       the resource represented by the config, by using the config object directly. See <a
+       href=https://github.com/WICG/fenced-frame/issues/194>#194</a> for thoughts on fixing this.
 
       1. Let |config| be the result of [=fenced frame config mapping/finding a
          config=] in <var ignore>sourceDocument</var>'s [=node navigable=]'s [=navigable/traversable