Subject: Content Provider Notification

From: Markus Hofmann <[email-masked]>
Date: Tue, 04 Jun 2002 13:41:10 -0400

Hi,

in a previous email exchange on this list concerning the IAB 
consideration (3.1) about notification to content providers, I 
somewhere typed the following:

 >> (3.1) Notification: The overall OPES framework needs to assist
 >> content providers in detecting and responding to client-centric
 >> actions by OPES intermediaries that are deemed inappropriate by
 >> the content provider.
 >
 > Section 2.6 of the draft should extend to include some form of
 > notification of the OPES action to the originating party *when
 > requested* by the originating party. Implicit notification
 > mechanisms would not scale, but a content provider should be able
 > to explicitly request notification in some form.

In discussing this issue with others, the question arised whether the 
capability of requesting such notification might eventually violate 
the privacy of a content consumer/client, since it would allow a 
CONTENT PROVIDER to find out about CLIENT-CENTRIC actions.

Such notification might eventually reveal private information the 
client does not necessarily want to share with a content provider, for 
example the client's prefered language (revealed by a language 
translation service). Or what about a scenario in which the client 
browses the Web through an anonymizing proxy, but the client-centric 
service is provided on an OPES box sitting between the client and the 
anonymizing proxy? Normally, the content provider would only see the 
IP address of the anonymizing proxy, but with requested OPES 
notifiactions he/she would eventually find out about the OPES box 
sitting close to the client, thus eventually allowing him/her to 
figure out the client's ISP and such like. Other scenarios are thinkable.

Any thoughts on that? How should this be adressed? Does this rule out 
direct notification of CLIENT-CENTRIC actions to the CONTENT-PROVIDER, 
or would the benefits of such notifications outweight the privacy 
concerns? Might indirect notification by the client (based on OPES 
tracing information) be acceptable, i.e. bringing the client back into 
the notifiaction loop? Does the client have a right to veto direct 
notification?

-Markus

---

From: John Morris <[email-masked]>
Date: Tue, 4 Jun 2002 15:34:51 -0400

At 1:41 PM -0400 6/4/02, Markus Hofmann wrote:
><snip>
>In discussing this issue with others, the question arised whether 
>the capability of requesting such notification might eventually 
>violate the privacy of a content consumer/client, since it would 
>allow a CONTENT PROVIDER to find out about CLIENT-CENTRIC actions.
>
><snip>
>Any thoughts on that? How should this be adressed? Does this rule 
>out direct notification of CLIENT-CENTRIC actions to the 
>CONTENT-PROVIDER, or would the benefits of such notifications 
>outweight the privacy concerns? Might indirect notification by the 
>client (based on OPES tracing information) be acceptable, i.e. 
>bringing the client back into the notifiaction loop? Does the client 
>have a right to veto direct notification?
>
>-Markus

Markus,

The privacy concern you raise is a very real and very challenging 
one.  I think that the IAB properly placed a great value in 
transparency (motivated, in part, to protect users' privacy by 
telling users who has access to their information).  But in some 
situations transparency can harm privacy and anonymity.  I do not 
think that there is any easy answer that can fully protect the rights 
of all concerned.

I set out below a middle ground approach that strikes me as a 
reasonable compromise.  But before getting to it, let me respond to 
an earlier question raised by Eric Burger:

At 1:30 PM -0400 6/3/02, Eric Burger wrote:
>Hmmm.
>
>Does this mean that a source can block ANY transformation?  The concept
>"breaks" the Internet model of "bits are bits".  The good news is that it is
>impossible to enforce such a request.  An end-point is an end-point.  Unless
>we go the way of the DMCA and end up pressuring hardware manufacturers to
>physically block the execution of transformation code...
>
><snip>
>
>Given the impossibility of enforcing a "do not OPES" indicator, but there
>being some utility of requesting "no OPES, please", can we make this an
>informational indicator, if we need it at all?

My answer to Eric is that I don't think he and I disagree about what 
is reasonably plausible to implement -- a source will not be able to 
"enforce" a "do not OPES" flag.  But the term "informational 
indicator" suggests, to me, a bit of information that is largely 
ignored downstream.  Here, I believe that an OPES dispatcher should 
look for and honor a "do not OPES" instruction.

