Thanks for posting.

This is actually a bit of a minefield.

On rel="noopener"...

rel="noopener" is implemented in browsers for a couple of years only, i.e. is relatively new.

We do *already* support forcing rel="noopener" in Comcode.

Normally what happens is a user without 'allow_html' privilege will post something using WYSIWYG, then Composr will convert that HTML to Comcode, and then rel="noopener" will be applied.

However, it has increasingly been our policy to greenlight the idea that regular users can be given 'allow_html' privilege and our blacklister in the Comcode compiler would filter out any dangerous HTML like JavaScript (as well as our XSS detector that looks at input).

In this scenario, a *blacklist* is not going to *inject* additional HTML. Nor should we try to make that happen, Comcode is already incredibly complicated.

WHATWG have specified a new policy that target="_blank" links should not have a window.opener to be manipulated:
https://github.com/whatwg/html/issues/4078
And browsers have finished implementing it this year:
https://bugs.chromium.org/p/chromium/issues/detail?id=927340
https://bugzilla.mozilla.org/show_bug.cgi?id=1503681
https://bugs.webkit.org/show_bug.cgi?id=190481

If a link does not have target="_blank" then there will be no window.opener to manipulate, and no issue.

However, a user may put in rel="opener" and workaround this!
We could implement blacklisting in the Comcode compiler for rel="opener".
Probably as a v10 security fix (I don't think it warrants implementing our security response process though, this is relatively specific and minor).

Meanwhile, there is a much more robust approach, a new CSP-like policy COOP:
https://www.chromestatus.com/feature/5432089535053824
(this Chrome link provides links to the specification and implementation status in browsers).
This is not yet implemented in Chromium, but nearly done. It is already implemented in Firefox. Development has not apparently started in webkit.
There is lead time to worry about here.
It is a concern that COOP introduces yet another HTTP header for something pretty minor, but it seems worth it. I'd be for implementing this in v11.

v10:
- Blacklist rel="opener"

v11:
- Implement COOP

~v12 (once we can rely on COOP being available):
- Remove rel="opener" blacklist
- Remove rel="noopener" injection in Comcode

Implemented changes for v10, and v11. Keeping issue open for ~v12 (with updated title).

I've removed the v12 tag as various obscure browsers do not support this (it isn't something implemented by the rendering engine, so even rendering engines using WebKit/Blink are not going to automatically get this).
Better to just leave our robust handling in there, for now at least.