Evan Daniel schrieb:
> On Tue, May 26, 2009 at 4:45 PM, xor <x...@gmx.li> wrote:
>> On Friday 22 May 2009 16:39:06 Evan Daniel wrote:
>>> On Fri, May 22, 2009 at 8:17 AM, Matthew Toseland
>>>
>>> <t...@amphibian.dyndns.org> wrote:
>>>> On Friday 22 May 2009 08:17:55 bbac...@googlemail.com wrote:
>>>>> Is'nt his point that the users just won't maintain the trust lists?
>>>>> I thought that is the problem that he meant.... how can Advogato help us
>>>> here?
>>>>
>>>> Advogato with only positive trust introduces a different tradeoff, which
>>>> is still a major PITA to maintain, but maybe less of one:
>>>> - Spammers only disappear when YOU mark them as spammers, or ALL the
>>>> people you trust do. Right now they disappear when the majority, from the
>>>> point of view of your position on the WoT, mark them as spammers (more or
>>>> less).
>>> When they *fail to mark them as trusted*.  It's an important
>>> distinction, as it means that in order for the spammer to do anything
>>> they first have to *manually* build trust.  If an identity suddenly
>>> starts spamming, only people that originally marked it as trusted have
>>> to change their trust lists in order to stop them.
>>>
>>>> - If you mark a spammer as positive because he posts useful content on
>>>> one board, and you don't read the boards he spams you are likely to get
>>>> marked as a spammer yourself.
>>> Depends how militant people are.  I suspect in practice people won't
>>> do this unless you trust a lot of spammers... in which case they have
>>> a point.  (This is also a case for distinguishing message trust from
>>> trust list trust; while Advogato doesn't do this, the security proof
>>> extends to cover it without trouble.)  You can take an in-between
>>> step: if Alice marks both Bob and Carol as trusted, and Bob marks
>>> Carol a spammer, Alice's software notices and alerts Alice, and offers
>>> to show Alice recent messages from Carol from other boards.
>>> (Algorithmically, publishing "Sam is a spammer" is no different from
>>> not publishing anything about Sam, but it makes some nice things
>>> possible from a UI standpoint.)  This may well get most of the benefit
>>> of ultimatums with lower complexity.
>>>
>>>> - If a spammer doesn't spam himself, but gains trust through posting
>>>> useful content on various boards and then spends this trust by trusting
>>>> spam identities, it will be necessary to give him zero message list
>>>> trust. Again this has serious issues with collateral damage, depending on
>>>> how trigger-happy people are and how much of a problem it is for newbies
>>>> to see spam.
>>>>
>>>> Technologically, this requires:
>>>> - Changing WoT to only support positive trust. This is more or less a one
>>>> line change.
>>> If all you want is positive trust only, yes.  If you want the security
>>> proof, it requires using the network flow algorithm as specified in
>>> the paper, which is a bit more complex.  IMHO, fussing with the
>>> algorithm in ways that don't let you apply the security proof is just
>>> trading one set of alchemy for another -- it might help, but I don't
>>> think it would be wise.
>>>
>>>> - Making sure that my local ratings always override those given by
>>>> others, so I can mark an identity as spam and never see it again. Dunno
>>>> if this is currently implemented.
>>>> - Making CAPTCHA announcement provide some form of short-lived trust, so
>>>> if the newly introduced identity doesn't get some trust it goes away.
>>>> This may also be implemented.
>>> My proposal: there are two levels of trust (implementation starts
>>> exactly as per Advogato levels).  The lower level is CAPTCHA trust;
>>> the higher is manually set only.  (This extends to multiple manual
>>> levels without loss of generality.)  First, the algorithm is run
>>> normally on the manual trust level.  Then, the algorithm is re-run on
>>> the CAPTCHA trust level, with modification: identities that received
>>> no manual trust have severely limited capacity (perhaps as low as 1),
>>> and the general set of capacity vs distance from root is changed to
>>> not go as deep.
>>>
>>> The first part means that the spammer can't chain identities *at all*
>>> before getting the top one manually trusted.  The second means that
>>> identities that only solved a CAPTCHA will only be seen by a small
>>> number of people -- ie they can't spam everyone.  The exact numbers
>>> for flow vs depth would need some tuning for both trust levels,
>>> obviously.  You want enough people to see new identities that they
>>> will receive manual trust.
>> It is absolutely INACCEPTABLE for a discussion system to only display 
>> messages
>> of newbies to "some people" due to the nature of discussion:
>> - The *value* of a single post from a new identity which has posted a single
>> message can be ANYTHING... it can be absolute crap... but it can also be a
>> highly valuable secret document which reveals stuff which is interesting for
>> millions of people. In other words: The fact that someone is a newbie does 
>> not
>> say ANYTHING about the worth of his posts. In more other words: NO individual
>> has the right to increase the "worth" of his posts - as in the amount of
>> people reading them - by speaking very much on Freetalk and gaining lots of
>> trust with that. EVERY SPEAKER SHALL BE EQUAL! :) Thats freedom of speech.
>> Therefore, the probability of messages of a valid identity not being seen by
>> everyone must be reduced to nearly zero.
>>
>> Further, "a small number of people" will mean random people, and because you
>> cannot expect newbies to solve thousands of captchas, a newbie will only 
>> solve
>> 10 or so. So if you really mean only the people who have published the
>> captchas, how high do you consider the probability that: 0. They actually use
>> Freetalk currently? 1. They read (maybe single!) board where the newbie 
>> posts?
>> 2. They read the posts of him? 3. They are interested in the posts? 4. They
>> actually give him real trust then, thats the product of all the
>> probabilities!..... This is VERY unlikely! So if we want newbies to have ANY
>> chance to gain trust, we need thousands of people to see their posts until
>> someone is actually interested, because if only 10 people see them, it is 
>> very
>> likely that not a single one will read the posts and give trust.
> 
> A small number could still be rather large.  Having thousands see it
> ought to suffice.  For the current network, I see no reason not to
> have the (default) limits such that basically everyone sees it.

