Subject: on OPES

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jun 2001 14:00:15 -0400

I think it comes down to this:

If OPES is building a standard interface which allows a content-provider 
a lot of flexibility in implementing *its own services*, and/or allows a user
a lot of flexibility in adapting content to his own needs, that's 
probably a good thing.

If on the other hand OPES is building an interface which allows a third 
party to modify content that is obtained from other information providers, 
I don't see any way that IETF should support it.  Even requiring consent is 
not enough if the user or provider can be coerced into providing that consent.

When OPES proponents gloss over the difference between these it doesn't
give me confidence that they can be trusted to develop appropriate protocol 
mechanisms to deter abuse, much less recommend policy for the use of OPES.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 22 Jun 2001 13:42:44 -0700

Keith Moore wrote:
> ... allows a content-provider a lot of flexibility in implementing
> *its own services* ...

I don't buy this one. While minimizing the differences between
implementations may increase flexibility somewhat, I don't hear the market
screaming that the existing tools for content customization are inadequate.

> ... allows a user a lot of flexibility in adapting content to
> his own needs ...

> ... allows a third party to modify content that is obtained
> from other information providers ...

I don't see how you can tell the difference given that the 'user' will be
delegating the adaptation task to a program (read that 'third party'). Since
there is no way for an interface standard to tell if the man-in-the-middle
here is an application on the user's pda or some upstream 'transparent'
service, you have to say no. Even if you require a certificate as part of
the process to distinguish that it is the pda sending the message, any other
app on that device could be driving the customization app to cause
'authorized' changes.

Getting back to Valdis's example, if I were sitting at GM the first thing I
would do is give away through ZD-downloads an easily customized java applet
that would provide an eye-catching pop-up ad (or swimsuit calendar), while
in the background causing the device it is running on to tell every OPES
server it knows about to rewrite all occurrences of Ford with GM. Since the
authorizations would be coming from the endpoints as 'local customization'
commands, it would be a cheap way to redirect the target audience with no
easy way for those taking advantage of the free applet or the browsing end
user to correlate the events. While this can probably be done already, the
thing that currently prevents widespread abuse is the lack of a standard way
to hack the various proxies.

Why does anyone believe that the IETF should be the one to endorse something
with this potential for abuse? If other standards bodies want that
privilege, let them have it. We can still issue an informational RFC on the
hazards of the approach. When the press goes looking for someone to blame
for shortsightedness of this brain-dead concept just make sure they are
looking elsewhere.

Tony