Child origin:

Ready

[Home]

Site Permissions in Iframes

Verifies which origin the browser uses for permission identity when a permission request originates from an iframe rather than the top-level page. This exposes bugs where the browser stores a permission grant against the iframe's requester origin instead of a normalised site key, causing unexpected dialogs, duplicate prompts, or unrecognisable settings entries.

The cross-origin iframe loads this same page from one of the repo's test domains (good.third-party.site on live, third-party.example locally). Both resolve to the same server and serve the same files, so no external dependency is needed.

Configuration

First-party Panel

First-party first-party

Origin:

Iframe Panels

Same-origin same-origin

Iframe src:

Parent origin:

Cross-origin cross-origin

Iframe src:

Parent origin:

Test Steps

Test 0 — First-party baseline

  1. In the First-party panel, click a permission button (e.g. Geolocation or Camera).
  2. Observe the permission dialog — the domain shown should be the top-level page origin.
  3. Grant the permission (tap Allow).
  4. Open browser Settings > Site Permissions. Verify the grant is stored against the top-level site domain.
  5. This establishes the baseline: the same permission requested from an iframe should behave identically in terms of which domain is shown and how the grant is keyed.

Test 1 — Cross-origin permission identity

  1. In the Cross-origin iframe panel, click a permission button (e.g. Geolocation or Camera) inside the embedded page.
  2. Observe the permission dialog — which domain does it display? Record it below.
  3. Grant the permission (tap Allow).
  4. Open browser Settings > Site Permissions. Which domain is the grant stored against? Is it the iframe origin, the top-level site, or an eTLD+1?
  5. Navigate the top-level page to the iframe's origin directly (e.g. open good.third-party.site in a new tab).
  6. Request the same permission again — are you prompted again, or is the grant reused?

Test 2 — Same-origin baseline

  1. In the Same-origin iframe panel, click the same permission button.
  2. Observe the permission dialog — the domain shown should match the top-level page.
  3. Grant the permission.
  4. Verify in Settings that the grant is stored against the top-level site domain.

Test 3 — Same-eTLD+1 subdomain (local dev only)

  1. Set up local hostnames per the repo README:
    127.0.0.1  first-party.example
    127.0.0.1  sub.first-party.example
    Both hostnames in the mkcert certificate:
    mkcert first-party.example "*.first-party.example" ...
  2. Set ?child=https://sub.first-party.example/features/iframe-permissions.html
  3. Follow the same steps as Test 1.
  4. After granting, navigate to first-party.example directly and re-request the same permission.
    • BUG (current): you get prompted again because the grant is keyed to the subdomain.
    • FIXED: the grant should be reused because both share the same eTLD+1.

Observation Log

Expected Outcomes

Before the permission identity fix

ScenarioDialog showsStored againstRe-prompted?
First-party (no iframe) privacy-test-pages.site privacy-test-pages.site No
Same-origin iframe privacy-test-pages.site privacy-test-pages.site No
Cross-origin iframe (good.third-party.site) good.third-party.site good.third-party.site N/A (different site)
Same-eTLD+1 subdomain (local) sub.first-party.example sub.first-party.example Yes (bug)

After the permission identity fix

ScenarioDialog showsStored againstRe-prompted?
First-party (no iframe) privacy-test-pages.site privacy-test-pages.site No
Same-origin iframe privacy-test-pages.site privacy-test-pages.site No
Cross-origin iframe (good.third-party.site) good.third-party.site good.third-party.site N/A (different site)
Same-eTLD+1 subdomain (local) first-party.example (eTLD+1) first-party.example (eTLD+1) No (fixed)

Event Log