Re: Insertion of adverisements

Yeah, not a great story, but I think you have it about right.

Noah

On 2/15/2015 5:35 PM, Mark Nottingham wrote:
> Reverse proxies act with the authority of (and at the pleasure of) the origin server; they're fundamentally technically limited.
>
> Unfortunately, the same can't be said of "forward" proxies.
>
> In HTTP, the only kind of "forward" proxy that is explicitly nominated is one that's configured by the user. That's not technically enforced for HTTP, however, and it's turned out that it's far more efficient/workable to interpose a proxy in lower-layer protocols ("interception proxying").
>
> So I think the rub here is obtaining that express authorisation from the client.
>
> * If someone buries that authorisation in a contract T&C that no-one reads, is that "express authorisation"?
>
> * If it's in a 20-character wide, 5 character high <textarea> that passes by when you click through a captive portal (also not accommodated by the standards, btw), is that OK?
>
> * Or in your employment / education / incarceration contract (or perhaps an amendment to it that came about after you signed up and buried on some intranet site, or in some HR person's filing cabinet)?
>
> * What about when it's enshrined in law?
>
> Those are pretty much the mechanisms we have right now, and they're pretty widely deployed.
>
> The most obvious way to prevent unwanted intermediation is using HTTPS. However, there are also a number of ways that HTTPS can be changed from a two-party to a three-party protocol, and they're growing in prevalence. I'll start a separate thread about that.
>
> Cheers,
>
>
>
>> On 3 Feb 2015, at 8:08 am, Noah Mendelsohn <nrm@arcanedomain.com> wrote:
>>
>> I agree, the word proxy raises issues that I did not consider properly. The SOAP term "intermediary" is more neutral, since it carries no implication of acting on behalf of one of the endpoints. Indeed, I think that anyone inserting advertisements without express authorization from the survey authority or the consuming user is a proxy for neither, even if the technical specifications to which they appeal are those for Web proxies.
>>
>> Perhaps one way to skin this is to note that:
>>
>> * The HTTP specifications provide for "proxies", which act on behalf of the client. There are also "reverse proxies" acting on behalf of servers.
>>
>> * We note that it is possible to deploy intermediary software and/or hardware that conforms to the technical specifications for such proxies (e.g. in the ways that headers are content are manipulated) but that in fact are not acting on behalf of either server or client. The TAG believes that.....(PUT HERE WHATEVER YOU THINK IS THE RIGHT POLICY REGARDING SUCH INTERMEDIARIES...E.G. THAT THEY ARE CONTRARY TO WEB ARCHITECTURE, THAT THEY ARE A GOOD THING IN SOME CASES, WHATEVER.)
>>
>> Noah
>>
>> On 2/2/2015 1:10 PM, Alex Russell wrote:
>>> On Mon, Feb 2, 2015 at 5:49 PM, Noah Mendelsohn <nrm@arcanedomain.com
>>> <mailto:nrm@arcanedomain.com>> wrote:
>>>
>>>     Thank you! A minor quibble would be that the wiki name
>>>     HTTPS-and-Advertising seems to scope the discussion to a particular
>>>     item in a possible threat matrix rather than to the deeper set of
>>>     issues which seem to be along the lines of:
>>>
>>>     * What sorts of content manipulation by proxies should be appropriate,
>>>     and when?
>>>
>>>
>>> The word "proxy" blurs the lines of authority. This, to me, seems to be
>>> related to "which set of parties which are implicitly trusted should be
>>> allowed to violate the end-to-end principle?"
>>>
>>> ISTM that framing this in terms of "active" and "passive" parties to the
>>> transaction clarifies intent in a network composed of endpoint owners and
>>> transit providers. That there are some transit providers that are also
>>> endpoint owners helps make more sense of cases like businesses that have
>>> proxies but also root the client.
>>>
>>>     * What is the correct role for possible more widespread deployment of
>>>     TLS (or other encryption/signature technology) in limiting the ability
>>>     of proxies to inappropriately modify content?
>>>
>>>
>>> I like this framing a lot.
>>>
>>>     * To what extent would that more widespread deployment of TLS also
>>>     hamper more legitimate modification of content by proxies (if any such
>>>     modification is legitimate)?
>>>
>>>
>>> Phrasing this in terms of "endpoint owners" and "transit providers" makes
>>> that distinction clearer to me.
>>>
>>>     * To what degree will more widespread deployment of TLS cause those who
>>>     run proxies to inappropriately spoof certificates in an effort to
>>>     retain their ability to modify content?
>>>
>>>     I may not have the above exactly right, but scoping only to advertising
>>>     seems a bit off the mark. I do realize that my retitling of the e-mail
>>>     thread did use the word "advertisements", so possibly the problem
>>>     traces to me.
>>>
>>>     Thank you again for acting on my concerns!
>>>
>>>     Noah
>>>
>>>     On 2/2/2015 11:41 AM, Daniel Appelquist wrote:
>>>
>>>         Thanks, Noah.
>>>
>>>         I agree this is an area that needs more scrutiny. In my discussions
>>>         web developers this issue comes up again and again. I have created
>>>         a wiki page here:
>>>
>>>         https://github.com/w3ctag/__wiki/wiki/HTTPS-and-__Advertising
>>>         <https://github.com/w3ctag/wiki/wiki/HTTPS-and-Advertising>
>>>
>>>         …where we can hopefully collect some of the issues and see if there
>>>         is scope for a future TAG deliverable on this topic.
>>>
>>>         I will send this URL out to some of the web community members who
>>>         have engaged me on this topic so we can hopefully bring some
>>>         real-world feedback to this discussion.
>>>
>>>         Thanks,
>>>         Dan
>>>
>>>             On 28 Jan 2015, at 18:05, Noah Mendelsohn <nrm@arcanedomain.com
>>>             <mailto:nrm@arcanedomain.com>> wrote:
>>>
>>>             Whatever the other issues, I think it would be good for the TAG
>>>             to focus particularly on the importance of complying with
>>>             specifications.
>>>
>>>             The specifications for HTTP and associated supporting protocols
>>>             (TCP etc.) either do or do not make clear whether insertion of
>>>             advertisements is conformant with the specifications. I would
>>>             like to believe that such content alteration is non-conforming,
>>>             but HTTP does allow for some transformations, and provides a
>>>             header to prohibit such transformations being done [1]. In any
>>>             case, I will leave it to others who are more expert in HTTP to
>>>             decide whether insertion of advertisements is or is not
>>>             conforming to the pertinent specifications.
>>>
>>>             I'm suggesting that the TAG's analysis (if any) should start
>>>             with that question, though I can see the TAG going further to
>>>             discuss other questions relating to ad insertion as well.
>>>
>>>             Noah
>>>
>>>             [1] http://tools.ietf.org/html/__rfc2616#section-14.9.5
>>>             <http://tools.ietf.org/html/rfc2616#section-14.9.5>
>>>
>>>
>>>
>>>
>>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

Received on Monday, 16 February 2015 00:47:32 UTC