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