ietf-openproxy
[Top] [All Lists]

Re: CDT Comments on OPES

2001-08-09 14:42:56

OPES will increase the integrity of content delivery over what is
available today.  

It is of only academic interest to contrast
a pure end-to-end world against a world with OPES.  As another
purely academic exercise, contrast a pure voice switching
model against the Internet.  The Internet offers many opportunities
for traffic monitoring, substitution, and malicious intervention that
the phone system did and does not.  Whether or not the benefits 
outweighed the risks was not evident a priori; in the case of OPES,
you cannot make such an evaluation simply by pointing out risks
that are already there without OPES and claiming that OPES somehow
makes them worse.

Hilarie Orman

John Morris <jmorris(_at_)cdt(_dot_)org> 08/09/01 02:56PM >>>

FYI, below are comments circulated a few days ago to the IESG, providing a 
public policy perspective on some of the issues raised by the OPES working 
group proposal.  Many of the issues discussed have been discussed on this 
list and/or the IETF list; some are addressed in the current charter draft, 
while others are not.  Whether or not the IETF working group is 
established, I am hopeful that these comments can make a constructive 
contribution to the discussion of the proposed OPES tools.  John Morris

----------------------------------------
John B. Morris, Jr.
Director, Internet Standards, Technology
& Policy Project
Center for Democracy and Technology
1634 I Street NW, Suite 1100
Washington, DC 20006
(202) 637-9800
(202) 637-0968 fax
jmorris(_at_)cdt(_dot_)org 
http://www.cdt.org 
----------------------------------------

1.0 Summary

We write to outline serious policy concerns raised by the proposal that the 
IETF/IESG create a working group on "Open Pluggable Edge Services" (OPES).

As outlined below, OPES would further diminish the "end to end" principles 
that have been so important to the development of the Internet.  OPES would 
reduce both the integrity, and the perception of integrity, of 
communications over the Internet, and would significantly increase 
uncertainly about what might have been done to content as it moved through 
the network.  OPES would also increase the risk that ISPs can exercise 
bottleneck control over users' access to the Internet, and could favor 
certain content and application providers over others.

On the threshold question of whether the IETF should sponsor and sanction 
the proposed OPES working group, we believe that the risks of OPES outweigh 
the benefits of IETF review and control.  In the event that the IESG 
approves the creation of the OPES working group, we suggest below a set of 
requirements for OPES that would mitigate policy concerns.

2.0 Background

The Center for Democracy and Technology first became aware of the OPES 
proposals through the work of its newly created Internet Standards, 
Technology & Policy Project [see http://www.cdt.org/standards/]. (The 
comments below are submitted on behalf of CDT, and not the Project 
participants.) CDT is a nonprofit public interest group that promotes civil 
liberties and democratic values online. CDT has over the years been very 
involved in protecting free speech, privacy, and openness on the Internet, 
and these comments reflect those public policy goals.


3.0 Concerns Raised by OPES

3.1 Content Manipulation, Free Expression, and Privacy

OPES would significantly increase the risk of unauthorized interference 
with or manipulation of communications as they traverse the Internet.  OPES 
would diminish end to end network design principles and facilitate 
third-party alteration of, or action based on, communications without the 
notice or consent of end point parties. As such it creates major concerns 
for free expression and privacy online.

The one party consent model defined in the proposed charter poses a threat 
to the model of trust built into the end to end model, as well as allowing 
third parties to interfere with the free flow of information that has 
become a hallmark of Internet communication. For example, OPES could 
facilitate third-party or state-sponsored censorship of Internet content 
without the knowledge or consent of end users; OPES could also facilitate 
third-party manipulation of content for commercial purposes (such as 
advertising) without the consent of the end parties.  OPES could also 
facilitate surveillance systems like Carnivore, risking individual privacy 
and discouraging unpopular expression on the web.  Those who wish to 
publish content with complete integrity may be forced to use end-to-end 
encryption of communications, raising barriers to entry in the cost of 
publishing and decreasing potential benefits of caching.

Undeniably, as proposed, OPES would require the consent of either the 
sender or receiver.  Also undeniably, the IETF process would likely ensure 
that this and other security and privacy concerns would be honored in a 
proper implementation of OPES.

At bottom, however, OPES is not a protocol for communications between 
computers or networks, but rather is a self-contained facility to 
manipulate content.  The core functions of OPES (rule-based review of 
content, diversion of selected content, and execution of proxylets or other 
content manipulations) can be implemented entirely within one server (or 
linked servers).  There is no fundamental need that certain protections and 
guidelines be followed to, for example, ensure interoperability among 
networks.  It appears unlikely that meaningful security and validation 
requirements could be made to be so integral to OPES that such requirements 
could not be easily overridden within an individual implementation of OPES.

