Bug 206957 – iFrames no longer respect referrerpolicy attribute value in ITP

• Status: NEW
• Component: Frames

[Jack Wellborn]

Hello,

The link provided shows several iframes that have a referrerpolicy="same-origin". The expected behavior shown in current Safari, Firefox, and Chrome is that both the friendly and sandboxed same-origin iframes get the full referrer while the cross-origin iframes get nothing. In Safari Technology Preview Release 99, the sandboxed iframe is also getting nothing. In the very least I would like to know whether this is a bug or if downgrading document.referrer to eTLD+1 even when the owner explicitly opts to share more information is an intended part of ITP 2.3 https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/. 

Thanks.

~Jack

[John Wilander]

Is this question for document.referrer only or for HTTP referrer headers too?

[Jack Wellborn]

Thanks. document.referrer only.

[Radar WebKit Bug Importer]

<rdar://problem/59005187>

[John Wilander]

(In reply to Jack Wellborn from comment #2)
> Thanks. document.referrer only.

Further questions – are you saying that:
1) This changed between STP 98 and 99?
2) The iframe that's seeing a downgraded document.referrer is same-origin, same-site, or cross-site?
3) The downgraded document.referrer is just the eTLD+1 or just the origin?
4) The iframe that's seeing a downgraded document.referrer is nested? If so, what does the chain of origins look like from the affected iframe all the way to the top frame?

[Jack Wellborn]

1) This changed between STP 98 and 99?
Not sure, this came up in a project this week. I can say that the current version of regular Safari on Mojave seems to give me the full referrer when using document.referrer from a sandboxed iframe.

2) The iframe that's seeing a downgraded document.referrer is same-origin, same-site, or cross-site?
Using the definition here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)#Usage, I believe my example is shows sandboxed and non-sandboxed same-origin and cross-site iframes.

3) The downgraded document.referrer is just the eTLD+1 or just the origin?
Seems to be eTLD+1 (the 'www' comes through when clicking the below). https://www.jackwellborn.com/playground/iFrameReferrerTest/top.html?foo=bar shows the referrer with 

4) The iframe that's seeing a downgraded document.referrer is nested? If so, what does the chain of origins look like from the affected iframe all the way to the top frame?
I have updated my test page to include various nested scenarios. 
https://www.jackwellborn.com/playground/iFrameReferrerTest/top.html?foo=bar

Hope this helps.

[John Wilander]

Getting lost in terminology here. I have to ask for some clarifications. See inline.

(In reply to Jack Wellborn from comment #5)
> 1) This changed between STP 98 and 99?
> Not sure, this came up in a project this week. I can say that the current
> version of regular Safari on Mojave seems to give me the full referrer when
> using document.referrer from a sandboxed iframe.

There is quite a significant difference between current STP and current shipping Safari.

> 2) The iframe that's seeing a downgraded document.referrer is same-origin,
> same-site, or cross-site?
> Using the definition here:
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-
> Origin_Resource_Policy_(CORP)#Usage, I believe my example is shows sandboxed
> and non-sandboxed same-origin and cross-site iframes.

An iframe cannot be same-origin and cross-site at the same time so I assume you're talking about multiple iframes.


> 3) The downgraded document.referrer is just the eTLD+1 or just the origin?
> Seems to be eTLD+1 (the 'www' comes through when clicking the below).
> https://www.jackwellborn.com/playground/iFrameReferrerTest/top.html?foo=bar
> shows the referrer with 

Then it's not the eTLD+1 but rather the full origin. This is what I see on your example page.

> 4) The iframe that's seeing a downgraded document.referrer is nested? If so,
> what does the chain of origins look like from the affected iframe all the
> way to the top frame?
> I have updated my test page to include various nested scenarios. 
> https://www.jackwellborn.com/playground/iFrameReferrerTest/top.html?foo=bar

Thanks! I think the last two are indicating the wrong results. Look at the text output in them.

Looking at your example page (thanks for setting it up), I think the behavior is expected. Expected as in a "technology preview," or things to come.

If the site (eTLD+1) of the referrer differs from the site (eTLD+1) of the iframe, document.referrer only returns the origin.

In the case of sandboxed iframes, they get the unique origin unless you give them the allow-same-origin token. This means that the comparison "if the site (eTLD+1) of the referrer differs from the site (eTLD+1) of the iframe" results in false since the unique origin doesn't match any other origin.

[Jack Wellborn]

Thanks.

> An iframe cannot be same-origin and cross-site at the same time so I assume you're talking about multiple iframes. 

Am I mistaken that a website could have one iframe with same-origin source and another iframe with a cross-site source?

> Then it's not the eTLD+1 but rather the full origin. This is what I see on your example page.

Ah. I misinterpreted the MDN link. I think I finally get it.

> Thanks! I think the last two are indicating the wrong results. Look at the text output in them.

The second to last one is jackwellborn.com (top) > wormsandviruses.com (outer iframe) > jackwellborn.com (inner iframe). Because the inner iframe (jackwellborn.com) has a different origin than the outer iframe (wormsandviruses.com), it only gets the referrer origin.

The last one is jackwellborn.com (top) > wormsandviruses.com (outer iframe) > wormsandviruses.com (inner iframe). If I understand correctly, the inner iframe sees the full referrer because it shares the same origin of the outer iframe. Both are wormsandviruses.com.

Thanks for clarifying. Would Webkit consider supporting referrerpolicy="same-origin" for sandboxed iframes? This would allow publishers to share basic data while still sandboxing contents. Furthermore, I don't think there is a data leakage/tracking concern since it's still restricted to same origin. While there is the allow-same-origin sandbox value, my understanding is that would also greatly undermine the benefits of the sandbox, especially if allow-scripts are also included. Thanks again.

[John Wilander]

(In reply to Jack Wellborn from comment #7)
> Thanks.
> 
> > An iframe cannot be same-origin and cross-site at the same time so I assume you're talking about multiple iframes. 
> 
> Am I mistaken that a website could have one iframe with same-origin source
> and another iframe with a cross-site source?
> 
> > Then it's not the eTLD+1 but rather the full origin. This is what I see on your example page.
> 
> Ah. I misinterpreted the MDN link. I think I finally get it.
> 
> > Thanks! I think the last two are indicating the wrong results. Look at the text output in them.
> 
> The second to last one is jackwellborn.com (top) > wormsandviruses.com
> (outer iframe) > jackwellborn.com (inner iframe). Because the inner iframe
> (jackwellborn.com) has a different origin than the outer iframe
> (wormsandviruses.com), it only gets the referrer origin.
> 
> The last one is jackwellborn.com (top) > wormsandviruses.com (outer iframe)
> > wormsandviruses.com (inner iframe). If I understand correctly, the inner
> iframe sees the full referrer because it shares the same origin of the outer
> iframe. Both are wormsandviruses.com.
> 
> Thanks for clarifying. Would Webkit consider supporting
> referrerpolicy="same-origin" for sandboxed iframes? This would allow
> publishers to share basic data while still sandboxing contents. Furthermore,
> I don't think there is a data leakage/tracking concern since it's still
> restricted to same origin. While there is the allow-same-origin sandbox
> value, my understanding is that would also greatly undermine the benefits of
> the sandbox, especially if allow-scripts are also included. Thanks again.

Allowing full document.referrer for sandboxed same-site iframes without the "allow-same-origin" token is a reasonable ask. It's up for consideration.