To avoid getting a "do not OPES" instruction, a user/client might 
well be willing to tell the server what OPES transformation the 
client wants to do, and the server might then permit the 
transformation.  As a hypothetical, if a publisher wants to block 
OPES transformations of its content into a compact wireless format 
(because the publisher offers a separate wireless service, for 
example), the publisher may well not have any problem with an OPES 
service that translates (at the request of a German-speaking human 
client) all content into German.

BUT, a client-to-server notification of proposed OPES transformations 
can raise the exact privacy problem that Markus identified.

An approach that gives some (but not all) protection to both sides would be:

1.  OPES defaults to provide client-to-server notification of 
proposed OPES transformations.
2.  A client can change the default and thus block the notification.
3.  A server can issue a general "do not OPES" instruction, which a 
properly implemented OPES dispatcher would honor.  Thus, while a 
client could block client-to-server notification, the server could 
block all OPES transformations.

This approach would allow the client control over his or her privacy 
and/or anonymity, but at the potential cost of (a) losing access to 
certain information, or (b) only getting access to the information in 
an untransformed way.

To be clear, the suggested approach is NOT symmetric.  I would 
support giving the client the option to block client-to-server 
notification, but I think that server-to-client notification should 
be mandatory (assuming the OPES dispatcher or OPES service provider 
is an entity other than the server itself).  This asymmetry seems 
appropriate because, in the end, the server typically holds all of 
the cards (in the form of holding some requested information) and 
commonly the client is the entity that needs greater protection.

But, to loop back, the privacy/anonymity implications of the 
client-to-server notification raises tough questions.

John

--------------------------------------------------
John Morris // CDT // http://www.cdt.org/standards
--------------------------------------------------

---

From: "The Purple Streak (Hilarie Orman)" <[email-masked]>
Date: Tue, 04 Jun 2002 18:46:12 -0600

I suppose the content could be marked with an advisory to the
content consumer's software - the advisory being "upon reading,
mail or POST the OPES headers to the content provider."  That's about
the only reasonable way I can see to provide strong forms of
notification while still giving the content consumer some control.
But the content provider just isn't going to want to be bombarded
with all these notifications, and if notifications were a default
requirement, it would be crippling.  The providers would need
a detailed way of specifying which kinds of OPES services or which
OPES service providers did or did not have to provide notifications.
Which gets back to the inline policy specification and validation
methods of my paper of last year.  It's a heavyweight solution, done
to show that these problems have solutions, but at a cost.  And it
is clearly outside what the working group wants to do.

The mechanisms for notification would be complicated, as they cannot
follow the content path.  They must be the same for both endpoints
(because both the request and the response can be part of OPES
processing), and they must handle the case of intermediate content
providers (consider a personalization service contracted for by the
content provider; if the content consumer's personalization service
conflicted with it, the personalization service provider must be
notified).  How can one relate the notification to the request that
ocassioned it?  In the case of a caching proxy, the content provider
would not have seen the request, and the notification of an OPES
service would not be related to any activity seen by the provider or
his contracted services.

In short, I do not see how to design a meaningful notification service
that suits anyone's purposes within the current working group's
talents and desires.  And there's no point in saying "no notification"
if we haven't got a notification service.  So there's no impact
on the architecture.

I suggest we put this issue aside for the time being.  It has been
considered, it is very difficult, and it can be a topic for a later
encharterment.

Hilarie

John Morris wrote:

