consent expression (was RE: [Asrg] ASRG next steps)

Paul Judge <paul.judge@ciphertrust.com> Wed, 05 March 2003 00:04 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 TAA16205 for <asrg-archive@odin.ietf.org>; Tue, 4 Mar 2003 19:04:18 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h250F1J26748 for asrg-archive@odin.ietf.org; Tue, 4 Mar 2003 19:15:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h250F1526745 for <asrg-web-archive@optimus.ietf.org>; Tue, 4 Mar 2003 19:15:01 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16199; Tue, 4 Mar 2003 19:03:47 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h250E1526702; Tue, 4 Mar 2003 19:14:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h250D4526669 for <asrg@optimus.ietf.org>; Tue, 4 Mar 2003 19:13:04 -0500
Received: from ciphertrust.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16143 for <asrg@ietf.org>; Tue, 4 Mar 2003 19:01:50 -0500 (EST)
Received: from ([10.0.0.6]) by mail0.ciphertrust.com with ESMTP ; Tue, 04 Mar 2003 19:01:30 -0500 (EST)
Received: by ctxchg.ciphertrust.com with Internet Mail Service (5.5.2653.19) id <VRGLC17Z>; Tue, 4 Mar 2003 18:51:41 -0500
Message-ID: <B1F08F445F370846AB7BEE424365F00DCBF465@ctxchg.ciphertrust.com>
From: Paul Judge <paul.judge@ciphertrust.com>
To: 'Vernon Schryver' <vjs@calcite.rhyolite.com>, asrg@ietf.org
Subject: consent expression (was RE: [Asrg] ASRG next steps)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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, 04 Mar 2003 18:51:40 -0500

> 
> What is "consent expression"?  

Consent expression means that someone can state which communication they
wish to receive or not to receive. This allows a very granular definition by
each user(individual or organization).


> If it is not a trivial boolean like 
> "I do [not] like spam," how can it not be a magnet for abuse ranging
> from minor privacy violations to more spam to literal visits from
> death squads reducing their political enemies?

trivial boolean? spam can not be expressed as a boolean. We realized that
the definition is inconsistent and people in this community have spent many
years debating "unsolicited bulk" versus "unsolicited commercial bulk"
versus a host of other definitions seeking some form of optimal cover set of
everyone's personal definition. The problem is that while these broad
definitions are good, they are not perfect. There are many messages that
people consider spam that do not fit these definitions (this leads to false
negatives). Likewise there are messages that fall within these definitions
that are not considered spam (this leads to false positives). Spam is in
many cases an individual preference. It is a subjective opinion of unwanted
messages. One approach is to continue to try to confine the definition to
one that covers only the subset of what everyone considers spam without
including anyone's wanted messages. A different approach is to step away
from the binary decision of spam and non-spam and realize that communication
can be more granularly defined. For example, "product offers", "chain
letters", "mailing lists", "newsletters", "greeting cards", "fradulent
offers", "unauthenticated messages", "unverifiable messages", etc. By
developing a robust categorization of messages, we can allow users to
express consent for certain types of communication. This allows the common
lack-of-consent policies to be implemented as close to the source as
possible. From there, we require an architecture that can support these
policies. This architecture may very well be a combination of current and
new approaches.
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg