On Sat, 14 Feb 2004, Ed Gerck wrote: > Dean Anderson wrote: > > > You are confusing a covert channel with noise. They aren't the same. > > Of course they aren't -- how could a channel be equal to noise, anyway? > > What I said is that the *information* transferred by a covert channel, > whatever that information might be, is NOT the message (the intended > information). So, the spammer didn't intend to send you a message about Viagra?? That somehow "noise" caused the message to be altered to be about Viagra?? I don't think so. > Thus, for modeling purposes in terms of Shannon's > information theory, the choice is clear. The *information* transferred > by a covert channel is noise (the only other possible option). Not only isn't it 'the only possible option', but the information carried by a covert channel is not noise. The sender sent information and the receiver recieved the information. It isn't the case that the spammer intended to send a message about the superbowl, but somehow "noise" altered the message to a solicitation on viagra. Rather, they intended to send a message on viagra, and you recieved their message, noise free. But seeing the solication for viagra, you became upset, and reported a complaint about the inappropriate use of the channel. In information-theory-speak, you report a "communication in violation of the security model"; a covert or sneaky channel. A note of caution: The intent of the senders and receivers is irrelevant to information theory channels. Covert channels can exist with or without intent, and with or without cooperation. Information theory is concerned with the movement of information through a transmitter to a reciever. The intent or cooperation in that transfer is irrelevent, except that a channel used for information not intended for transmission is called covert or sneaky. For example, when a remote SSL attacker uses timing information to obtain the secret key of the server, the server isn't cooperating, nor does it intend to provide the secret key. Information theory looks at the actual value of the key, and whether that was transmitted to the reciever with or without noise. In the case of the SSL timing attack, there is a lot of noise, but information theory tells us, and practice confirms, that the noise can be corrected, until the key is successfully transmitted to the receiver error free. In the case of spam though, we safely assume the intent of sender to get a spam message to the recipient, and can couch our descriptions accordingly, but we need to exercise some caution. With regard to noise, what we are really be concerned with is the message before it is transmitted, and the message after it is received. In our case, the transmission is usually noise free thanks to the function of TCP. > > Antispammers have commonly used an analogy that equates spam with noise > > and anti-spam efforts as trying to find a "noise filter". The analogy > > sounds good, but is not accurate, which might suggest a reason why they > > have failed to find a "filter". > > If you are proposing a different model, fine. I'm not proposing a different model. The model of "spam is noise" that you are using is inaccurate and wrong. I'm explaining the correct way to model spam in information theory. This will help explain why many anti-spam proposals are unworkable, and why previous attempts have failed. > > Spam isn't unwanted until after the fact: You read it, and then you don't > > like it. > > I strongly disagree -- I don't read spam and I don't even try to > read the unsubscribe information in it. I try the best I can to detect > it and delete it as early as possible. If possible, even before it is > queued in my mail box and causes me further problems (and costs). You don't _want_ to read it. You don't _want_ to spend time reading it. It's the fact that one doesn't have time to read all the junk that many people find annoying about spam, as well as objectionable content. But those who don't have email aren't annoyed by spam. You have to receive spam to be annoyed by it and not want it. > I believe that's also what the majority of email users would like to do > -- or, do you really think we all have the time to read spam and decide > after the fact that it is indeed spam? What users want is constrained by what's possible. I want faster-than-light travel for free. Many people want that, which explains its popularity in science fiction. But we are constrained by physics and technology. Quite obviously, in the case of spam we are trying to find ways so that we don't have to read/sort/delete spam, or spend less time doing so. You have promised that your scheme will eliminate the whack-a-mole nature of spam. I'm saying that it is impossible to eliminate this charactistic from spam, based on what we know from information theory about covert or sneaky channels. This tells us that your scheme cannot deliver what you have promised. The prevalence of anti-spam schemes that claim to make spam just disappear are much like the perpetual motion machines proposed at the turn of the last century. Eventually, we started to use thermodynamics to analyze these schemes before they were built. When we see perpertual motion, we dismiss the idea as a "perpetual motion scheme". We do not need to prototype perpetual motion schemes to know they won't work. Likewise, we do not need to prototype communication systems that claim to be free of covert channels to know that they won't be free of covert channels. Information theory tells us that one can never be free of covert channels. > That's why the proposal for anti-spam burden does provide a mandatory > pre-delivery burden that can be increased as much as the *recipient* > wants. Users should not be burdened with reading and sorting out spam -- > regardless how the senders want to classify it! I think you also need to consider the causality constraints on a "Pre-delivery burden that can be increased as much as the *recipient* wants". You cannot make an uneven playing field for the spammer. You can increase the pre-delivery burden on everyone. Yet the spammer using virus-stolen computer and bandwidth resources won't care. You can't change the pre-delivery burden after you receive the spam because of causality. --Dean