Re: Content Provider Notification

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:

> 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
> --------------------------------------------------