Re: Thoughts on MixMinion archives

[Nick Mathewson <nickm@alum.mit.edu>]

On Tue, 2002-04-23 at 18:02, Len Sassaman wrote:
> On 23 Apr 2002, Nick Mathewson wrote:
> 
> > Well, if we get the cap/type system straightened out enough, we may be
> > able to keep backwards compatibility indefinitely.  We should ponder
> > what backwards-compatible changes are considered for the future, and
> > which of them can be pulled into the Mixminion spec.
> 
> I think that backwards compatibility with Type I remailers is something to
> strive to be free of. We're currently managing just fine with the remix
> system, but I hate to see users using Type I. If we can just get everyone
> to upgrade to Type III clients, I see no real reason to worry about
> supporting the previous versions.

Sorry -- I was suggesting that, if we got stuff right this time, we
might make future systems backwards compatible with type III... not that
we should keep types I and II alive forever.

 [...]
> > Sorry about the confusion--what you describe is the intended behavior of
> > a SMTP delivery module.  The idea is to make all delivery methods into
> > isolated modulres, to make the security of the core easier to examine.
> 
> Okay, so this is a Mixminion specific architecture issue, which I don't
> have to worry about.

Well, it touches the spec a little too.  The idea is to have a notion of
"payload type" in the spec, so that experimental extensions can be
isolated from the spec proper.

The spec will need to say things of the form, "When you receive a
message of type SMTP, you need to extract an email address like this and
a message body like that, and send them along via SMTP--either via an
MTA or manually."

 [...]
> Agreed. This also brings up the sticky question of extensibility. Ideally,
> we'll permit no extensions that would fragment the anonymity set. However,
> if we don't specify a method for specifying additional features/
> capabilities, they will happen ad-hoc.

Indeed.  Also, extensibility allows us to phase new delivery and
forwarding strategies into the system _without_ breaking backwards
compatibility.

There's no way we can prevent people from wilfully adding stupid
extensions to the system.  We should just practice good design
ourselves, make sure that our design docs explain how to do so, and
encourage others to follow along.  I bet that anybody with enough hubris
to ignore our advice has enough hubris to hack an incompatible, ad-hoc
extension mechanism onto our code anyway. :)

Yrs,
-- 
Nick