Re: [gentoo-dev] RFP: System to account users configurations

[George Shapovalov <georges@its.caltech.edu>]

Hi guys.

Nice to see voting/user feedback discussed here!
I have spent some time few month ago thinking about similar issue. I would 
like to point out this link
http://www.its.caltech.edu/~georges/gentoo/epsp/vote0.html
where I present a few thoughts about possible voting system.
I should immediately note, that I was "designing" (well, "0" in the file name 
should give you an idea about its status :)) that system for a very specific 
purpose - to enhance quality control over ebuilds by allowing all users to 
cast their votes indicating ebuild stability and (optionally) popularity. 
Accumulation of additional information may provide nice statistics. However I 
would like to add one "feature request" to Rufiao's proposal. Namely the 
ability to configure what kinds of information are collected and sent 
upstream.

As I see there are two possible approaches towards design of voting system:
1. active system - passive users
2. passive system - active users

In reality any  reasonable voting system should include elements of both, the 
question is more about proportions :). In that text I was leaning more 
towards second option. You will find few arguments behind my thinking. 
Nonetheless the system I was in the end describing seems to be very similar 
to the one proposed by Rufiao :), including concerns about use of ips for 
identification and requirement to register. Though overall procedure looks a 
bit simplier.

Along the same lines there are two "boundary" positions WRT how much 
information is collected and processed.
1. Collect info about individual systems in central location and use that to 
build statistics. (pretty much necessary for 1st approach)
2. Only keep statistical info centrally and update it when user votes. May 
play well with 2nd approach if done correctly.

As was pointed out second position raises abuse concerns. However I would 
still prefer such approach if some care could turn up a reasonably secure 
model. At least it would be worth to try that as a first implementation, as 
it is much easier on resources and implementation.

Sorry about this rough posting, just wanted to bring up that link in case you 
will be able find anything usefull there :). I will try to get back to this 
topic and may be write something more detailed :).

George


On Sunday 16 June 2002 16:11, Rufiao wrote:
> The abuse of this kind of system should be taken into account, since it may
> be quite easy for someone to create a bot (or whatever) capable of feeding
> the system with fake data, and by consequence destroy its reputation.
>
> However, I agree this issue should not complicate the system setup. There
> are problems with the approach I've described, in particular for users who
> maintain more than a couple of Gentoo boxes (it may be inconvenient even
> for people who run more than one machine, due to the fact it's necessary to
> have one key per machine).
>
> Debian's popularity-contest uses SMTP as its transport, both to avoid the
> need for constant internet connection and to have some means to ensure the
> identity of every contributing machine. I'm not sure SMTP can help on the
> identification of users at all, and it may complicate the setup even more
> for users who don't have local MTA spools set (and which want to
> participate but don't have constant connectivity), so I've discarded it.
>
> Also, using the machine's IP addresses as a measure of abuse (by
> investigating how many posts occur for a given address) may lead to bad
> results, since some users have more than one machine under a 1:n NAT.
>
> In the end, it may be better to simply avoid the signup, and use some
> 'loose' approach, which is to ask the user's e-mail to be used just in the
> case of abuse detection (of course a 'bad' user could provide a fake e-mail
> address, but in this case, after the detection of abuse and a unsucessful
> attempt to contact the user, all his provided data can be set to be
> automatically rejected by the server-side system).
>
> But it may happen there's a better approach for this whole problem.. Any
> thoughts?
>