- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Tue, 28 Feb 2017 13:52:31 -0700
- To: HTTP working group mailing list <ietf-http-wg@w3.org>
- Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
On 02/28/2017 01:09 PM, Kari Hurtta wrote: >> 1. When a client, while talking to a forward proxy, detects and reports >> a communication error, it SHOULD mention that the proxy was involved and >> SHOULD mention the address of that proxy. >> >> It seems silly to propose that though -- it ought to be common sense, >> especially for CONNECT errors, especially for folks concerned about user >> privacy. > Yes, this looks like common sense. And still no one browser does that. According to Adrien, FireFox complies with the first SHOULD (at least): https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0288.html > When proxy is selected or not by proxy.pac, it is not obvious that > is proxy used for particular request. It is always obvious for the browser. I assume you mean that it is not obvious for the user, and I agree with that (with cases not limited to just PAC-driven proxy selection!). Exposing hidden or obscured proxy usage should be (but is not) a great motivation for anti-proxy folks arguing that the user must have full control at all costs. This disconnect feeds conspiracy theories that those folks prioritize things other than user's informed consent and control. >> 2. Clients would also need to support retrieval of HTTPS resources by a >> forward HTTPS proxy. While such mechanism is already supported by HTTP >> and TLS, its actual deployment probably requires secure response signing >> and other fancy stuff that, AFAIK, others have already proposed. > You means passing https -URLs to proxy for retrieval. Yes. A.k.a. "GET https://" inside a TLS connection to the proxy. > Proxy needs also then way to report what certificate it > got from server. To be more precise, the _browser_ needs that, but, yes, this is probably required, and that is exactly why I mentioned secure response signing (or something like that) as a prerequisite. The proxy would need to somehow forward origin's response signature or public certificate (at least). This is where an HTTP extension is required. Everything else is already supported (at the protocol level) AFAICT. > In that case location bar probbaly need to be two lines: > First line tells proxy and certificate status of proxy URL > Second line tells reported certifcate of server and visited URL Third line tells whether the proxy certificate is Transparently Logged Fourth line tells the Root CA that signed the proxy certificate Fifth line tells the majority stock holder of that Root CA Sixth line tells whether that stock holder signed the XYZ pledge ... I continue to resist the temptation to tell browser folks how to do UI. I am sure that they can build great UIs, and that they do not need this WG "help" with that. It is a solvable design problem. With enough motivation, they can solve it. Alex.
Received on Tuesday, 28 February 2017 20:53:01 UTC