Surely this header should be an allow list, not a block list? Disable features from iframes etc. until permitted, if the header's present, so that you never end up with unexpected activity from external sources.
Unfortunately, reverse compatibility forces the web into a blacklisting model with new headers.
In my Copious Free Time (TM) I am trying to write a web framework that is default deny instead, so even if the web itself is whitelist based, you can try to write in a default-deny environment for security reasons. But even if imagine a perfect such framework from 2017, now in 2018 you have these new headers to deal with, and it means even if the 2018 version of this default-deny framework comes up, you can't just upgrade the framework itself and do nothing because now if you default-deny all of these the website stops working. Plus it's a sense of false security if you program this restriction that says "no iframes!" if someone uses a browser that doesn't support it.
Couldn't we instead have a header sites could implement to indicate they're compatible with the newer security model? The incentive would be that new features can only be accessed by sites that conform to the new model.
Older sites could continue to function as they do today or perhaps be even more heavily sandboxed AND not have access to new APIs.
Permissive by default also means you have to worry about making sure that every time a new feature comes out that you have to go back and update your code to disallow it rather than updating it to be allowed only if and when you actually want to use it.
I also wonder if this will lead bad actors to scan for this header and start targeting their ads at sites that don't have this policy configured.
It really does seem incredibly poorly thought out.
If it were an allow list, then they wouldn't be able to add more features to the list without breaking backwards compatibility.
For example, imagine your site relies on document.write to function, and there's currently no feature policy that lets you whitelist that feature. You create a whitelist that includes the features you do use, but that list doesn't mention document.write, because there's currently no way to block or allow that with a feature policy. Now imagine Chrome adds a feature policy for document.write six months later; your site will break because you didn't explicitly whitelist document.write, even though that would have been impossible for you to do at the time your site was first created.
In my Copious Free Time (TM) I am trying to write a web framework that is default deny instead, so even if the web itself is whitelist based, you can try to write in a default-deny environment for security reasons. But even if imagine a perfect such framework from 2017, now in 2018 you have these new headers to deal with, and it means even if the 2018 version of this default-deny framework comes up, you can't just upgrade the framework itself and do nothing because now if you default-deny all of these the website stops working. Plus it's a sense of false security if you program this restriction that says "no iframes!" if someone uses a browser that doesn't support it.
It's a hard problem, unfortunately.