Will original HTTP Referer be preserved?

[todd-patterson]

I understand the proposal is about IP protection and masking the originating IP address. However, I'd like to understand if the original HTTP Referer will be unchanged and accessible after traffic passes-through the proxy(s).

HTTP Referer is sometimes used instead of IP address for allowlist / denylist behavior. I realize that using Referer for access-control behavior comes with some risks (Referer can 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 HTTP Referer unmodified, such that end-servers will still be able to know the original Referer?

If the original value is preserved, will it still be available on the traditional Referer header, or another header (e.g. *-Forwarded-*)?

[dvorak42]

There are no plans to alter the Referer header 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 the Referer header 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 the Referer header happen outside of this feature those will be communicated with their own Intent process.

[todd-patterson]

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.