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.
Older sites could continue to function as they do today or perhaps be even more heavily sandboxed AND not have access to new APIs.
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.
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.
These "security flags" could be added for almost anything that might annoy a user; it's not just for security.
Yes, if it's playing audio not initiated by the user.
> These "security flags" could be added for almost anything that might annoy a user; it's not just for security.
Good. I'm a user and I don't like being annoyed. It's… annoying.