- From: Ryan Sleevi <notifications@github.com>
- Date: Thu, 03 Jun 2021 09:12:51 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/1247/853992782@github.com>
> Aside: it says there that it is fine to discover if a user is behind a proxy, but is that really true? Can you discover that reliably today? I believe it would be best described as "placeholder for discussion", while wanting to be explicit in calling out the path that Chrome's implementation took (in part, for ease/expediency). Ultimately, similar to the complexities around file:// origins and scoping permissions (to the file vs to the directory vs to the scheme), there's complexity tradeoffs; if we blocked proxies from making such connections at all, that'd almost certainly be more disruptive. Treating them as 'public' implicitly would also cause issues with many existing proxy uses (where the proxy is used to access local resources, as opposed to being bypassed for local resources) It's certainly come up several times before, particularly with Resource Timing APIs. For example, `nextHopProtocol` has the potential to disclose the proxy information (since the proxy is, by definition, the next hop). Network Error Logging similarly can give indications of the presence/absence of a proxy, as can using mTLS. Ideally, we would not provide any such differentiation, but fundamentally, a proxy is a different connection path than direct, so anything keyed of connection properties (e.g. the IP address) necessarily offer a differentiation. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/1247#issuecomment-853992782
Received on Thursday, 3 June 2021 16:14:30 UTC