W3C home > Mailing lists > Public > www-tag@w3.org > February 2015

Re: Considering the pressure to turn HTTPS into a three-party protocol

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Tue, 17 Feb 2015 21:32:46 +0100
To: Noah Mendelsohn <nrm@arcanedomain.com>
Cc: "www-tag@w3.org List" <www-tag@w3.org>
Message-ID: <6b87ea1fo9r9uhbuhkkm9n5f8mr4sir53v@hive.bjoern.hoehrmann.de>
* Noah Mendelsohn wrote:
>I disagree. The specification is defining the use of a name for purposes of 
>dereference. To conform to this specification, the agent must end-to-end 
>encrypt, and the spirit seems clear that this means not modify the content.
>As I noted, you can create useful agents of all sorts, some of which will 
>do useful things not conforming to this specification. I would argue that 
>your proposed crawler is an example.
>The specification defines a preferred way of dereferencing an https-scheme 
>URI and says that a conforming agent shall do this. The foundational 
>specfication of the web, RFC 3986 delegates to the specification we're 
>discussing. Thus, this appears to me to be the specified, conforming 
>behavior for Web user agents.

The requirement you cited is a MUST-level requirement, it is not a pre-
ference. You are arguing that such a crawler cannot be implemented with-
out violating the protocol. I do not think that is a reasonable reading
and certainly not what I had in mind when reviewing the document as part
of my Last Call reviews. I also note that your argument would go both
ways; if

  user agent -> user configured intermediary -> origin server

violates the protocol, then it seems pretty clear that

  user agent -> CDN -> origin server

would also violate the protocol, as that is not a true end-to-end path
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 
Received on Tuesday, 17 February 2015 20:33:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:10 UTC