Subject: Re: [Asrg] New take on emerging idea. (yet another C-R system?)

From: "John Fenley" <[email-masked]>
Date: Thu, 10 Apr 2003 11:51:43 -0600

>From: J C Lawrence <[email-masked]>
>If you do it via consent tokens, the user can see all the consent tokens
>he as acquired from others, and the consent tokens he has grated
>others.  He doesn't (necessarily) see how or why those tokens were
>created or exchanged, or what traffic takes advantage of them.

sounds a little messy, and confusing for a new internet user to deal with.

>Note that this process exposes another spam vector.  As systems will
>have to maintain their private lists of consent tokens, then an obvious
>spammer approach is to compromise systems (and subscribe to large
>mailing lists) and collect tuples of address pairs and consent tokens.
>If they can then inject forged mail with the appropriate envelopes and
>tokens they can bypass the system.

Messier, and less secure that temporary whitelisting/choicelisting.

John Fenley

side note:
=====================================================
I have updated my plan to allow notification of delivery failure to list 
managers. This was lacking in the previous version, and I think it nicely 
rounds out the plan.

www.pontifier.com/database.html
www.pontifier.com/challenge.html

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

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

---

From: J C Lawrence <[email-masked]>
Date: Thu, 10 Apr 2003 11:53:49 -0700

On Thu, 10 Apr 2003 11:51:43 -0600 

> sounds a little messy, and confusing for a new internet user to deal

It is, or at least can be.  Flexible systems are like that.  I'm not
about to try to resolve consumer-grade UI issues at this part in the
game.  That's not my background or an area I'm particularly interested
in.  What I am interested in is building a system that someone, nay,
many man someones from MS to AOL to Cyrus to...etc can whack what they
think might be a usable UI on.

> www.pontifier.com/database.html www.pontifier.com/challenge.html

I don't like and would rather avoid centrally defined and managed
systems.  They are too prone to abuse, and frankly, I consider them
unsuitable, especially given recent history.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Chuq Von Rospach <[email-masked]>
Date: Thu, 10 Apr 2003 12:34:06 -0700

On Thursday, April 10, 2003, at 11:53  AM, J C Lawrence wrote:

> It is, or at least can be.  Flexible systems are like that.

but at the same time, we're likely talking about multiple systems, 
and/or systems with different operating modes. The typical user doesn't 
need real-time token generation for web pages, what they want can be 
stuffed into a mail client and doesn't require any server side at all. 
Handle it all at the MUA level if you want. and it wouldn't be the 
first time someone built a system with an "expert mode" that hid 
secondary features until a user decided to tackle them....

An MUA-based individual whitelisting system that interfaces to your 
address book (and stores your permission scheme in your address book) 
would solve most of the complexity for Joe User with some careful 
design, and make it portable to the user, not the server. Then other 
systems can be put in place at the server and organization levels if 
you want to manage the larger infrastructure issues (role accounts, web 
scraping, etc), and to implmenent organizational white and black lists 
and such. Those can be managed by "us pros", and be more complex, and 
yet stay out of the way of a client also doing their own personal 
management on a micro level.

No need for "a" solution here, and frankly, it's not what we want. 
There's a use for organizational spamblocking and personal spamblocking 
(i.e., mail.app's stuff on OS X), and a use for organizational 
whitelisting systems and personal ones. they're complementary, the only 
real issue is making sure they don't get into turf wars by C/Ring each 
other to death. ("you identify first!" "No, you!") -- but that's no 
worse than vacation bot wars, is understood, and we should realize up 
front we won't solve that problem, either.. (grin)

---

From: J C Lawrence <[email-masked]>
Date: Thu, 10 Apr 2003 12:52:36 -0700

On Thu, 10 Apr 2003 12:34:06 -0700 

> but at the same time, we're likely talking about multiple systems...

Bingo.  I would much prefer not to marry to a specific implementation,
design, architecture, or deployment.  Let the decisions be made at the
points where real metal hits real road, and then __allow__ them to
migrate up the stack if desired.  

I'm not about to define, declare, or formally dictate a socio-political
war at this stage in the game.

> design, and make it portable to the user, not the server. 

<I carefully won't mutter things about LDAP schemas and how they *could*
tie in fairly nicely with this and John Fenley's proposal>

> Then other systems can be put in place at the server and organization
> levels if you want to manage the larger infrastructure issues (role
> accounts, web scraping, etc), and to implmenent organizational white
> and black lists and such. Those can be managed by "us pros", and be
> more complex, and yet stay out of the way of a client also doing their
> own personal management on a micro level.

No you got it...

Put resources and intelligence at the point where they are actually
used, and where there are humans with the subjective and contextual
definitions to make up their own damn minds for themselves.

> No need for "a" solution here, and frankly, it's not what we
> want. There's a use for organizational spamblocking and personal
> spamblocking (i.e., mail.app's stuff on OS X), and a use for
> organizational whitelisting systems and personal ones. they're
> complementary, the only real issue is making sure they don't get into
> turf wars by C/Ring each other to death. ("you identify first!" "No,
> you!") -- but that's no worse than vacation bot wars, is understood,
> and we should realize up front we won't solve that problem,
> either.. (grin)

Up until a few years ago most vacation bots Did The Right Thing.  Heck,
it may still be true.  I'll be happy if we can design a system that:

  a) Is easy to understand without an EBNF or RFC

  b) Can be easily and simply made to work correctly based on that
  understanding.

  c) Isn't trivially compomisable by people who do read the EBNF and
  have evil intent.

We know there are going to be screw ups.  There always have been and
there's little sign of that pattern changing.  Deal.  As long as we make
it easy to Do The Right Thing -- especially if we manage the miracle of
not making it attractive to Do Something Similar But Different -- then I
think we can rest content and get back to our happy rounds of bitching
and moaning at the horrible state of affairs with the screw ups and how,
"People had better manners and were smarter in my day..."