The wide proliferation of OPES implementations would, it seems, be likely 
to lead to the modification of such implementations to facilitate 
unauthorized manipulations of content.  The incentives for unauthorized 
manipulations are clearly present on the Internet, and OPES would make such 
improper actions easier to implement.  Just very recently we have seen 
examples of largely unauthorized manipulation of content for marketing 
purposes by third parties.  [See, e.g., 
http://slashdot.org/features/01/07/31/2015216.shtml or 
http://www.salon.com/tech/feature/2001/08/02/parasite_capital/index.ht 
ml].  OPES seems likely to facilitate such schemes.

3.2  Facilitating Gatekeepers

OPES could further promote the creation of bottleneck power in the hands of 
Internet Service Providers.  Over the past few years, the Internet has seen 
broadband ISPs move toward a business model of contracting with "preferred" 
content providers and facilitating the fast delivery of that content over 
competing, non-preferred content. OPES would significantly increase the 
potential of ISPs to enter into preferential or even exclusive contracts 
with service providers ("the exclusive language translation services 
offered to users of XYZ ISP").  These preferred and exclusive arrangements 
can serve to reduce innovation and competition for content and services on 
the Internet.  Although high bandwidth content is already subject to 
potential discrimination in delivery over some ISPs, OPES would likely 
increase such potential for discrimination among service providers.  This 
bottleneck and/or gatekeeper power raises serious public policy concerns.

3.3 Suggested Action

Ultimately, from a public policy perspective, we believe that the risks of 
OPES outweigh its undeniable potential benefits.  We understand that, in 
the absence of an IETF sanctioned implementation of OPES, the same 
capabilities are likely to be created elsewhere (through iCAP and other 
techniques).  It is our perception, however, that IETF sanction would 
further promote the acceptance and use of these techniques, and in turn 
that would lead to the significant risk of abuse.


4.0 Proposed OPES Policy Requirements

We fully appreciate that there is not a clear and obvious answer to the 
question of whether the IETF/IESG should create an OPES working group.  If 
such a working group is created, we would look forward to making a 
constructive contribution to that effort.  In such a context, we suggest 
that certain requirements be added to the OPES charter.  None of these 
safeguards would provide protection against non-complying implementations 
of OPES, but they would at least define the ground rules for proper 
implementations of OPES.  The requirements we would suggest are:

4.1 End Point Notice

A metatag indicating that some OPES manipulation has been performed on a 
given communication should be available to the end points of an 
exchange.  Concerned parties should also be notified as to the nature of 
the OPES service provided (thereby creating a nontrivial requirement of the 
creation of a vocabulary or taxonomy of OPES services, as discussed below). 
This full disclosure will be especially important if OPES services are used 
routinely and an object is manipulated in several different ways by a 
variety of services.

4.2 Consent

As the OPES proposals currently anticipate and require, no content should 
be subject to an OPES manipulation without the clear consent of either the 
sender or ultimate recipient of the communication.

4.3 End Point Veto

The consent of one party is not sufficient to protect the speech and 
privacy interests of all end point parties subject to OPES services. Both a 
sender and the ultimate recipient should be able to veto the use of OPES 
manipulation, through the use of (for example in the web context) 
metatags.  For example, a web user should be able to include a "no OPES" 
metatag in an initial http request, and the responding web site should 
honor that metatag (even if only by refusing the request as some web sites 
now do if cookies are not accepted - an unfortunate result but at least one 
that is honest).  Similarly, a web publisher should be able to include a 
"no OPES" tag that is honored by OPES servers later in the communication.

4.4 Other Goals - Privacy, Negotiation

PRIVACY:  Because there is unlikely to be an opportunity for a prior review 
(by the end user or the user's P3P agent) of the privacy policies of the 
OPES server (or a third party server called out by OPES), such OPES-related 
privacy policies should be reflected in the privacy policies of any content 
publisher who chooses to use OPES. Thus, publishers who wish to use OPES 
should take responsibility for the use or dissemination of information by 
an OPES service provider. We believe that addressing this need, or some 
direct and effective method that a user can interrogate the privacy policy 
of an OPES provider, should both be a part of OPES and should be included 
in revisions to the P3P specification.

NEGOTIATION: It would be desirable for all parties to have the ability to 
communicate their respective wishes regarding OEPS services to achieve some 
mutually satisfactory result.  Given that many OPES services may be 
performed on a given object, both parties should be able to decide which 
must be overridden.  For example, a web publisher might demand that the 
quality of her images are not downgraded by an OPES compression service, 
and a user may consent to a longer download time and bypass that OPES 
service for that particular image.  The same user might not agree to 
disable an OPES virus scan at the request of the content provider.

We recognize that such negotiation capability poses several large design 
problems and hence propose it as a goal to be explored rather than a 
requirement for moving forward.

5.0 Conclusion

We appreciate the opportunity to present our views on the OPES proposals, 
and we look forward to further contributing on this issue in appropriate 
venues.  For questions or further information about this document please 
feel free to contact John Morris <jmorris(_at_)cdt(_dot_)org> or Alan Davidson 
<abd(_at_)cdt(_dot_)org> at CDT. ##



<Prev in Thread] Current Thread [Next in Thread>