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

Re: Insertion of adverisements

From: Alex Russell <slightlyoff@google.com>
Date: Mon, 2 Feb 2015 18:10:39 +0000
Message-ID: <CANr5HFVfPN5vE5hd9oMUO=_6hPBVG8E5+hCtYL+La1-Oyu=ZBw@mail.gmail.com>
To: Noah Mendelsohn <nrm@arcanedomain.com>
Cc: Daniel Appelquist <appelquist@gmail.com>, TAG List <www-tag@w3.org>
On Mon, Feb 2, 2015 at 5:49 PM, Noah Mendelsohn <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
>>
>> …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> 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
>>>
>>>
>>
>
Received on Monday, 2 February 2015 18:11:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 February 2015 18:11:37 UTC