- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Mon, 27 Feb 2017 10:40:01 -0700
- To: ietf-http-wg@w3.org
- Cc: Mark Nottingham <mnot@mnot.net>
On 02/26/2017 06:50 PM, Mark Nottingham wrote: > What I'm hearing from the discussion is that [...] *any* ability to > indicate the real nature of the problem would help avoid deploying > more MitM > The sweet spot sounds like it needs to balance the network > administrator's desire to convey the reason and their identity with > the browser vendors' need to minimise the new surface area exposed, > as well as resources to implement. > I wrote that draft with that in mind -- happy to change the details. I do not know how to phrase this so that it does not sound unnecessary harsh, but it feels like you are hearing what you want to hear (i.e., what your draft enables): On this thread, I have heard virtually no reasonable justification for limiting the proxy error vocabulary. Yes, several folks shared stories about those old browser bugs and were justifiably worried about the dangers of incorrectly presenting from-proxy content. And yes, one person said that he is going to recommend FireFox because that browser reveals a tiny bit more about the error, but there is a huge gap between all that and a claim that a limited vocabulary would both alleviate those fears and address enough use cases IMHO. This is not meant as an attack of some sort. I am only claiming that there is currently no consensus about or even rational justification for the limited vocabulary (and the latest example with a plain text phone number is a good illustration why there should not be). I am worried that if we push limited vocabulary as The Solution, and browsers painfully implement that, but the volume of needless MitM attacks does not go down substantially (because limited vocabulary is not The Solution), then we will be in an even worse position than we are today. Thank you, Alex.
Received on Monday, 27 February 2017 17:40:30 UTC