On Thu, 3 Apr 2003, Weisong Shi wrote:
Given theses traces, is it possible for clients or content providers
to verify the correctness of them? For example, if an OPES processor
reduces the resolution of an image, but he record something else.
How can you verify this?
You cannot automatically detect all inconsistencies, of course. It is
impossible to guarantee that a program does not lie or to auto-detect
every possible lie. What we can and should do is:
- assist the user or content provider in contacting
administrators of broken OPES systems once the
user or content provider suspect a problem
(i.e., OPES trace can help in locating the
broken intermediary)
- support bypass of OPES intermediaries when
possible (i.e., you may be able to get a
raw, unprocessed image if you suspect that
processing is corrupted _and_ if the system
does not require processing)
- optionally, we can ask for digital signatures
for trace entries so that you have better
protection from the trace itself lying to you
(but most intermediaries will not pay $$$ for
key certificates so this will work just for
a few big companies handling most(?) of the
traffic)
Please note that OPES does not introduce new problem categories (what
you describe can happen today if, say, a CDN gets hacked), but it may
help solving some of the existing ones, at least partially.
Alex.
Alex Rousskov wrote:
Oskar,
It looks like our disagreements are not as deep as I
originally thought. I agree with most of your latest comments.
Indeed, we should be careful about distinguishing a content
provider system and a 3rd party system operating under content
provider permission. I was pushing for treating any system as a single
entity once the message leaves that system. You are saying that there
are at least three kinds of systems: content providers, end users with
their proxies, and 3rd party services like CDNs. I agree, as long as
we can treat a 3rd party service as a single entity once the message
leaves that service.
How about starting with the following simple set of
unpolished rules:
1. An OPES processor SHOULD add its identification
to the trace.
2. An OPES processor SHOULD add to the trace
identification of every callout service that received
the application message.
3. An OPES processor MUST add to the trace identification
of the "system/entity" it belongs to. "System"
ID MUST make it possible to access "system" privacy
policy.
4. An OPES processor MAY group the above information
(items 1-3) for sequential trace entries having
the same "system/entity" ID. In other words, trace
entries produced within the same "system/entity"
MAY be merged/aggregated into a single less detailed
trace entry.
5. An OPES processor MAY delegate trace management to
a callout service within the same "system/entity".
We need to agree on what an "identifier" in items 1-3 represents and
how trace entries are encoded (the latter is application-specific).
Overall, do the above 5 items sound reasonable at all? Are there any
huge gaps they do not cover? (I think I know of one hole, but would
prefer to hear others' comments before diving any deeper)
Thank you,
Alex.