News for hackers. Stuff that matters.
Re:A new security header: Feature Policy by Ajedi32 on Monday July 30, 2018 @10:08AM (#17644481)
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.

Re:A new security header: Feature Policy by kps on Monday July 30, 2018 @10:40AM (#17644672)
Devil's advocate: If your site is doing something that is worth adding a secturiy flag for, and is unmaintained, it should break.
Re:A new security header: Feature Policy by Ajedi32 on Monday July 30, 2018 @10:52AM (#17644784)
Such as... playing audio?

These "security flags" could be added for almost anything that might annoy a user; it's not just for security.

Re:A new security header: Feature Policy by kps on Monday July 30, 2018 @01:43PM (#17646366)
> Such as... playing audio?

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.