Closed todd-patterson closed 8 months ago
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.
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
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 usingReferer
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 HTTPReferer
unmodified, 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
Referer
header, or another header (e.g.*-Forwarded-*
)?