There are some good ideas in this trust discussion.
I think there's a fairly clear integrity model for packet delivery:
the network won't modify anything past the transport headers.
Packet deletion isn't modification. The network can copy,
misdeliver, and corrupt packets, but only insofar as the rate
is low and the effects pretty much uniformly distributed over
all users.
This is significantly weakened from the original concept,
which wouldn't have allowed NAT or related stuff, but
still, it's almost simple.
There's an implicit integrity model in the word "cache" that's
similar. Literally, caches don't modify content. But caching is only
part of a proxy or a surrogate or a content service node.
There's a more complicated model for "proxies", I claim. They
provide integrity on parts of the content (data, payload, etc.),
but they have application-level responsibilities to protect,
enhance, and add value to content. I think there's
a legitimate question here, about what integrity guarantees
can be expected. And I think it's difficult, but may worthwhile,
to draw up some guidelines. Things such as
By default, content integrity is assured.
Refusal to deliver content is not modification
Publishers and users should have clear ways of specifying
acceptable policies for content modification.
Users should have clear ways opting out of content
modification services.
The content should have an audit trail of modification
services applied end-to-end
Content services should not move data between
unrelated transactions
...
Hilarie
Donald Gillies <gillies(_at_)netapp(_dot_)com> 02/02/01 06:29PM >>>
People sometimes get worried about the trust model that governs the
web. well, it turns out that without the trust model for congestion
control, TCP and the entire internet would fail tomorrow.
ICAP cannot doing anything truly new; you could always in the past
pull a proxy skeleton core off the shelf and do what ICAP does. So,
the arguments about trust models and how to enforce trust models in
the fetch pipeline are kind of rendered impotent by this alternative.
Before we can argue about how to enforce trust models in a system
containing an ICAP device, it would be necessary for the proxy engine
cores to be banned as "controlled substances" by the DEA and licensed
& controlled as such.
ICAP will provide features that *control* and inter-operate with a
network cache so that ICAP + Network Cache can give you a huge bang
per dollar invested in ICAP server development. The idea is to pull
most of proxy and service-writer complexity into the cache, jack up
the performance, and allow ICAP applications to proliferate.
We can spend time writing trust guidelines for proxy service authors,
but I'd be reluctant because it doesn't seem like custom proxy-writers
are running amok right now.
Most of the things that can be done with ICAP can be done with local
applet, and I am not aware of a set of trust model guidelines for
these.
As for the ASP protocol that might run between an ICAP service (or
custom proxy) and the ASP central service site, i think that this area
is a little new and we should wait a year or two and then enlist the
ASP's into putting forward some proposals in this area.
- Don