Gentoo Archives: gentoo-dev

From: George Shapovalov <georges@×××××××××××.edu>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] RFP: System to account users configurations
Date: Tue, 18 Jun 2002 05:38:53
Message-Id: 200206180337.26484.georges@its.caltech.edu
In Reply to: Re: [gentoo-dev] RFP: System to account users configurations by Rufiao
1 Hi guys.
2
3 Nice to see voting/user feedback discussed here!
4 I have spent some time few month ago thinking about similar issue. I would
5 like to point out this link
6 http://www.its.caltech.edu/~georges/gentoo/epsp/vote0.html
7 where I present a few thoughts about possible voting system.
8 I should immediately note, that I was "designing" (well, "0" in the file name
9 should give you an idea about its status :)) that system for a very specific
10 purpose - to enhance quality control over ebuilds by allowing all users to
11 cast their votes indicating ebuild stability and (optionally) popularity.
12 Accumulation of additional information may provide nice statistics. However I
13 would like to add one "feature request" to Rufiao's proposal. Namely the
14 ability to configure what kinds of information are collected and sent
15 upstream.
16
17 As I see there are two possible approaches towards design of voting system:
18 1. active system - passive users
19 2. passive system - active users
20
21 In reality any reasonable voting system should include elements of both, the
22 question is more about proportions :). In that text I was leaning more
23 towards second option. You will find few arguments behind my thinking.
24 Nonetheless the system I was in the end describing seems to be very similar
25 to the one proposed by Rufiao :), including concerns about use of ips for
26 identification and requirement to register. Though overall procedure looks a
27 bit simplier.
28
29 Along the same lines there are two "boundary" positions WRT how much
30 information is collected and processed.
31 1. Collect info about individual systems in central location and use that to
32 build statistics. (pretty much necessary for 1st approach)
33 2. Only keep statistical info centrally and update it when user votes. May
34 play well with 2nd approach if done correctly.
35
36 As was pointed out second position raises abuse concerns. However I would
37 still prefer such approach if some care could turn up a reasonably secure
38 model. At least it would be worth to try that as a first implementation, as
39 it is much easier on resources and implementation.
40
41 Sorry about this rough posting, just wanted to bring up that link in case you
42 will be able find anything usefull there :). I will try to get back to this
43 topic and may be write something more detailed :).
44
45 George
46
47
48 On Sunday 16 June 2002 16:11, Rufiao wrote:
49 > The abuse of this kind of system should be taken into account, since it may
50 > be quite easy for someone to create a bot (or whatever) capable of feeding
51 > the system with fake data, and by consequence destroy its reputation.
52 >
53 > However, I agree this issue should not complicate the system setup. There
54 > are problems with the approach I've described, in particular for users who
55 > maintain more than a couple of Gentoo boxes (it may be inconvenient even
56 > for people who run more than one machine, due to the fact it's necessary to
57 > have one key per machine).
58 >
59 > Debian's popularity-contest uses SMTP as its transport, both to avoid the
60 > need for constant internet connection and to have some means to ensure the
61 > identity of every contributing machine. I'm not sure SMTP can help on the
62 > identification of users at all, and it may complicate the setup even more
63 > for users who don't have local MTA spools set (and which want to
64 > participate but don't have constant connectivity), so I've discarded it.
65 >
66 > Also, using the machine's IP addresses as a measure of abuse (by
67 > investigating how many posts occur for a given address) may lead to bad
68 > results, since some users have more than one machine under a 1:n NAT.
69 >
70 > In the end, it may be better to simply avoid the signup, and use some
71 > 'loose' approach, which is to ask the user's e-mail to be used just in the
72 > case of abuse detection (of course a 'bad' user could provide a fake e-mail
73 > address, but in this case, after the detection of abuse and a unsucessful
74 > attempt to contact the user, all his provided data can be set to be
75 > automatically rejected by the server-side system).
76 >
77 > But it may happen there's a better approach for this whole problem.. Any
78 > thoughts?
79 >