Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Will original HTTP Referer be preserved? #22

Closed
todd-patterson opened this issue Oct 24, 2023 · 2 comments
Closed

Will original HTTP Referer be preserved? #22

todd-patterson opened this issue Oct 24, 2023 · 2 comments

Comments

@todd-patterson
Copy link

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
Copy link

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dvorak42 @todd-patterson