> The privacy concern you raise is a very real and very challenging one.  
> I think that the IAB properly placed a great value in transparency 
> (motivated, in part, to protect users' privacy by telling users who has 
> access to their information).  But in some situations transparency can 
> harm privacy and anonymity.  I do not think that there is any easy 
> answer that can fully protect the rights of all concerned.
> 
> I set out below a middle ground approach that strikes me as a reasonable 
> compromise.  But before getting to it, let me respond to an earlier 
> question raised by Eric Burger:
> 
> 
> My answer to Eric is that I don't think he and I disagree about what is 
> reasonably plausible to implement -- a source will not be able to 
> "enforce" a "do not OPES" flag.  But the term "informational indicator" 
> suggests, to me, a bit of information that is largely ignored 
> downstream.  Here, I believe that an OPES dispatcher should look for and 
> honor a "do not OPES" instruction.
> 
> To avoid getting a "do not OPES" instruction, a user/client might well 
> be willing to tell the server what OPES transformation the client wants 
> to do, and the server might then permit the transformation.  As a 
> hypothetical, if a publisher wants to block OPES transformations of its 
> content into a compact wireless format (because the publisher offers a 
> separate wireless service, for example), the publisher may well not have 
> any problem with an OPES service that translates (at the request of a 
> German-speaking human client) all content into German.
> 
> 1.  OPES defaults to provide client-to-server notification of proposed 
> OPES transformations.
> properly implemented OPES dispatcher would honor.  Thus, while a client 
> could block client-to-server notification, the server could block all 
> OPES transformations.
> 
> certain information, or (b) only getting access to the information in an 
> untransformed way.
> 
> To be clear, the suggested approach is NOT symmetric.  I would support 
> giving the client the option to block client-to-server notification, but 
> I think that server-to-client notification should be mandatory (assuming 
> the OPES dispatcher or OPES service provider is an entity other than the 
> server itself).  This asymmetry seems appropriate because, in the end, 
> the server typically holds all of the cards (in the form of holding some 
> requested information) and commonly the client is the entity that needs 
> greater protection.
>

---

From: "Oskar Batuner" <[email-masked]>
Date: Wed, 5 Jun 2002 16:36:56 -0400

This issue comes to question - who has the final authority on what.
Authority domains should be divided between server's origin of authority and
client's origin of authority. None may have an absolute authority over all
OPES servers in the delivery path.

An example: virus checking. If the server is able to issue some directive
like "no OPES action" which disables all OPES intermediaries - any malicious
life form that takes control over the server may just defeat all antivirus
security.

Filters also may be made vulnerable to adaptive attack by probing using
trace/report facilities.

I think this also answers to the Markus question:

>Any thoughts on that? How should this be addressed? Does this rule out
>the notification loop? Does the client have a right to veto direct
>notification?

There are cases like those above where we have conflict of interests between
content provider and content consumer. Such conflict undermines the
 "benefit" approach - each side may have different understanding of
benefits.

I'd suggest limiting any MUST-level requirements in tracing/reporting
mechanism by appropriate authoritative domain ("color" in the architecture
draft terminology). Client definitely should have the veto right in it's
domain, otherwise it can not rely on certain types of legitimate OPES
services.

I do agree with Hilarie that detailed specification of this mechanism may be
delayed. Such a mechanism may be subject of a separate draft. But the
architecture draft should set the general framework and requirements for the
tracing/reporting.

Oskar

---

From: John Morris <[email-masked]>
Date: Wed, 05 Jun 2002 15:26:25 -0400

Some comments inline.....

At 06:46 PM 6/4/02 -0600, The Purple Streak (Hilarie Orman) wrote:

>requirement, it would be crippling.

Wouldn't client-to-server notice transmitted as part of the initial request 
to the server provide the server with some notice without creating a flurry 
of after-the-fact notifications?

>   The providers would need

Although it is clearly a non-trivial task, I expect that some time of 
description method will in the end be a necessary part of OPES.

>service would not be related to any activity seen by the provider or

Let me float a simpler and still plausible approach:

1.  By default, no client-to-server notice is necessary.
2.  For the limited number of servers that care, they can send out an "are 
you planning to OPES" inquiry before filling the client's request.
3.  The client side OPES operator would be able to respond to the inquiry 
in the hope of satisfying whatever concern the server might have,  UNLESS 
in initially requesting the service from the OPES provider the client said 
"do not give notice to the server."

>considered, it is very difficult, and it can be a topic for a later

It strikes me that there are at least some questions that can and should be 
answered now, such as whether the protocol will honor a "do not OPES" flag.

John

