Example 12 (security/privacy) seems unneeded

[annevk]

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.

This attack is ruled out by the processing model. If we wanted to include examples that are already ruled out, we'd have to include many more. (But also, we'd have to update the surrounding text which assumes they are not ruled out.)

[bokand]

I wanted to include this case, even though it's precluded by our processing model, to give readers some idea of the kinds of cases we need to be worried about. But you're right that it doesn't fit with the other examples or surrounding prose.

I'll see if I can rework this section to make this clearer.

[bokand]

Actually, re-reading this, text fragments in an iframe aren't strictly precluded by the processing model (this changed but not since this was filed) since we only perform the top-level browsing context check for cross-origin initiators. This enables e.g. an iframe'd document navigating itself to a text fragment. Edit: I think this was wrong, cross-origin is checked after text directive user activation (which is where the top-level check was confusingly included, #239 makes this clearer)

That said, it's done via sec-fetch-site which is wrong per #179 so I'll need to address it there.