ietf-asrg
[Top] [All Lists]

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

2003-05-13 08:02:22
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>