ietf-openproxy
[Top] [All Lists]

Re: IAB considerations

2003-08-15 16:15:29


On Thu, 24 Jul 2003, The Purple Streak, Hilarie Orman wrote:

The current consideration draft confuses "privacy" and "undetected
modification" and "encryption".

"Privacy" is about trusting a party with data that they may use but
not disclose.  The detection modification of data is its
"integrity", and it can be ensured by cryptographic methods,
including keyed hashes and public key methods, but in general, not
encryption.  Encryption is used for "confidentiality", and it can be
accomplished by cryptographic methods, but it is not a way to ensure
integrity: encrypted data on the wire can be undetectably modified
by third parties unless a cryptographic integrity mechanism is used
in conjunction with the encryption.

While do not fully agree with your interpretation of privacy,
integrity, and encryption, I would be more than happy to discuss
specific draft flaws and address these concerns (of course). What
draft text should be fixed in this regard?

The current draft characterizes processor identification at content
provider sites as "irrational"

I disagree. The draft says (emphasis added) "It is irrational to
expect a content provider to provide _access_ to internal hosts
participating in content generation". This is different from providing
identification of those hosts!

The point is that in a typical environment an end user would have no
way to access internal hosts, even if they are well identified.
Furthermore, even if such access is provided as an exception to
corporate integrity policy, the accessed servers will not be able to
tell the end user much because they are not designed for or have
enough information to communicate with end users. Note that the above
quoted text belongs to the "IP-layer communication" section. We are
discussing addressability of the OPES intermediaries there, nothing
else.

The conclusion in the current draft is that the IAB consideration in
question can apply to a "a very limited subset of OPES intermediaries"
and, hence, is not directly satisfiable in real world.

My feeling is that IAB did not see the big picture (OPES systems) and
focused their attention on components (OPES processors), creating
irrelevant/misleading concerns. I am guessing that they simply did not
consider common arrangements where many OPES processors form a single
OPES system, representing a single content/data provider.

Note that if IAB had expressed their concerns in terms of OPES
systems, we would have no problems satisfying them! My suggestion is
that we do not treat IAB concerns literary but apply our better
understanding of the problem domain to satisfy "true" IAB intent.

If you are familiar with Lawrence Lessig's work, this approach is
similar to re-interpreting the Constitution authors' intent in the
light of current [digital] reality instead of treating Constitution
text literary and, hence, inapplicable. To our advantage, IAB members
are still alive as opposed to US Constitution authors; we can always
get a second opinion. Moreover, I think Markus intended to get such a
second opinion sometime soon, using the existing draft.

It is also argues that end users cannot identify themselves usefully
to a content provider's internal processors.  Although I don't
disagree that this might be true in some implementations, it isn't
clear that it is impossible in practice.

It is not that the users cannot identify themselves. They
[technically] can. It is that the internal OPES processors do not
poses enough state and global understanding to respond to user
requests. Most OPES processors do not have a notion of a "user"; they
work with much more simple and well-focused objects like XML trees,
access counters, or ad images.

I think that overall the viewpoint should clearly distinguish
between protocol feasibility and impact on content provider
practices.

The text is trying to distinguish between micro-level feasibility
(OPES processor MUST be addressable) and architectural macro-level
feasibility (OPES processor is invisible behind an OPES system which
MUST be addressable).


We can approach the problem from a different angle:

        IAB already made an exception for chained OPES processors.
        An OPES system is nothing else but a chain of OPES processors
        or a very similar structure. Clearly, there should be
        no difference to the end user whether she deals with
        a chain or a "graph/tree" of OPES processors as long as the
        exit point is addressable/identified!

Would that angle help you accept the notion of OPES system? If not,
where do you see an important difference between a "chain of OPES
processors with an addressable exit point" and a "graph of OPES
processors with an addressable exit point"?

Thank you,

Alex.


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