>>>capability of requesting such notification might eventually violate the 
>>>privacy of a content consumer/client, since it would allow a CONTENT 
>>>PROVIDER to find out about CLIENT-CENTRIC actions.
>>>
>>><snip>
>>harm privacy and anonymity.  I do not think that there is any easy answer 
>>that can fully protect the rights of all concerned.
>>To avoid getting a "do not OPES" instruction, a user/client might well be 
>>willing to tell the server what OPES transformation the client wants to 
>>do, and the server might then permit the transformation.  As a 
>>BUT, a client-to-server notification of proposed OPES transformations can 
>>raise the exact privacy problem that Markus identified.

---

From: "Oskar Batuner" <[email-masked]>
Date: Thu, 6 Jun 2002 00:44:06 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of John Morris
> Sent: Wednesday, June 05, 2002 3:26 PM
> To: The Purple Streak (Hilarie Orman)
> Cc: OPES Group
> Subject: Re: Content Provider Notification
>
>
>
[..............}

> "do not give notice to the server."

This mode of operation requires all participants to be OPES-enabled, very
strict limitation. If in response to request from the standard
browser comes inquiry (2) - well, this just means that the server
breaks HTTP and browser may behave unpredictably.

I think the same goal may be achieved (even more efficiently) by adding to
the request coming through the OPES proxy an additional header - OPES
advertisement (again, if permitted/instructed by the end user). Non-OPES
enabled server will simply ignore this additional header; OPES-enabled one
may add some instructions to the response.

As a side effect I'd suggest to add an explicit architectural requirement
that the presence of OPES server in the dataflow SHALL NOT disrupt
operations of non-OPES aware clients and servers. OPES server, content
server and content consumer MAY use OPES extensions to the base protocol
(HTTP), but support of these extensions SHALL NOT be required.

Oskar

---

From: "The Purple Streak (Hilarie Orman)" <[email-masked]>
Date: Wed, 05 Jun 2002 23:11:32 -0600

My comments are inline headed by [HKO].

>>At 06:46 PM 6/4/02 -0600, The Purple Streak (Hilarie Orman) wrote:

[HKO] Reading the IAB considerations carefully, and noting that the
content provider is only interested in corrupted or malicious OPES
services, one finds that this would not be a limited number of servers,
it would probably be almost all servers.  Also, as an aside, note that
this inquiry itself could be implemented as an OPES service by a
content distributor.

[HKO] Further, the OPES intermediary will not, in general, forward
every request for a particular piece of content back to the content
provider.  Thus, the best that could be done is for the content to
contain some header saying "please notify me each time you serve this
content with an OPES service applied", because in general, whether or
not an OPES service is applied will depend on some attributes particular
to the requestor.

> may add some instructions to the response.

[HKO] But in general, the decision about applying an OPES service will
not be made until the content arrives at the OPES box, so the
notification cannot travel with the request.  I suppose all potential
OPES services could be listed in the request, but that seems unscalable
because it discourages adminstrators from installing services - they
cause request bloat.

> (HTTP), but support of these extensions SHALL NOT be required.

If you can amplify "disrupt" reasonably I'd probably agree with this
suggestion.

Hilarie

---

From: "Oskar Batuner" <[email-masked]>
Date: Thu, 6 Jun 2002 19:51:09 -0400

On OPES advertisement/notification headers:

The main idea is to let the content server know that
there is an OPES entity in the dataflow path. Adding
an "existence and capabilities" notification to request
or response does not replace tracing and reporting
mechanism, it just supplements it and helps to overcome
limitations imposed by "don't break end-to-end HTTP" rule.

If such notification is present it SHALL include:
a) OPES protocol extensions level supported, including
tracing and reporting support available;
b) method to be used by the content server to communicate
with OPES server - OPES extensions to base protocol or
out-of-band. In the latter case OPES server address
MUST be included.

It MAY also include:

c) OPES server origin-of-authority address (if one is different
from the OPES server itself and the OPES server is willing to
expose one). This may be useful for out-of-band negotiations
(for example getting/checking authorization for certain actions
or signing up for pay-per-use services);
d) services or classes of services available.

I don't think such notification creates a scalability
problem - number of OPES servers in a particular dataflow is
very limited. The main goal of notification is not to advertise
all available services or their classes (though this also may
be feasible in some cases) but to declare willingness of the
OPES server to disclose its presence and negotiate services
(including tracing and reporting) with the content server
or user agent.

