As privacy engineering is getting more and more mature as a field in some settings experts are creating a "privacy checklist" of things to have. It's useful in design, development, and deployment, but also audits. Many useful things could be added to such a list.

Of particular recent relevance is the configuration of web browser permissions. Permissions allow the website access to certain sensitive mechanisms, like geolocation, webcam, etc. But as more and more powerful features are being added to a web browser, there is a need to be able to configure such access in simple ways.

That's what Permissions Policy is all about. It's a web browser feature improving the management of privacy information flows. For example, it can be used to easily globally (on the visited website) disable access to sensitive stuff like geolocation, camera access, notifications, and so on. It's a must-have for the privacy engineering checklist. Configuration is a simple header:

Permissions-Policy: fullscreen=(), geolocation=()

Once this is included, a website would be unable to trigger fullscreen, or access geolocation. The specified features will be disabled. It can be more granular, as per the specification:

SecureCorp Inc. wants to completely disable use of the Geolocation API within all browsing contexts except for its own origin and those whose origin is "https://example.com", even in the presence of an attacker who can embed their own iframes on SecureCorp’s pages. It can do this by delivering the following HTTP response header to define a restricted permissions policy for Geolocation:

Permissions-Policy: geolocation=(self "https://example.com")

The allowlist is a list of one or more origins, which can include the application’s origin, optionally with the keyword "self", and any third-party origin.

With this policy in effect, it can then use the "allow" iframe attribute as usual to grant geolocation to certain frames, but only those frames hosting content from http://example.com or SecureCorp itself will actually be granted the ability to use that API.

No rogue script or malicious tampering with the site (cyberattack-like) would be able to bypass such a limitation. That's why it should be considered a good practice, security by design, privacy by design, and so on.

This feature can also report violations, which is a useful feature. If defined, and a violation report occurs, what is the possible reason? Development mistake, or an attempt to modify the site (unsanctioned, as in a cyberattack/compromise)? It's certainly worth finding out!

It's a useful tool to improve the technical design of the website. It can also help get compliant with data protection laws, for sure. I approve!

Did you like the assessment and analysis? Any questions, comments, complaints, or offers of engagement ? Feel free to reach out: me@lukaszolejnik.com