If your small number is that big, you should add that because for me, "small" 
is not around
"thousends". Additionally, if you allow them to reach thousends (will a freenet 
based message system
ever reach more people?), is there any value in restricting this anyway?

> If the post is really that valuable, some people will mark the poster
> as trusted.  Then everyone will see it.

Why should they? People are lazy, so most, if not all will just read it, maybe 
answer it, but who
thinks about rating someone because of a single post? People are and will 
always be lazy.

> You may think that everyone should be equal; I don't.  If newbies are
> posting stuff that isn't spam (be it one message or many), I'm willing
> to believe someone my web can reach will mark them trusted.  You
> obviously aren't; that's fine too.  Fortunately, there is no
> requirement we use the same capacity limiting functions -- that should
> be configurable for each user.  If you want to make the default
> function fairly permissive, that's fine.  I think you'd be making the
> wrong choice, but personally I wouldn't care that much because I'd
> just change it away from the default if new-identity spam was a
> problem.

So you want the default to be more censoring. And you trust people to not be 
lazy. I oppose both.
First, if you really want to implement such censorship, make the default open, 
with thousends of
trusted users, it wont be a difference anyway. Second, why should people mark 
new identities as
trusted? I use FMS and i dont change the trust of every identity i see there. 
And i do somehow
manage a trustlist there. If someone is lazy (and the majority is), they will 
do nothing.

> Also, you seem to be mistaken about what I mean by limiting CAPTCHA
> identity capacity.  Limiting it to 1 means it's nonzero.  That means
> the identity can receive trust and be accepted, so the message will be
> read.  All it means is that they can't grant trust to anyone else.  It
> says nothing about their own ability to post messages.  The wouldn't
> need to solve lots of CAPTCHAs any more than they would under eg FMS.
> A few should suffice, for redundancy vs collisions and the poster
> having gone offline.

???

Who told you that someone would have to solve many captchas and that forever? 
You only need to solve
1 captcha that is not already solved and which is from a trusted person which 
publishes its trustlist.
And i dont think he is mistaken. You still require people to mark identities as 
trusted to get them
visible and have them stay visible to others. This wont happen, so people will 
loose their
Captcha-Trust and will have to solve more captchas. Annoying for everyone, and 
most annoying for the
lazy majority.

> Fundamentally, it's a question of whether you believe CAPTCHAs work.
> I don't.  If you start with an assumption that CAPTCHAs are a minor
> hindrance at most, then if you require that everyone sees messages
> sent by identities that have only solved CAPTCHAs and not gained
> manual trust, then you've made it a design criteria to permit
> unlimited amounts of spam.  (That's bad.)  If you believe CAPTCHAs
> work, then things are a bit easier...  but I think the balance of the
> evidence is against that belief.

Captchas may not be the ultimative solution. But they are one way to let people 
in while prooving to
be humans. And you will need this limit (human proove), so you will always need 
some sort of captcha
or a real friends trust network.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to