Protecting UX with Feature Policy

Browsers are capable of bridging sensors, Bluetooth, USB, and other hardware to web apps like never before. However, as always in life, great power can be a double-edged sword. Securing access is a particularly sensitive issue for applications that serve 3rd party content – either as scripts, iframes, or user-supplied media files. Even browser extensions can introduce unexpected content to our products.

Emerging security measures in web browsers introduce a mechanism that allows feature availability management. Modern applications use Feature Policy to:

• Enforce permissions
• Enforce performance

Embedding 3rd party content opens the door to malicious or otherwise unwanted access to various features like geolocation, camera or Bluetooth access, and even automatic video playback. Feature policies can help control such access.

Some 3rd party scripts use notorious JavaScript features like synchronous document writing and communications with a server. These APIs deteriorate user experience because they block any interaction until complete. Feature policies can also help guardrail performance by denying access to such code. They can also be used to ensure properly optimized images are transferred to the browser, which makes Feature Policies a desirable performance enforcing mechanism.

Think of Feature Policies as a contract between the web product owners and their users that governs the use of browser features or lack thereof. For maximum effectiveness, use Feature Policies in development environments to enforce the contract early on.

Implementing Feature Policy

Feature Policy is Content Security Policy’s (CSP) younger sister. Directives are set in an HTTP header, which gives additional opportunity to set features from the server-side programmatically.

Feature-Policy:
    geolocation 'self';
    camera 'none';
    fullscreen '*'

Controlling Iframe Features

<iframe
 src="https://my.ads.com"
 allow="geolocation; document-write">

We can only cherry-pick the allowed features. The disallow attribute does not exist.

Iframe feature policies will inherit settings from the parent document. The more restrictive policy applies. Note that policies propagate to nested iframes in the same restrictive fashion.

Setting Allowed Contexts

Similar to Content Security Policies, each feature respects a list of permitted contexts:

• * – Allow all
• self – Allow the current document and all iframes with the same origin (domain)
• none – Disable the feature altogether
• Create a space-separated list of origins or domains allowed to access a functionality (e.g. https://example.com) with –

  <origins>

Reading Allowed Features

Using Javascript, developers should check if a feature is permitted before using it. In the following example, we will detect if camera access is allowed before connecting to it.

const isCameraAllowed = document.featurePolicy.allowsFeature('camera');

if (isCameraAllowed) {
 // Attach to the camera
        navigator.mediaDevices
          .getUserMedia({ video: true })
          .then(handleVideo)
          .catch(onError);
}

Here are a few other useful Javascript interfaces for Feature Policies:

• document.featurePolicy.features() – get the list of all available features in a browser
• document.featurePolicy.allowedFeatures() – returns an array of all available features for a document
• document.featurePolicy.getAllowlistForFeature('camera') – get contexts that can access a feature (e.g camera)

Feature Policy Compatibility

It’s still early to capitalize on Feature Policies confidently, but most modern browsers support them in some capacity. Documentation is scarce, so rely on the Javascript methods described above.

You can begin introducing feature policies today. Policies are opt-in, so enable them where it makes sense. It’s best to start with your application context before restricting 3rd party content as some of it may break (especially ad-serving scripts).

Here are a few Feature Policies you could implement now:

• oversized-images – disallow large images
• geolocation – control access to user’s location data
• camera – control camera access
• document-write – disallow outdated document.write
• wake-lock – control whether power-saving mode can be disabled
• autoplay – should media like video play automatically
• more policies

If your application doesn’t require hardware access, consider disabling access to the camera, microphone, speakers, and even autoplay. Doing so may help protect your users’ privacy and bandwidth.

You can help us in the mission to create a safer and more reliable Web by sharing this article with the people in your network.