From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AA8F6138334 for ; Fri, 6 Sep 2019 05:20:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EA7D5E07FA; Fri, 6 Sep 2019 05:20:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BCB84E07FA for ; Fri, 6 Sep 2019 05:20:37 +0000 (UTC) Received: from pomiot (c134-66.icpnet.pl [85.221.134.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id E120934AD22; Fri, 6 Sep 2019 05:20:35 +0000 (UTC) Message-ID: Subject: Re: [gentoo-nfp] [RFC] Alternative methods for determining 'interest in Foundation affairs' From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-nfp@lists.gentoo.org Date: Fri, 06 Sep 2019 07:20:31 +0200 In-Reply-To: References: Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-e3+rK6LwLMWn9JJq7v3y" User-Agent: Evolution 3.30.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-nfp@lists.gentoo.org Reply-To: gentoo-nfp@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: 238cf725-d32b-4364-93d6-6ceeeb999a23 X-Archives-Hash: 6ce04082fac759db0e8448f54b6dba76 --=-e3+rK6LwLMWn9JJq7v3y Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2019-09-05 at 22:42 +0000, Robin H. Johnson wrote: > If you consider various real world voting systems, they generally > require some form of electoral roll, on which voters are checked off, to > prevent voting multiple times (this can be enforced with other > mechanisms). Sure but I should point out that generally: 1. The people who are checking you off generally try to cover other voters on the list. 2. They don't have a real way of associating your vote with your check off. So I don't think examples of 'real life' voting systems are really relevant, unless they are 100% electronic and are subject to the same inherent weaknesses as we are. However, even then the scale might make sniffing votes impractical. >=20 > > > 2. It introduces a big weakness in the system. My whole idea was to > > > make it practically impossible to sniff votes after the election is > > > prepared. With this solution, anyone with sufficient privileges > > > (election officials, infra) can trivially passively sniff votes. > > We need to know who cast votes, we don't need to know the content of th= e > > votes. I assume building such a system is possible (maybe it isn't?) > mgorny's system design is explicitly around building protections to > enable LESS trust being placed in infra & voting officials. >=20 > Timing correlation in when a vote or stub appears in the system is a > concern in that environment. >=20 > I agree that it should be possible to build this requirement into the > system, but at what cost in development. To be honest, I can't really think of a reasonable way to do that. We have simply too few votes spread over too much time. > > > I believe we should consider other options of determining activity. > > > Depending on whether we actually want to keep people actually interes= ted > > > in GF, or just those caring enough to stay, I can think of a few > > > options. > I'd say those options should be in addition to, rather than instead of > voting. Why? What is the difference, say, between casting a vote and pushing a 'I am active' button once a year? If the latter's an option, there's really no point in leaking voting information just to have two alternatives. >=20 > > > Another option (which some people aren't going to like) is to require > > > all Foundation members to be Gentoo devs (but not the other way aroun= d), > > > and then terminate GF membership along with developer status. Given > > > that there's only a few non-dev members, and most of them are retired > > > devs whose membership simply didn't terminate by existing rules yet, = I > > > think there shouldn't really be a problem in making the few intereste= d > > > members non-commit devs by existing rules. > > This doesn't really imply interested in the Foundation either though; > > because the developership and Foundation are separate. > If this includes making non-commit developership easier to > get AND maintain (the undertaker discussions about how to gauge > ongoing involvement of non-commit devs is very relevant to this), then I > have no conceptual problem with requiring all Foundation members to be > developers (It should still be possible to be a developer WITHOUT being > a Foundation member). That is the point. However, we need solid proposals for this. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-e3+rK6LwLMWn9JJq7v3y Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl1x7J9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA57GQf/WFVKrOaddv6I/nNxVwKotz40lGrIAHjL88cqX+UAJLqWVbDWuxMX5RJQ c1HuG+w+2PHx83WQybqGbesCepxjH/WctfeDmIatWDUOkyRsH13MQtdFGKSp6vSO Z/X/3or7VINSF/l45Bnw81tQjrce5r/jsepr6N/ugd2m6GRxjiHF0QFazd+EC/Fm QSjw9MANukEX34y7HKi+GZ0nf0AweUIcYONQ8ci2CMCzh2FC8Ovo8Xr4AGdTgF+2 czlYvcrVkKaShzLel+D99c58Y8iItsENXvFkigI0vLyeR9ol5ASTrrtN1NBreJxw 5AM5ObKvI/5CwrqWDXswxbdBEGZtYA== =Ul3q -----END PGP SIGNATURE----- --=-e3+rK6LwLMWn9JJq7v3y--