[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notes from Conversation with Roger
I got a free pass for 2 to see a preview of _Blade II_. When Roger and
I got there, we found (for worse or better) that they had already given
out all the seats, and that we'd need to go to a cafe and talk about
Mixminion instead.
Here are the notes we scribbled, somewhat elucidated and somewhat
reorganized.
NOT ALL OF THESE OBSERVATIONS ARE TRUE. This was all brainstorming.
- Although we have said we don't want to log individual messages, it
appears that some operators would like usage statistics. Perhaps
it would be good to tabulate number of incoming messages vs. number
of messages sent via each output method.
ABUSE
- Abuse seems to be the biggest unaddressed problem for people who
run remailers.
- Curtailing bandwidth is desirable, but won't get abuse complaints
to go away: somebody can send a threatening message in under 1k.
OBSERVATION 1: It's okay if there are different output methods
for nodes that accept different levels of exposure to abuse
complaints. Even if there are never more than a couple dozen nodes
willing to send SMTP to all and sundry, they could be supplanted by
others that send SMTP to those who opt in, others that encrypt and
store...
Of course, nothing but "sent SMTP to anybody" is good enough in
situations when recipients do not want to admit that they are
recipients of anonymous messages--see Observation 7 below. (Roger
made an analogy to a regulation during the 1950's wherein the Post
Office would -- as an alleged service to the postal customer --
hold "communist propaganda" for you at your local post office, and
not give it to you unless you came in and acknowledged with your
that you wanted it.)
OBSERVATION 2: Running middle nodes (ones that relay to other
nodes, but not to arbitrary SMTP addresses) may be relatively
innocuous. If this is so, then we can get people running those
nodes who would not want to assume the burden of running an open
SMTP exit.
OBSERVATION 3: Roger likes hybrid topologies, especially (from what
I can tell) ones that start with a free-route, but which end with a
short cascade to an exit (or destination) node. These would seem
to be a natural consequence of a system with many more relay nodes
than exit nodes.
OBSERVATION 4: There's a difference between "anonymous receiving
systems" and "anonymous sending systems." [I don't remember what
this had to do with abuse.
OBSERVATION 5: Abusive users are a problem for exit nodes, and thus
for the system; abusive exit nodes are not a problem in themselves?
OBSERVATION 6: We should encourage users to run their own
recipient/originator/relay nodes to improve their anonymity. (Of
course, not all users can do so.)
OBSERVATION 7: The problem with opt-in is people who cannot admit
that they want to receive anonymous messages: they are
indistinguishable from people who do not want anonymous messages,
but have not said so.
Nevertheless, if some exit nodes are willing to run opt-in-only
SMTP, whereas others run unrestricted (or opt-out) SMTP, we may be
better off than if we only have unrestricted SMTP.
SIDENOTE
- Client software should gripe about sending documents in formats like
MS Word. Word documents are less anonymous than people think.
SINGLE-USE REPLY BLOCKS (SURBS) AND MULTI-USE REPLY BLOCKS (MURBs).
- SURB and MURB are short and easy to say.
- We should look, according to Paul, at "Flash Mixes". He says they
may help us achieve MURBhood.
- SURBs are better than nothing. In order to get any adoption over
Mixmaster 2, we'll need to have positive features that Mixmaster 2
lacks. SURBs could be such a feature on their own.
- We know of 3.5 was to make nym-like things with SURBs:
1. Nym servers that recipients restock with a supply of nyms.
2. Rendezvous: Use Freedom/Onion-Routing to connect to a public
location, and give RBs as people ask for them. You can require
auth/auth as necessary. (This assumes a connection-based
system exists.)
2'. Same as 2, but use MM instead.
3. Store messages, and send a bunch of SURBs to pick them up.
- "SURB-generators" are an alternative to MURBs. If I can give a
semitrusted nym server a way to generate SURBs for me, then this
may be better than MURBs because--except to the server holding
the generator-- all headers look the same.
THE RELATION OF MIXMINION TO CONNECTION-BASED SYSTEMS
- Will the lack of MURBs cause users to use connection-oriented
systems instead?
- There is reason to suspect that virtual circuits and long-term
connections risk anonymity, or at least make it harder to get.
STRATEGY NOTE 1: Let's not build in insecure or bogus versions of
features just to try to woo users away from connection-based
systems.
STRATEGY NOTE 2: If connection-based, low-latency systems come to
exist, and if they are ever as secure/anonymous as Mixminion, would
Mixminion still have a reason to be?
(Roger brought up the existence of users who don't have IP-like
connections, but if they're the only ones using Mixminion,
anonymity sets will be small indeed.)
Our conclusion was basically: "No, not if they were really as
secure/anonymous--but it is not certain that they will ever be. It
will be a wonderful day if they are."
- We can reduce our own latency by using cascades, since only the
first node in a cascade will ever have a batch waiting.
STRATEGY NOTE 3: The more users we've got, the lower our latency.
If we have no users, we're nothing.
Corollary: A user who runs an client/middle node is better still.
MORE SIDENOTES ON GOALS, PHILOSOPHY, AND LEGAL ISSUES
- (Roger wants Mixminion to support what Mixmaster does, plus
cascades, plus support for Free Haven.)
STRATEGY NOTE 4: We should keep the trust network human for now.
We should track performance of nodes, but let humans decide how to
choose paths.
STRATEGY NOTE 5: Nobody gets much anonymity unless we educate users.
OBSERVATION 8: Crypto is still a munition: though the old export
controls are no longer in effect, the wide scale adoption of crypto
is not (in some circles) considered a desirable goal.
OBSERVATION 9: If less-anonymous systems exist that provide enough
anonymity for ordinary people, are we left with only the "hardened
criminals"?
No. Consider 4 anonymity systems: [examples are chosen at random; I
have no idea of China's crypto resources.]
System 1: Breakable by nobody.
System 2: Breakable by the NSA.
System 3: Breakable by the NSA, China, Russia, and Israel, and any
major country with very good crypto.
System 4: Breakable by the NSA, the FBI, China, Israel, the Church
of Scientology, Microsoft, IBM, AT&T, Uganda, France, Organized
Crime, or anybody who's willing to spend $5M or send a large
posse of unsavory characters to go break the proper sequence
of kneecaps.
Clearly, the average person would prefer 1, 2, or 3 to 4--not just
"Hardened criminals". The worrisome people (if you're talking to
somebody who trusts the US govt) are those who need 1, and can't
settle for 2.
Roger and I don't think this is much of a problem: we're fairly sure
that we're not going to wind up with anything that falls under 1.
STRATEGY NOTE 6: Based on considerations of users who _would_ settle
for 4 above, we reiterate George's contention that we should
support people who are willing to trade anonymity for ease of use...
- ...so long as doing so doesn't compromise others, or tighten
anonymity sets.
- ...but educate!
OBSERVATION 10: Does educating users on how to use Mixminion well
make us liable or legally vulnerable?
- Obviously, we should ask a lawyer. Roger knows somebody
appropriate.
- Probably not, so long as we aren't explicitly urging people
to commit crimes.
- Nevertheless, harping on the possible criminal applications of
our service might make it seem (falsely!) that we condone
criminal behaviors, and provide a means for legal harassment.
Thus...
STRATEGY NOTE 7: We should only include legitimate, legal, generally
positive examples in our documentation. (e.g., let's not write
"Alice wants to hire a hit-man named Bob to kill Carol, who sold her
some bad heroin." Let's stick to "Alice wants to tell an
investigative journalist named Bob about the bogus accounting
practices of her employer, Carol." It's not that the former
necessarily makes us legally liable: it's just bad PR.)
OBSERVATION 11: End-user convenience is inversely proportional to
resistance against adversaries who can get access to your computer.
- In this case, saving messages is a no-no.
- Preference files are evidence, esp. if they name names.
- We should provide client software that works for users with
these needs and for users without them.
- An intermediate option is to encrypt such data, as GPG encrypts
keyrings.
SIDENOTES:
- We may be able to prevent Gzip bombing by requiring Gzipped packets
to have the output size in their headers, and by limiting that size.
- Others have written papers entitled "Topic: From Theory to Practice."
A cool title for us could be: "Mixminion: Fooing theory *from*
practice."
PLANS:
- When do we bring more people in?
- Option A: After a few more revisions of the spec.
- Option B: After the above, plus a proof-of-concept implementation.
(I favor B. Solicit the world's opinions before the first revision
of your code, and you start on the 2nd-system effect immediately.)
- What do I need in order to implement?
- For now, I need a spec more than anything.
- Soon, we'll need to discuss licensing and strategic decisions.
- I'm putting off writing crypto and net stuff; I'll have to do so
soon.
======================
And that's when we went home.
Yours,
--
Nick