Redact ancestorOrigins using iframe referrerpolicy by zcorpan · Pull Request #11560 · whatwg/html

zcorpan · 2025-08-14T11:10:20Z

This aligns ancestorOrigins exposure with referrer policy when using the iframe referrerpolicy attribute, so an embedder can prevent revealing its own origin to embedded documents. If an <iframe> uses referrerpolicy="no-referrer" or same-origin (and the parent and child are cross-origin), the parent’s origin and any same-origin ancestors are replaced with opaque origins (until reaching an ancestor that is cross-origin). Other policies continue to expose full origins.

This approach keeps existing behavior by default (for web compat) while addressing privacy concerns with an opt-out.

The algorithm reuses the parent's existing list of ancestor origins, avoiding synchronous cross-process lookups and ensuring a stable snapshot even if ancestors mutate their referrerpolicy attributes later.

Fixes #1918. Closes #2480.

At least two implementers are interested (and none opposed):
- Gecko
- WebKit
Tests are written and can be reviewed and commented upon at:
Implementation bugs are filed:
- Chromium: https://issues.chromium.org/u/1/issues/465806326
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1085214
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=303537
Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
MDN issue is filed: Document that iframe referrerpolicy can influence location.ancestorOrigins and windowclient.ancestorOrigins mdn/content#42231
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

/browsers.html ( diff )
/browsing-the-web.html ( diff )
/document-lifecycle.html ( diff )
/document-sequences.html ( diff )
/dom.html ( diff )
/iframe-embed-object.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/nav-history-apis.html ( diff )

zcorpan · 2025-08-14T11:12:51Z

This is the same as @annevk's #2480 but applied on top of the latest main. Rebasing involved a lot of unrelated conflicts, so instead I copied over the content in a new branch.

annevk · 2025-08-14T12:52:12Z

I think using the document's referrer is the wrong model. Because we don't care about the referrer of top-level example.com (how the user got to example.com, perhaps from search.example), we care about example.com's policy (or its iframe's policy) when embedding widget.example, when determining what information widget.example should have access to.

zcorpan · 2025-08-14T17:07:02Z

I created a doc to work out how to specify this with the new model: https://docs.google.com/document/d/1TDryRMiw7sVKBfrvnzEQk0PzGQk7_G7ShF4Uy68MvSU/edit?usp=sharing

Copy of the doc's current state

Example 1

example.org (no referrer policy)
- Iframe referrerpolicy=”no-referrer”
  - Widget.example

