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.

> 
> > > 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 the
> > 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.
> 
> Timing correlation in when a vote or stub appears in the system is a
> concern in that environment.
> 
> 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 interested
> > > 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.

> 
> > > 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 around),
> > > 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 interested
> > > 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.

-- 
Best regards,
Michał Górny