- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 29 Jan 2015 16:46:48 +1100
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- Cc: Public TAG List <www-tag@w3.org>
Hey Noah, Hate to be the bearer of bad news here, but transforming content is perfectly acceptable according to HTTP, *provided* that the "no-transform" directive isn't present. See: http://httpwg.github.io/specs/rfc7230.html#message.transformations Education would help. W3C has already published: http://www.w3.org/TR/ct-guidelines/ What would be nice is a clearer statement that intercepting proxies (aka "transparent proxies", although that's a misnomer) -- i.e., those interposed by the network at a lower layer, rather than explicitly configured by the client -- are not sanctioned by the protocol, and in fact violate internet architecture. There are some relevant documents here, e.g., <http://www.ietf.org/rfc/rfc2775.txt>: """ Similarly, for a protocol such as HTTP with a well-defined voluntary proxy mechanism, application proxies also serving as caches are very useful. Although these devices interfere with transparency, they do so in a precise way, correctly terminating network, transport and application protocols on both sides. They can however exhibit some shortfalls in ease of configuration and failover. However, there appear to be cases of "involuntary" applications level devices such as proxies that grab and modify HTTP traffic without using the appropriate mechanisms, sometimes known as "transparent caches", or mail relays that purport to remove undesirable words. These devices are by definition not transparent, and may have totally unforeseeable side effects. (A possible conclusion is that even for non-store-and-forward protocols, a generic diversion mechanism analogous to the MX record would be of benefit. The SRV record [RFC 2052] is a step in this direction.) """ And the extended discussion in <https://www.rfc-editor.org/rfc/rfc4924.txt> is topical as well. Cheers, > On 29 Jan 2015, at 3:01 pm, Noah Mendelsohn <nrm@arcanedomain.com> wrote: > > I strongly agree. See my post from earlier today [1], which I think is pretty much aligned with what you've just written, Tim. > > > This community should move from crystal-ball gazing as to how courts > > might interpret laws and regulations which are out there > > toward defining a protocol, where > > necessary including policy pieces as well as the technical bits. > > Yes. I do wish it were clearer from the RFCs that inserting adds violates the technical bits of the protocol. However, the provision for transforming proxies makes that a bit unclear to me. > > Do we have a clear answer on the technical bits: does insertion of an advertisement violate the technical specifications for HTTP? If so, where is the pertinent specification text? Thanks! > > As you say, we could also deal with this as a "policy piece" instead or in addition. > > Noah > > [1] http://lists.w3.org/Archives/Public/www-tag/2015Jan/0199.html > > On 1/28/2015 7:34 PM, Tim Berners-Lee wrote: >> >> On 2015-01 -28, at 17:48, Eric J. Bowman <eric@bisonsystems.net >> <mailto:eric@bisonsystems.net>> wrote: >> >>>> >>>> I pointed out that outright ad-replacement was considered by some as >>>> theft-of-revenue. I hope we can agree on that. >>>> >>> >>> I can agree if we're sharing an opinion. As a fact, I must disagree as >>> it hasn't been adjudicated, and I am not in posession of any crystal >>> ball showing me what the courts must certainly find if it were to be >>> adjudicated. As more years pass without adjudication of this issue, it >>> becomes harder to rule against, if the defense is established custom and >>> practice. >>> >> >> >> This community should move from crystal-ball gazing as to how courts >> might interpret laws and regulations which are out there toward defining a >> protocol, where >> necessary including policy pieces as well as the technical bits. >> So for example, along with the TCP protocol that a byte stream is broken up >> into packets, routed, retransmitted, and reorganized into the original >> stream byte for byte, >> we now need a legal corollary that anyone who breaks the protocol as part >> of any nefarious >> commercial scheme is breaking the law. "Code is law" in that it determines >> the way people >> interact much like law, but also Law is Code, in that it is part of the >> system design and also needs to be got right and >> worked out in mailing lists and github. We need to work more closely with >> people who make laws. >> >> Just as Larry Lessig points out (I hope I attribute this right) that there >> is no justice in >> obeying unjust laws, so maybe the corollary to that is that there is >> injustice in breaking >> things which ought to be laws even though they are not (yet). So if you >> are working for >> a project which injects javascript into hotel user's web pages, think >> about pushing back >> on the project or finding a better job. >> >> Jus sayin. >> >> Tim >> >> Director hat off but not far away >> > -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 29 January 2015 05:47:21 UTC