Re: [Asrg] C/R Thoughts: Take 1

Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net> Tue, 13 May 2003 15:02 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15689 for <asrg-archive@odin.ietf.org>; Tue, 13 May 2003 11:02:22 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DESRF29839 for asrg-archive@odin.ietf.org; Tue, 13 May 2003 10:28:27 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DESRB29836 for <asrg-web-archive@optimus.ietf.org>; Tue, 13 May 2003 10:28:27 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15662; Tue, 13 May 2003 11:01:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FbJk-0004gr-00; Tue, 13 May 2003 11:03:48 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FbJj-0004gl-00; Tue, 13 May 2003 11:03:47 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DER4B29740; Tue, 13 May 2003 10:27:04 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DEQSB29701 for <asrg@optimus.ietf.org>; Tue, 13 May 2003 10:26:28 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15532 for <asrg@ietf.org>; Tue, 13 May 2003 10:59:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FbHq-0004fT-00 for asrg@ietf.org; Tue, 13 May 2003 11:01:50 -0400
Received: from 216-220-241-233.midmaine.com ([216.220.241.233] helo=nic-naa.net) by ietf-mx with esmtp (Exim 4.12) id 19FbHp-0004fJ-00 for asrg@ietf.org; Tue, 13 May 2003 11:01:50 -0400
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.9/8.12.9) with ESMTP id h4DEnkZj023207; Tue, 13 May 2003 10:49:46 -0400 (EDT)
Message-Id: <200305131449.h4DEnkZj023207@nic-naa.net>
To: Jon Kyme <jrk@merseymail.com>
cc: ASRG <asrg@ietf.org>, brunner@nic-naa.net
Subject: Re: [Asrg] C/R Thoughts: Take 1
In-Reply-To: Your message of "Tue, 13 May 2003 15:23:39 BST." <E19Fagt-0001Ou-00@argon.connect.org.uk>
From: Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Tue, 13 May 2003 10:49:46 -0400

> >I see privacy issues for challenge/response systems, but that's not
> >one.  
> 
> Perhaps I should have said "data protection" (as we call it in the UK).

95/46/ec et seq.

There's no easy fix for the similarity but difference in definition.

There is the issue of describing the data SpamArrest collects. For those
who want to see what another community have attempted, see the P3P Spec,
where we have one descriptive vocabulary (read the schema if you can, and
the text then the schema if you cannot). 

There is the issue of describing what SpamArrest does with the data it
collects, in particular how long it retains it, who it provides it to,
and a special case of that, what access the originator of the data has
to correct (or creatively modify) it. Again, there is one descriptive
vocabulary in the P3P Spec.

> Of course the *sender* isn't aware (in advance) that this particular
> 3rd party is handling the mail. 

Hmm. This is the kind of problem putting data collection policy announcement
into <junk> is supposed to solve. P3P-on-http via a well-known-location, or
as junk-on-forms or junk-on-cookies (I'm one of the proud parents of that)
or junk-on-... is intended to allow (er, xml validation) evaluation of 1st-
and 3rd-party policy statements (that might actually be technically correct).
The receiver could be announcing a 3rd-party redirect.

>> I think any spam filtering RFC ought to have a section on privacy
>> like the required section on security.

Agreed. Of course, it will need to show that "privacy" (aka "data protection")
isn't a subset of "security", or a trivial consequence of use of cryptographic
technique or invisible ink.

> That would be nice.  No negative privacy impact is a "requirement".

The vagueness of this concerns me.

Eric
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg