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
Is this question for document.referrer only or for HTTP referrer headers too?
Thanks. document.referrer only.
<rdar://problem/59005187>
(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?
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.
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.
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.
(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.