Summary

  • W3C's 2019 Feature Policy draft let a page declare which browser features its documents and embedded guests could use. Its examples include fullscreen, geolocation, camera and microphone.
  • The September 2026 Permissions Policy draft gives the arrangement two visible surfaces: a document-level HTTP response header and the allow attribute on a particular iframe. Inherited policy carries the parent's choices into the guest room.

Imagine a website as a small theater. The main page owns the building. It invites a map into one booth, a video player into another and a payment form into a third. Each booth is an embedded frame. The map would like the visitor's location; the player might want fullscreen; a meeting widget may ask for camera access. Giving every guest a master key would make the stage manager's job exciting in all the wrong ways.

The W3C's first public Feature Policy draft, published in April 2019, gave the stage manager a written list. An HTTP response header called Feature-Policy could disable features for the page and its descendants or restrict them to selected origins. The draft's examples put fullscreen and geolocation on the list, then show camera and microphone confined to a chosen embedded origin. The important invention was a location for the host's decision. It traveled with the page rather than hiding in a patchwork of assumptions about every guest.

The September 2026 Permissions Policy working draft says plainly that the specification used to be named Feature Policy. The name changed, and the current header is Permissions-Policy. Its syntax is a structured dictionary. One example is Permissions-Policy: fullscreen=(), geolocation=(): empty lists leave those two capabilities unavailable throughout the document's descendants. A venue that wants no filming has closed the camera room before the guests arrive.

Now change the scene. The host wants one embedded map to use geolocation. The 2026 draft shows an iframe with allow="geolocation". That attribute addresses this particular guest room. The page-level header can also draw an outer boundary around permitted origins. The draft's example permits the site's own origin and a named guest origin in the header, then uses allow to choose the frame that receives access. A guest in another booth cannot wave the neighboring invitation and claim the same privilege.

There are three decisions in play. Each feature has a default allowlist. The parent document can declare a policy in its response header. The iframe's container policy is shaped by its allow attribute. When a child document is created or navigated, it inherits a state determined by the parent and the container. That inheritance is the real lock. A frame cannot enlarge an entitlement that the host's policy has already shut. The guest's own document still has its own declared policy, but it begins from the permissions the doorway allows.

This is why “put it in an iframe” was never a complete answer to who gets the keys. An iframe draws a separate browsing context, yet modern features cross far beyond passive display. Location, camera, microphone, fullscreen and other APIs make a guest's behavior consequential for the person viewing the page. The policy framework turns a host's choice into a browser-enforced part of the embedding arrangement. A page builder can invite a guest without assuming that invitation includes every feature in the building.

The 2026 draft also makes the rules inspectable. A document can query its permissionsPolicy object to learn whether a feature is available and present a suitable interface. An iframe element has a corresponding policy view. A map widget that has no route to geolocation can show an address field; a camera widget can leave its shutter button offstage. The check observes the policy gate. The user's permission prompt and the device's own availability are later decisions, made by different actors.

The W3C's publication history records the long run of working drafts up to September 2026. Across those drafts, the guest-room problem stayed concrete: one page could contain many pieces of other pages, while browser features grew more powerful. The host needed a way to write a rule for the whole venue and then make a deliberate exception for one booth. The browser needed a way to carry that rule down the corridor.