Re: [permissions-policy] Privacy by default

Hey Per,

I can provide some insight from back when I was following along with Feature Policy, the previous incarnation of Permissions Policy.

The problem comes down to what is meant by "default"? There is no defined set of 'default' permissions so what it ends up meaning is 'all currently supported permissions' in the particular client. Different clients support a different set of permissions and adopt them at different rates, not to mention variation caused by uptake of updates, so we end up with a very wide meaning for 'all currently supported permissions'. This list of permissions also changes over time with the addition of more permissions and possibly the deprecation of permissions too. This means you'd never actually know what "default" truly means.

If a new permission were to be added, like `document.write` or `can-load-images`, the set of permissions covered by "default" would expand and if your site depends on that permission/feature, it would no longer function until you realised something was broken and added the new permission to your Permissions Policy header to be allowed. This kind of opportunity for causing large scale breakage of websites is typically not favourable and avoided. It would also make browser vendors hesitant to add new permissions for fear of breaking websites, ultimately being counterproductive.

As a security person myself, I too prefer the idea of being secure by default and blocking everything, only allowing what I specify, but that's only safe with either a fixed list of permissions or a way to do this with backwards compatibility, neither of which we have, sadly!

Some sources:
https://github.com/w3c/webappsec-permissions-policy/issues/189
https://github.com/w3c/webappsec-permissions-policy/issues/208
https://github.com/w3c/webappsec-permissions-policy/issues/327
https://github.com/w3c/webappsec-permissions-policy/blob/main/policies/document-write.md

Hope that helps!

Kind regards,

Scott.
https://scotthelme.co.uk


________________________________
From: Per �stergaard <Per.Oestergaard@lego.com>
Sent: 06 December 2021 12:49
To: public-webappsec@w3.org <public-webappsec@w3.org>
Subject: [permissions-policy] Privacy by default


Hi



I was wondering why there is no default method. Without a default=() (e.g. no permissions), our websites have to return a long list of deny permissions. Furthermore, this list needs to be updated whenever new permissions appears. IHO it would make much more sense to have a deny-all setting and open for the features we know our solution supports. In this way, we would also restrict any unauthorized code (injection attacks, supply chain attacks, content editors� HTML).



How come this design was chosen and how can I influence the standard?



Always have fun





[LEGO]

Per �stergaard
Principal Engineer
Digital Security

Mobile

+4540235746

E-mail

Per.Oestergaard@lego.com<mailto:Per.Oestergaard@lego.com>

LEGO System A/S
�stvej
7190 Billund
Denmark
Company: +45 79506070
www.LEGO.com<http://www.LEGO.com>

LEGO and the LEGO logo are trademarks of the LEGO Group. �2021
The LEGO Group. This email message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.