Repository navigation
Will original HTTP Referer be preserved? #22
Description
Activity
There are no plans to alter the
Refererheader as part of IP protection, and it will be the same as what would have been sent if the request wasn't sent through the IP protection system. The value will continue to be available in theRefererheader as normal. HTTP headers are encrypted end-to-end between Chrome and the origin website, so the proxies cannot see nor modify them. If changes to theRefererheader happen outside of this feature those will be communicated with their own Intent process.Got it, thank you. This was my assumption but wanted to confirm. I wasn't sure if SSL termination would happen at the proxy (e.g. in order to add headers and/or modify headers, such as for instrumentation or other purposes) and then traffic would be re-encrypted before sending on to final destination. You've clarified that won't happen.
I understand the proposal is about IP protection and masking the originating IP address. However, I'd like to understand if the original HTTP
Refererwill be unchanged and accessible after traffic passes-through the proxy(s).HTTP
Refereris sometimes used instead of IP address for allowlist / denylist behavior. I realize that usingRefererfor access-control behavior comes with some risks (Referercan be manipulated in some environments and scenarios), but it is considered "good enough" in some cases (your mileage may vary). This can be particularly important and useful for iframe scenarios.I've read through the Github explainer and https://developer.chrome.com/en/docs/privacy-sandbox/ip-protection/, but didn't find any specific mention of
Referer. Will all proxy(s) involved (whether 1-hop, 2-hop, or more) pass-along HTTPRefererunmodified, such that end-servers will still be able to know the originalReferer?If the original value is preserved, will it still be available on the traditional
Refererheader, or another header (e.g.*-Forwarded-*)?