Result: [“https://widget.example”, “null”]

Example 2

example.org (no referrer policy)
- Iframe referrerpolicy=”no-referrer”
  - Widget.example and navigates to other.example

Result: ???

Algo

HTML:

Let output be a new list of strings.
Let currentDoc be the Location object's relevant Document.
Let innerDoc be current.
Let currentContainer be null.
While currentDoc’'s container document is non-null:
1. Set currentContainer to current’s node navigable’s container.
2. Set currentDoc to current's container document.
3. Let origin be the result of getting an origin if the referrer policy allows given currentContainer, currentDoc, and innerDoc.
4. Append the serialization of current's origin to output.
Return output.

Referrer Policy:

To get an origin if the referrer policy allows given an element or null container, a document doc, and a document innerDoc:

Let elementReferrerPolicy be the empty string.
If element is not null, then set elementReferrerPolicy to element’s referrerpolicy attribute’s state.
Let docReferrerPolicy be doc’s referrer policy.
Let referrerPolicy be elementReferrerPolicy.
If referrerPolicy is the empty string, then set referrerPolicy to docReferrerPolicy.
If referrerPolicy is “no-referrer”, then return “null”.
If referrerPolicy is “same-origin” and doc’s origin is not same origin with innerDoc’s origin, then return “null”.
If referrerPolicy is “strict-origin”, "strict-origin-when-cross-origin", “no-referrer-when-downgrade”, and innerDoc’s URL is not potentially trustworthy but doc’s URL is potentially trustworthy, then return “null”.
Return the serialization of doc’s origin.

zcorpan · 2025-09-01T14:25:02Z

Doc updated. I've changed the algorithm to avoid exposing A's origin in the A->A->C case with the innermost iframe having referrerpolicy="no-referrer". Also added examples from w3c/webappsec-referrer-policy#77 (comment) and a polyfill to test with.

Copy of the doc's current state

Algorithm

HTML:

Let output be a new list of strings.
Let currentDoc be the Location object's relevant Document.
Let innerDoc be currentDoc.
Let currentContainer be null.
Let prevOrigin and prevMasked be uninitialized.
While currentDoc’s container document is non-null:
1. Set currentContainer to currentDoc’s node navigable’s container.
2. Set currentDoc to currentDoc's container document.
3. Let « origin, masked » be the result of [=getting an ancestor origin if the referrer policy allows=] given currentContainer, currentDoc, and innerDoc.
4. If prevMasked is true and origin is same origin with prevOrigin, then set masked to true.
5. If masked is true, then append “null” to output.
6. Otherwise, append the serialization of origin to output.
7. Set prevOrigin to origin.
8. Set prevMasked to masked.
Return output.

Referrer Policy:

To get an ancestor origin if the referrer policy allows given an Element container, a Document doc, and a Document innerDoc:

Let elementReferrerPolicy be the empty string.
If container is an iframe element, then set elementReferrerPolicy to container’s referrerpolicy attribute’s state.
Let docReferrerPolicy be doc’s policy container’s referrer policy.
Let referrerPolicy be elementReferrerPolicy.
If referrerPolicy is the empty string, then set referrerPolicy to docReferrerPolicy.
Let masked be false.
If referrerPolicy is “no-referrer”, then set masked to true.
Otherwise, if referrerPolicy is “same-origin” and doc’s origin is not same origin with innerDoc’s origin, then set masked to true.
Return « doc’s origin, masked ».

Note: Since mixed content checks prevent non-secure context documents in secure context documents, there’s no need to check secure context for “strict-origin”, "strict-origin-when-cross-origin", and “no-referrer-when-downgrade”.

Polyfill + demo

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/14030

Examples

iframe referrerpolicy=”no-referrer”

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe referrerpolicy=”no-referrer”, origin: https://b.com

Child: ["null"]

Examples below are from w3c/webappsec-referrer-policy#77 (comment)

top -> sandboxed iframe -> 3rd party iframe (ad)

Top-level browsing context, default referrer policy, origin: https://a.com
- Iframe sandbox, origin: opaque
  - Iframe, origin: https://b.com

Grandchild: ["null","https://a.com"]
Child: ["https://a.com"]

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag that's loading b.com -> loads {3, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe referrerpolicy=”no-referrer”, origin: https://b.com
  - iframe, origin: https://a.com

Grandchild: ["https://b.com","null"]
Child: ["null"]

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://b.com
  - Iframe referrerpolicy=”no-referrer”, origin: https://a.com

Grandchild: ["null","https://a.com"]
Child: ["https://a.com"]

{1, a.com} default referrer policy -> loads {2, a.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, c.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://a.com
  - iframe referrerpolicy=”no-referrer”, origin: https://c.com

Grandchild: ["null","null"]
Child: ["https://a.com"]

{1, a.com} default referrer policy -> loads {2, b.com} with default referrer policy -> loads {3, b.com} with noreferrer attribute on the iframe tag inside {3} -> loads {4, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://b.com
  - iframe, origin: https://b.com
    - iframe referrerpolicy=”no-referrer”, origin: https://a.com

Grandgrandchild: ["null","null","https://a.com"]
Grandchild: ["https://b.com","https://a.com"]
Child: ["https://a.com"]

zcorpan · 2025-09-02T11:39:31Z

After discussing with @farre we found out that reading the iframe's referrerpolicy attribute every time ancestorOrigins is read is not great. Instead, the value of the referrerpolicy attribute should be read when the document is created and stored on the document (or in its policy container).

zcorpan · 2025-09-05T10:01:26Z

reading the iframe's referrerpolicy attribute every time ancestorOrigins is read is not great.

This was not correct, the spec computes the ancestor origins list when the Location object is created, which happens when the Window object is created.

When a Location object is created, its ancestor origins list must be set to a DOMStringList object whose associated list is the list of strings that the following steps would produce:

https://html.spec.whatwg.org/#concept-location-ancestor-origins-list

Each Window object is associated with a unique instance of a Location object, allocated when the Window object is created.

https://html.spec.whatwg.org/#the-location-interface

So no need to store iframe's referrerpolicy. However, we want to minimize IPC and avoid inconsistency e.g. when an ancestor iframe's referrerpolicy attribute is mutated and a new child iframe is inserted (or is navigated). So the model we came up with now is to take the parent's ancestor origins list, mask some values as appropriate, and insert a new value.

Copy of the doc's current state

Algorithm

A Location object has an associated ancestor origin objects list. When a Location object is created, its ancestor origins list must be set to the list of origins that the following steps would produce:

Let output be a new list of origins.
Let innerDoc be the Location object's relevant Document.
Let parentDoc be innerDoc’s container document.
If parentDoc is non-null:
1. Assert: parentDoc is fully active.
2. Let parentLocation be parentDoc’s relevant global object’s Location object.
3. Let ancestorOrigins be parentLocation’s ancestor origins list’s associated list.
4. Let container be innerDoc’s node navigable’s container.
5. Let referrerpolicyAttribute be the empty string.
6. If container supports a referrer policy attribute (e.g., container is an iframe element), then set referrerpolicyAttribute to container’s referrer policy attribute’s state.
7. Let docReferrerPolicy be parentDoc’s policy container’s referrer policy.
8. Let referrerPolicy be referrerpolicyAttribute.
9. If referrerPolicy is the empty string, then set referrerPolicy to docReferrerPolicy.
10. Let masked be false.
11. If referrerPolicy is “no-referrer”, then set masked to true.
12. Otherwise, if referrerPolicy is “same-origin” and parentDoc’s origin is not same origin with innerDoc’s origin, then set masked to true.
13. If masked is true, then append “null” to output.
14. Otherwise, append parentDoc’s origin to output.
15. For each ancestorOrigin in ancestorOrigins:
  1. If masked is true:
    1. If ancestorOrigin is same origin with parentDoc’s origin, then append a new opaque origin to output.
    2. Otherwise, append ancestorOrigin to output and set masked to false.
  2. Otherwise, append ancestorOrigin to output.
Return output.

Note: Since mixed content checks prevent non-secure context documents in secure context documents, there’s no need to check secure context for “strict-origin”, "strict-origin-when-cross-origin", and “no-referrer-when-downgrade”.

A Location object has an associated ancestor origins list. When a Location object is created, its ancestor origins list must be set to a DOMStringList object whose associated list is the list of strings the following steps would produce:

Let ancestorOrigins be this’s ancestor origin objects list.
Let output be a new list of strings.
For each origin in ancestorOrigins:
1. Append the serialization of origin to output.
Return output.

Polyfill + demo

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/14047

Examples

iframe referrerpolicy=”no-referrer”

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe referrerpolicy=”no-referrer”, origin: https://b.com

Child: ["null"]

{1, a.com} default referrer policy -> loads {2, b.com} -> loads {3, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://b.com
  - iframe, origin: https://c.com

Grandchild: ["https://b.com","https://a.com"\]
Child: ["https://a.com"\]

Examples below are from w3c/webappsec-referrer-policy#77 (comment)

top -> sandboxed iframe -> 3rd party iframe (ad)

Top-level browsing context, default referrer policy, origin: https://a.com
- Iframe sandbox, origin: opaque
  - Iframe, origin: https://b.com

Grandchild: ["null","https://a.com"\]
Child: ["https://a.com"\]

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag that's loading b.com -> loads {3, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe referrerpolicy=”no-referrer”, origin: https://b.com
  - iframe, origin: https://a.com

Grandchild: ["https://b.com","null"\]
Child: ["null"]

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://b.com
  - Iframe referrerpolicy=”no-referrer”, origin: https://a.com

Grandchild: ["null","https://a.com"\]
Child: ["https://a.com"\]

{1, a.com} default referrer policy -> loads {2, a.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, c.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://a.com
  - iframe referrerpolicy=”no-referrer”, origin: https://c.com

Grandchild: ["null","null"]
Child: ["https://a.com"\]

{1, a.com} default referrer policy -> loads {2, b.com} with default referrer policy -> loads {3, b.com} with noreferrer attribute on the iframe tag inside {3} -> loads {4, a.com}

Top-level browsing context, default referrer policy, origin: https://a.com
- iframe, origin: https://b.com
  - iframe, origin: https://b.com
    - iframe referrerpolicy=”no-referrer”, origin: https://a.com

Grandgrandchild: ["null","null","https://a.com"\]
Grandchild: ["https://b.com","https://a.com"\]
Child: ["https://a.com"\]

TODOs

Test https://w3c.github.io/ServiceWorker/#client-ancestororigins

zcorpan · 2025-09-08T07:52:35Z

I've updated this PR, the algorithm should be the same as in the doc.

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Due to the tentative nature of the spec, and details still being hashed out, this PR is subject to minor changes.

This follows the current revamping of the spec found at whatwg/html#11560 and will change with it, potentially.

zcorpan · 2025-10-08T13:40:06Z

I wrote a summary of what this change does in the OP. (To be used in the commit message when squashing.)

noamr · 2025-10-13T15:35:00Z

cc @domfarolino

annevk · 2025-10-23T17:05:17Z

Before I forget: we need to patch https://w3c.github.io/ServiceWorker/#client-ancestororigins at the same time.

zcorpan · 2025-10-27T21:59:55Z

@annevk as far as I can tell, the call sites for Create Window Client use a Location object's ancestor origins list, which is still defined and compatible with this PR. But we should have tests for it.

johannhof · 2025-11-07T05:41:31Z

What is the reason for using the referrer policy instead of a new attribute / header? Are we not concerned that this would lead to situations where one of the two features is required, making it impossible for sites to opt out of the other?

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Due to the tentative nature of the spec, and details still being hashed out, this PR is subject to minor changes.

This follows the current revamping of the spec found at whatwg/html#11560 and will change with it, potentially.

theIDinside · 2025-11-07T15:44:07Z

So I've noticed a "bug" in the spec, or at least what we're expecting with one of the tests (and possibly others), while implementing this in Gecko (referenced commit in this convo).

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag that's loading b.com -> loads {3, a.com}
* Top-level browsing context, default referrer policy, origin: https://a.com
  
  * iframe referrerpolicy=”no-referrer”, origin: https://b.com
    
    * iframe, origin: https://a.com
Grandchild: ["https://b.com","null"]
Child: ["null"]

In this example, A1->B1->A2, where
(A1) <iframe src=B1 referrerPolicy=no-referrer>, this means that when B1 is loaded, it's policy container will contain "no referrer" as it's referrer policy. So when it loads A2 via <iframe src=A2> and it does its check, it sees that no attribute is set (the empty string) and therefore should defer to it's parentDoc, which is B1, who has been set with no-referrer. This means it should be [null, null] and [null] as results with this.

I don't know how we could even "turn the feature back on", with this approach as intended in that test, as empty string != default on, right?

zcorpan · 2025-11-10T02:31:21Z

What is the reason for using the referrer policy instead of a new attribute / header?

I think because it's similar enough to be used and because if a page uses referrer policy to hide itself from another document, ancestorOrigins would leak the referrer origin. A separate attribute/header might be too obscure to get the same level of adoption as referrer policy.

Are we not concerned that this would lead to situations where one of the two features is required, making it impossible for sites to opt out of the other?

When would sites want to hide only one?

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1085214 gecko-commit: 626bfdb90f3e1a0f78c6a6e832697520396e66bf gecko-reviewers: necko-reviewers, webidl, dom-core, smaug, jesup, zcorpan

This implements this attribute on Location and also adheres to the changes to the spec introduced in whatwg/html#11560 Tentative tests are also added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D273393 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1085214 gecko-commit: f3415e1670266a11917af7fff4ba14afde5d7ca5 gecko-reviewers: necko-reviewers, webidl, dom-core, smaug, jesup, zcorpan, devtools-reviewers, nchevobbe

annevk · 2026-02-16T17:26:39Z

+       <var>output</var>.</p></li>
+
+       <li><p>Otherwise, <span data-x="list append">append</span> <var>ancestorOrigin</var> to
+       <var>output</var> and set <var>masked</var> to false.</p></li>


This seems surprising. Can't the further ancestor be cross-origin with both parent and self? I guess the idea is that it's already an opaque origin in that case?

It can be, and it's intended to expose the further ancestor's origin in that case (see #11560 (comment) ) unless it opted to hide its origin.

This aligns `ancestorOrigins` exposure with referrer policy when using the `iframe referrerpolicy` attribute, so an embedder can prevent revealing its own origin to embedded documents. If an `<iframe>` uses `referrerpolicy="no-referrer"` or `same-origin` (and the parent and child are cross-origin), the parent’s origin and any same-origin ancestors are replaced with opaque origins (until reaching an ancestor that is cross-origin). Other policies continue to expose full origins. This approach keeps existing behavior by default (for web compat) while addressing privacy concerns with an opt-out. The algorithm reuses the parent's existing list of ancestor origins, avoiding synchronous cross-process lookups and ensuring a stable snapshot even if ancestors mutate their `referrerpolicy` attributes later. Fixes #1918. Closes #2480.

zcorpan · 2026-03-05T14:49:01Z

Rebased and resolved conflicts (from #12071 ).

annevk

This looks okay to me, but I'd like to see some of the slightly confusing cases better clarified.

annevk · 2026-03-10T18:03:38Z

+
+    <p class="note">Since <span>mixed content</span> checks prevent <span>non-secure context</span>
+    <span data-x="environment">environments</span> in <span>secure context</span> <span
+    data-x="environment">environments</span>, there's no need to check <span>secure context</span>


secure contexts?

(There was a proposal btw to allow non-secure contexts inside secure contexts...)

Where is that proposal?

annevk

Very nice. I think one case we could improve a little bit by using an early continue. That way the branching is less deep and less duplicated.

…rerpolicy See whatwg/html#11560

…storOrigins with iframe referrerpolicy, a=testonly Automatic update from web-platform-tests [service-workers] Test WindowClient ancestorOrigins with iframe referrerpolicy See whatwg/html#11560 -- wpt-commits: 60cd2c1605e452c62db05f93873cc7a148fa6093 wpt-pr: 56616

…storOrigins with iframe referrerpolicy, a=testonly Automatic update from web-platform-tests [service-workers] Test WindowClient ancestorOrigins with iframe referrerpolicy See whatwg/html#11560 -- wpt-commits: 60cd2c1605e452c62db05f93873cc7a148fa6093 wpt-pr: 56616 UltraBlame original commit: a3f6b619cfa40bfea66b1b03c72b13d326f1ba27

zcorpan mentioned this pull request Aug 14, 2025

Redact ancestorOrigins using "the document's referrer" #2480

Closed

zcorpan commented Aug 14, 2025

View reviewed changes

Comment thread source Outdated

zcorpan mentioned this pull request Sep 2, 2025

ancestorOrigins web-platform-tests/wpt#5402

Closed

zcorpan changed the title ~~Redact ancestorOrigins using "the document's referrer"~~ Redact ancestorOrigins using referrer policy Sep 3, 2025

annevk reviewed Sep 8, 2025

View reviewed changes

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

annevk reviewed Sep 10, 2025

View reviewed changes

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

theIDinside added a commit to theIDinside/firefox that referenced this pull request Sep 10, 2025

Added tentative tests for location.ancestorOrigins

01d7d02

This follows the current revamping of the spec found at whatwg/html#11560 and will change with it, potentially.

zcorpan added the agenda+ To be discussed at a triage meeting label Sep 25, 2025

cwilso mentioned this pull request Oct 3, 2025

Upcoming WHATNOT meeting on 2025-10-02 #11717

Closed

noamr mentioned this pull request Oct 9, 2025

Upcoming WHATNOT meeting on 2025-10-09 #11747

Closed

domfarolino reviewed Oct 23, 2025

View reviewed changes

Comment thread source Outdated

Comment thread source Outdated

Comment thread source Outdated

zcorpan removed the agenda+ To be discussed at a triage meeting label Oct 23, 2025

zcorpan force-pushed the zcorpan/redact-ancestororigins branch from 3c5e61f to 0004ccb Compare October 27, 2025 21:50

theIDinside added a commit to theIDinside/firefox that referenced this pull request Nov 7, 2025

Added tentative tests for location.ancestorOrigins

0a0e902

This follows the current revamping of the spec found at whatwg/html#11560 and will change with it, potentially.

domfarolino mentioned this pull request Jan 21, 2026

Calculate ancestorOrigins on document creation and store on document #12071

Merged

7 tasks

annevk requested changes Feb 16, 2026

View reviewed changes

zcorpan force-pushed the zcorpan/redact-ancestororigins branch from 6a302f4 to 2568667 Compare March 5, 2026 14:47

zcorpan added 4 commits March 5, 2026 15:51

Fix wrapping

974e07c

Fix typo

efaf543

Fix variable name

3362ce9

Typo a.com -> a.example

d82bae9

annevk reviewed Mar 10, 2026

View reviewed changes

zcorpan added 7 commits March 11, 2026 10:25

Rename innerDoc to document

959d48e

Tweak wording in note about secure contexts

a18fce1

iframe element referrer policy

fff2e8a

Add a note in the iframe element referrer policy section

1e1eb50

Add a note explaining the implication of setting masked to false

adee55e

Location -> Document in example

42637cb

Add more examples

3636520

annevk approved these changes Mar 11, 2026

View reviewed changes

Comment thread source Outdated

Use 'continue'

92253f5

zcorpan merged commit e161310 into main Mar 11, 2026
2 checks passed

zcorpan deleted the zcorpan/redact-ancestororigins branch March 11, 2026 14:45

zcorpan added a commit to web-platform-tests/wpt that referenced this pull request Mar 11, 2026

[service-workers] Test WindowClient ancestorOrigins with iframe refer…

60cd2c1

…rerpolicy See whatwg/html#11560

zcorpan mentioned this pull request Mar 11, 2026

Track ancestorOrigins privacy issues w3c/ServiceWorker#1075

Closed

vamshikrishnaramasamy mentioned this pull request May 29, 2026

Location/WindowClient ancestorOrigins: note iframe referrerpolicy effect mdn/content#44291

Merged

Conversation

zcorpan commented Aug 14, 2025 • edited by pr-preview Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zcorpan commented Aug 14, 2025

Uh oh!

annevk commented Aug 14, 2025

Uh oh!

Uh oh!

zcorpan commented Aug 14, 2025

Example 1

Example 2

Algo

Uh oh!

zcorpan commented Sep 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Algorithm

Polyfill + demo

Examples

iframe referrerpolicy=”no-referrer”

top -> sandboxed iframe -> 3rd party iframe (ad)

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag that's loading b.com -> loads {3, a.com}

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, a.com}

{1, a.com} default referrer policy -> loads {2, a.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, c.com}

{1, a.com} default referrer policy -> loads {2, b.com} with default referrer policy -> loads {3, b.com} with noreferrer attribute on the iframe tag inside {3} -> loads {4, a.com}

Uh oh!

zcorpan commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zcorpan commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Algorithm

Polyfill + demo

Examples

iframe referrerpolicy=”no-referrer”

{1, a.com} default referrer policy -> loads {2, b.com} -> loads {3, a.com}

top -> sandboxed iframe -> 3rd party iframe (ad)

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag that's loading b.com -> loads {3, a.com}

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, a.com}

{1, a.com} default referrer policy -> loads {2, a.com} with noreferrer attribute on the iframe tag inside {2} -> loads {3, c.com}

{1, a.com} default referrer policy -> loads {2, b.com} with default referrer policy -> loads {3, b.com} with noreferrer attribute on the iframe tag inside {3} -> loads {4, a.com}

TODOs

Uh oh!

zcorpan commented Sep 8, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

zcorpan commented Oct 8, 2025

Uh oh!

noamr commented Oct 13, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

annevk commented Oct 23, 2025

Uh oh!

zcorpan commented Oct 27, 2025

Uh oh!

johannhof commented Nov 7, 2025

Uh oh!

theIDinside commented Nov 7, 2025

{1, a.com} default referrer policy -> loads {2, b.com} with noreferrer attribute on the iframe tag that's loading b.com -> loads {3, a.com}

Uh oh!

zcorpan commented Nov 10, 2025

Uh oh!

Uh oh!

annevk Feb 16, 2026

Choose a reason for hiding this comment

Uh oh!

zcorpan Mar 3, 2026

Choose a reason for hiding this comment

zcorpan commented Aug 14, 2025 •

edited by pr-preview Bot

Loading

zcorpan commented Sep 1, 2025 •

edited

Loading

zcorpan commented Sep 2, 2025 •

edited

Loading

zcorpan commented Sep 5, 2025 •

edited

Loading