From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI, NICE_REPLY_A autolearn=unavailable autolearn_force=no version=4.0.0 Received: from vestibule.its.caltech.edu (vestibule.its.caltech.edu [131.215.48.17]) by chiba.3jane.net (Postfix) with ESMTP id A7F31ABD6B for ; Tue, 18 Jun 2002 05:38:53 -0500 (CDT) Received: from groug.home.net (PPP-36-207.caltech.edu [131.215.36.207]) by vestibule.its.caltech.edu (8.12.3/8.12.3) with ESMTP id g5IAcmk7024360 for ; Tue, 18 Jun 2002 03:38:49 -0700 (PDT) Content-Type: text/plain; charset="windows-1251" From: George Shapovalov To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] RFP: System to account users configurations Date: Tue, 18 Jun 2002 03:37:25 -0700 User-Agent: KMail/1.4.1 References: <20020616201137.45573567.rufiao@gmx.net> In-Reply-To: <20020616201137.45573567.rufiao@gmx.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200206180337.26484.georges@its.caltech.edu> Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 2bf12d22-3266-4e72-b228-026b095077e3 X-Archives-Hash: b955cabc76c0a621670283a6d417d38a Hi guys. Nice to see voting/user feedback discussed here! I have spent some time few month ago thinking about similar issue. I woul= d=20 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=20 should give you an idea about its status :)) that system for a very speci= fic=20 purpose - to enhance quality control over ebuilds by allowing all users t= o=20 cast their votes indicating ebuild stability and (optionally) popularity.= =20 Accumulation of additional information may provide nice statistics. Howev= er I=20 would like to add one "feature request" to Rufiao's proposal. Namely the=20 ability to configure what kinds of information are collected and sent=20 upstream. As I see there are two possible approaches towards design of voting syste= m: 1. active system - passive users 2. passive system - active users In reality any reasonable voting system should include elements of both,= the=20 question is more about proportions :). In that text I was leaning more=20 towards second option. You will find few arguments behind my thinking.=20 Nonetheless the system I was in the end describing seems to be very simil= ar=20 to the one proposed by Rufiao :), including concerns about use of ips for= =20 identification and requirement to register. Though overall procedure look= s a=20 bit simplier. Along the same lines there are two "boundary" positions WRT how much=20 information is collected and processed. 1. Collect info about individual systems in central location and use that= to=20 build statistics. (pretty much necessary for 1st approach) 2. Only keep statistical info centrally and update it when user votes. Ma= y=20 play well with 2nd approach if done correctly. As was pointed out second position raises abuse concerns. However I would= =20 still prefer such approach if some care could turn up a reasonably secure= =20 model. At least it would be worth to try that as a first implementation, = as=20 it is much easier on resources and implementation. Sorry about this rough posting, just wanted to bring up that link in case= you=20 will be able find anything usefull there :). I will try to get back to th= is=20 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 feed= ing > the system with fake data, and by consequence destroy its reputation. > > However, I agree this issue should not complicate the system setup. The= re > 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 eve= n > for people who run more than one machine, due to the fact it's necessar= y to > have one key per machine). > > Debian's popularity-contest uses SMTP as its transport, both to avoid t= he > 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 t= he > identification of users at all, and it may complicate the setup even mo= re > 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= =2E > > 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 unsucessf= ul > 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.. An= y > thoughts? >