206957 2020-01-29 12:46:01 -0800 iFrames no longer respect referrerpolicy attribute value in ITP 2020-06-23 09:24:47 -0700 1 1 1 Unclassified WebKit Frames Safari Technology Preview Unspecified Unspecified NEW https://jackwellborn.com/playground/iFrameReferrerTest/top.html?foo=bar InRadar P2 Normal --- 1 w0nka wilander joel katherine_cheney webkit-bug-importer wilander oldest_to_newest 1612617 0 w0nka 2020-01-29 12:46:01 -0800 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 1612645 1 wilander 2020-01-29 13:38:13 -0800 Is this question for document.referrer only or for HTTP referrer headers too? 1612648 2 w0nka 2020-01-29 13:42:35 -0800 Thanks. document.referrer only. 1612651 3 webkit-bug-importer 2020-01-29 13:48:48 -0800 <rdar://problem/59005187> 1612657 4 wilander 2020-01-29 13:54:18 -0800 (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? 1612694 5 w0nka 2020-01-29 14:39:47 -0800 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. 1612741 6 wilander 2020-01-29 15:56:57 -0800 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. 1612806 7 w0nka 2020-01-29 18:29:35 -0800 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. 1613486 8 wilander 2020-01-31 10:55:03 -0800 (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.