Oskar

> [mailto:[email-masked]]On Behalf Of The Purple Streak
> (Hilarie Orman)
> Sent: Thursday, June 06, 2002 1:12 AM
> To: OPES Group

---

From: "The Purple Streak (Hilarie Orman)" <[email-masked]>
Date: Thu, 06 Jun 2002 18:00:53 -0600

> out-of-band. In the latter case OPES server address

[HKO] This implies that there is a new communication protocol and
that the OPES server MUST be directly addressable from outside
the content path.  That opens a security hole for DOS attacks
that didn't have to be there before.

> or signing up for pay-per-use services);

[HKO] Signing up for services is not part of the OPES callout or
tracing protocol.  The architecture specifies this as a separate
function.  I don't see how an SOA in a request helps the process.

> d) services or classes of services available.

[HKO] Do you mean "available" or "might be applied sometime to the 
result of this request"?  What about subsequent requests for the
same content, requests that do not go to the origin server?  If
the OPES data processor changes it policies, must it notify all
origin servers for which it holds cached data of the changes?

> (including tracing and reporting) with the content server

[HKO] This extra negotiation seems to be a needless complication.

Hilarie

>>>>3.  The client side OPES operator would be able to respond to
>>>>
>>the inquiry
>>
>>>>in the hope of satisfying whatever concern the server might
>>>>
>>have,  UNLESS
>>
>>>This mode of operation requires all participants to be
>>>
>>OPES-enabled, very
>>
>>>I think the same goal may be achieved (even more efficiently)
>>>
>>by adding to
>>
>>>enabled server will simply ignore this additional header;
>>>
>>OPES-enabled one
>>
>>>As a side effect I'd suggest to add an explicit architectural
>>>
>>requirement
>>

---

From: "Oskar Batuner" <[email-masked]>
Date: Thu, 6 Jun 2002 23:21:47 -0400

> Sent: Thursday, June 06, 2002 8:01 PM
> Cc: OPES Group

I'm afraid this is not exactly correct, see draft p.9: 

"One of those annotations could be a URL with more detailed
information on the transformation that occurred to the data 
on the OPES flow."  

I do not see an additional risk in both cases: If I understand 
correctly the architecture statements (like Figure 1) - OPES 
works over TCP/IP connection that terminates at OPES entity. 
This means that the entity's IP is already exposed. Explicit 
declaration just removes dependency from the underlying 
protocol and points to the address that OPES entity wants to 
use for communication. Very convenient for legitimate usage 
(may be different from the connection IP) but not essential for 
attackers - they may use IP anyway.

As for adding out-of-band capabilities - you are right about 
complexity that comes with them, but satisfying all OPES 
requirements in-band may also be tricky. It may result in 
unnecessary growth of OPES-related information added to each 
message - in-band channel may be closed after any 
request/response exchange and there will be no second 
chance to ask questions.

> function.  I don't see how an SOA in a request helps the process.

Let's suppose some service requires authorization for usage or 
control. Content server (or user agent) may go to the SOA 
server and get an authorization. How this is done is outside 
of OPES architecture. But then this authorization will be 
included into all (restricted) instructions to the OPES 
server - probably using OPES extension to the base 
protocol.   

> origin servers for which it holds cached data of the changes?

I mean "available in general". As you've pointed out earlier 
it may be not possible to determine what rules will be applied 
without analyzing the response, and I do not propose notifying 
server of all possible variations.

The goal is to give the server (or user agent) a possibility to 
add some advise/instructions related to the specific service 
class. Some (naive) examples are:

"I'm a translation service" - "Include original text with 
translation"

"I'm going to insert regional ads" - "Sports related will 
work best with this content"

Due to the generic nature of such instructions they remain 
valid for subsequent requests for the same content, change 
of OPES policy just affects the way instructions are applied. 
 
> [HKO] This extra negotiation seems to be a needless complication.

Sorry, maybe I've used a wrong word. Here by negotiations I mean 
willingness to take into account OPES-related instructions/advice 
from the server or user agent and ability to satisfy inquiries 
like those proposed by John Morris. BTW such inquiry is a good 
candidate for out-of-band communications.

Oskar