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

From: "Jon Kyme" <[email-masked]>
Date: Tue, 13 May 2003 15:23:39 +0100

>> Issues like this:
>> http://www.toyz.org/SpamArrestSpams.html
>>
>> Summary: Alleges SpamArrest harvests sender addresses
>
>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).

>Ths SpamArrest abuse is a potential problem in any system where
>you let a third party with handle your mail.  It is a consideration
>in any system where that involves asking a third party anything about
>mail, including DNS blacklists.
>

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

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

That would be nice.  No negative privacy impact is a "requirement".
I think we had a fairly good consensus on the
Requirements...

--

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 13 May 2003 10:49:46 -0400

> 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.

> 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.

>> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 11:46:53 -0400

Excellent, these are all good points.  I'll take the lead on compiling a
framework that includes components provided.  I'll probably start with a
simple Table of Contents.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jon
> Kyme
> Sent: Tuesday, May 13, 2003 10:24 AM
> To: ASRG
> Subject: Re: [Asrg] C/R Thoughts: Take 1
>
>
> >> Issues like this:

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 13 May 2003 10:40:09 -0600 (MDT)

> From: Eric Brunner-Williams in Portland Maine <[email-masked]>
> To: "Jon Kyme" <[email-masked]>

> ...

I'm not sure the SpamArrest crime qualifies as a privacy issue for the
sender.  As a sender, you can't know whether the recipient of your mail
will respect its privacy.  Must every recipient of mail publish some
kind of policy that will be "certified" by an officious uselessness like
TrustE in the U.S?  Even if it is an issue for the sender, it seems the
recipient is on the hook for preventing abuses like SpamArrest's.

> ...

That it is an impossible to satisfy requirement bothers me.

Many spam defenses involve consulting third parties.  For examples,
consulting third parties for authentication, to determine whether a
message is bulk, or whether the sender is an infamous spammer are
fundamental to many spam defenses.  In each case, the question
itself divulges information that can be very sensitive.  For example,
knowing that [email-masked] received a message from
[email-masked] might be turned into a lot of money on the stock
market.  Letting the FBI know that [email-masked] received a
message from you could get you an indefinite secret confinement.

As with security, nothing it perfect.  What we can and must do is
minimize and fully disclose the privacy problems of spam defense.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg