Reaffirm public voting
======================
Since we can either have secret and intransparent voting, or we can have
open and transparent voting, the project resolves to leave our voting
system as it is.
Rationale:
The GR proposal for secret voting is silent on implenentation details, probably because secret and transparent voting is, well, impossible to achieve fully, so this GR is bound to a similar fate as the 'publish debian-private' vote, which was voted for and then was never implemented.
A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.
And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.
I'm seeking sponsors for this amendment to the current GR.
Mattia Rizzolo <mattia@debian.org> wrote on 04/03/2022 at 12:03:22+0100:
[[PGP Signed Part:Signature made by expired key 0816B9E18C762BAD Mattia Rizzolo <mattia@mapreri.org> ]]
On Fri, Mar 04, 2022 at 10:42:51AM +0000, Holger Levsen wrote:
Reaffirm public voting
======================
Since we can either have secret and intransparent voting, or we can have >> open and transparent voting, the project resolves to leave our voting
system as it is.
Rationale:
The GR proposal for secret voting is silent on implenentation details,
probably because secret and transparent voting is, well, impossible to
achieve fully, so this GR is bound to a similar fate as the 'publish
debian-private' vote, which was voted for and then was never implemented. >>
A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.
And then, early 2022 is not the time for rushed changes like this, which >> is also why I explicitly want to see "keep the status quo" on the ballot, >> and not only as "NOTA", but as a real option.
I'm seeking sponsors for this amendment to the current GR.
Assuming you meant this as "this ballot" instead of "this amendment" (following the new GR flow), I sponsor this.
If I were to add my thoughts: political GRs don't belong in Debian,
please take them elsewhere. For non-political votes there is no use
for private voting.
Is init systems GR a political GR?
I'm pretty sure some gave double thoughts before voting because of the shitstorm/flame that had happened before the vote.
On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:
Mattia Rizzolo <mattia@debian.org> wrote on 04/03/2022 at 12:03:22+0100:
[[PGP Signed Part:Signature made by expired key 0816B9E18C762BAD Mattia Rizzolo <mattia@mapreri.org> ]]
On Fri, Mar 04, 2022 at 10:42:51AM +0000, Holger Levsen wrote:
Reaffirm public voting
======================
Since we can either have secret and intransparent voting, or we can have >>>> open and transparent voting, the project resolves to leave our voting
system as it is.
Rationale:
The GR proposal for secret voting is silent on implenentation details, >>>> probably because secret and transparent voting is, well, impossible to >>>> achieve fully, so this GR is bound to a similar fate as the 'publish
debian-private' vote, which was voted for and then was never implemented. >>>>
A voting system which is transparent only to some, is undemocratic and >>>> will lead to few people in the know, which is diagonal to Debians goals >>>> of openness and transparency.
And then, early 2022 is not the time for rushed changes like this, which >>>> is also why I explicitly want to see "keep the status quo" on the ballot, >>>> and not only as "NOTA", but as a real option.
I'm seeking sponsors for this amendment to the current GR.
Assuming you meant this as "this ballot" instead of "this amendment"
(following the new GR flow), I sponsor this.
If I were to add my thoughts: political GRs don't belong in Debian,
please take them elsewhere. For non-political votes there is no use
for private voting.
Is init systems GR a political GR?
I'm pretty sure some gave double thoughts before voting because of the
shitstorm/flame that had happened before the vote.
Not only that, but also conflicts of interest involving an employer may
have influence over a non-political vote (or the willingness to vote).
This has been argued already it seems.
Bests,
--
Tiago
[[PGP Signed Part:Signature made by expired key 0816B9E18C762BAD Mattia Rizzolo <mattia@mapreri.org> ]]
On Fri, Mar 04, 2022 at 10:42:51AM +0000, Holger Levsen wrote:
Reaffirm public voting
======================
Since we can either have secret and intransparent voting, or we can have
open and transparent voting, the project resolves to leave our voting
system as it is.
Rationale:
The GR proposal for secret voting is silent on implenentation details,
probably because secret and transparent voting is, well, impossible to
achieve fully, so this GR is bound to a similar fate as the 'publish
debian-private' vote, which was voted for and then was never implemented.
A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.
And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.
I'm seeking sponsors for this amendment to the current GR.
Assuming you meant this as "this ballot" instead of "this amendment" (following the new GR flow), I sponsor this.
If I were to add my thoughts: political GRs don't belong in Debian,
please take them elsewhere. For non-political votes there is no use
for private voting.
On Fri, Mar 04, 2022 at 10:42:51AM +0000, Holger Levsen wrote:
Reaffirm public voting
======================
Since we can either have secret and intransparent voting, or we can have open and transparent voting, the project resolves to leave our voting system as it is.
Rationale:
The GR proposal for secret voting is silent on implenentation details, probably because secret and transparent voting is, well, impossible to achieve fully, so this GR is bound to a similar fate as the 'publish debian-private' vote, which was voted for and then was never implemented.
A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.
And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot, and not only as "NOTA", but as a real option.
I'm seeking sponsors for this amendment to the current GR.Assuming you meant this as "this ballot" instead of "this amendment" (following the new GR flow), I sponsor this.
On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bcue wrote:
I'm pretty sure some gave double thoughts before voting because of the shitstorm/flame that had happened before the vote.
This has been argued already it seems.
Is init systems GR a political GR?
On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote:
On Fri, Mar 04, 2022 at 10:42:51AM +0000, Holger Levsen wrote:
Reaffirm public votingAssuming you meant this as "this ballot" instead of "this amendment"
======================
Since we can either have secret and intransparent voting, or we can have >> > open and transparent voting, the project resolves to leave our voting
system as it is.
Rationale:
The GR proposal for secret voting is silent on implenentation details,
probably because secret and transparent voting is, well, impossible to
achieve fully, so this GR is bound to a similar fate as the 'publish
debian-private' vote, which was voted for and then was never implemented. >> >
A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.
And then, early 2022 is not the time for rushed changes like this, which >> > is also why I explicitly want to see "keep the status quo" on the ballot, >> > and not only as "NOTA", but as a real option.
I'm seeking sponsors for this amendment to the current GR.
(following the new GR flow), I sponsor this.
yes, that's what I ment, thanks. Do I need to resent my mail now with this change? :)
On Fri, Mar 04, 2022 at 10:42:51AM +0000, Holger Levsen wrote:
Reaffirm public voting
======================
Since we can either have secret and intransparent voting, or we can have open and transparent voting, the project resolves to leave our voting system as it is.
Rationale:
The GR proposal for secret voting is silent on implenentation details, probably because secret and transparent voting is, well, impossible to achieve fully, so this GR is bound to a similar fate as the 'publish debian-private' vote, which was voted for and then was never implemented.
A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.
And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot, and not only as "NOTA", but as a real option.
I'm seeking sponsors for this amendment to the current GR.
Assuming you meant this as "this ballot" instead of "this amendment" (following the new GR flow), I sponsor this.
If I were to add my thoughts: political GRs don't belong in Debian,
please take them elsewhere. For non-political votes there is no use
for private voting.
Holger Levsen <holger@layer-acht.org> writes:
On Fri, Mar 04, 2022 at 12:03:22PM +0100, Mattia Rizzolo wrote:
On Fri, Mar 04, 2022 at 10:42:51AM +0000, Holger Levsen wrote:
Reaffirm public votingAssuming you meant this as "this ballot" instead of "this amendment"
======================
Since we can either have secret and intransparent voting, or we can have >> > open and transparent voting, the project resolves to leave our voting
system as it is.
Rationale:
The GR proposal for secret voting is silent on implenentation details, >> > probably because secret and transparent voting is, well, impossible to >> > achieve fully, so this GR is bound to a similar fate as the 'publish
debian-private' vote, which was voted for and then was never implemented.
A voting system which is transparent only to some, is undemocratic and >> > will lead to few people in the know, which is diagonal to Debians goals >> > of openness and transparency.
And then, early 2022 is not the time for rushed changes like this, which >> > is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.
I'm seeking sponsors for this amendment to the current GR.
(following the new GR flow), I sponsor this.
yes, that's what I ment, thanks. Do I need to resent my mail now with this change? :)
I sponsor this.
While I may not end up voting for it as my first option, I think it
deserves to be an explicit option, because I can imagine that no super-majority emerges in this vote, and if that happens then we will be
able to draw rather different conclusions about the project consensus depending upon whether this option comes above or below NotA (and by how much).
Cheers, Phil.
On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote:
Is init systems GR a political GR?
yet there are people maintaining systemd and sysv in public.
The GR proposal for secret voting is silent on implenentation details, probably because secret and transparent voting is, well, impossible to achieve fully, [...]
A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.
Hi,
I think we can establish a limitation between "secret" and "wiser
secret". I can understand that making vote transparent and secret is
likely not possible. And I am not sure that it is the purpose. The
purpose is not to see displayed on a public website one name related
to a GR and a vote.
In other words, while I dont think someone will do a detailed
investigation to know who voted what (most people just will not want
to spend energy for this), anyone, including with malicious purpose,
can visit a web page to see what I voted and do harasment
then.
While I accept not to be in a full secret, as I am not afraid with
persons who can do harasment to spend so energy to find this info in
a deep server or via a hash or whatever, I am worry bif any mad guy
can see what I voted about a GR as I know the person will not
hesitate to attack me. Again, we have an example of this, of high
flame, during RMS GR, and while the most radical persons probably
did not want to do deep investigations about voters, I think they
were ready to visit a page and go after voters. I dont know if it
happent effectively, but given how the vote happent with trials to
disturb after the campaign time, it is possible.
The last thing which may justify a such ballot is the idea that "if you dont want to see your name related to a vote, just dont vote, you dont have to do it, you are free". this may be acceptable for political GRs, but more a problem for ambiguous situations.
Hence the importance to make secret possible at least, if not general and mandatory.
Reaffirm public voting
======================
Since we can either have secret and intransparent voting, or we can have
open and transparent voting, the project resolves to leave our voting
system as it is.
Rationale:
The GR proposal for secret voting is silent on implenentation details, probably because secret and transparent voting is, well, impossible to achieve fully, so this GR is bound to a similar fate as the 'publish debian-private' vote, which was voted for and then was never implemented.
A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.
And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.
I'm seeking sponsors for this amendment to the current GR.
A voting system which is transparent only to some, is undemocratic and
will lead to few people in the know, which is diagonal to Debians goals
of openness and transparency.
I'm not sure what you mean here. From some point of view, TLS is also transparent "only to some", since very few people understand the
mathematics behind the crypto involved there. Yet, we don't promote
unsecured communications where a TLS-secured variant exists.
Hello,
Le 04/03/2022 11:42, Holger Levsen a crit:
The GR proposal for secret voting is silent on implenentation details, probably because secret and transparent voting is, well, impossible to achieve fully, [...]
It is possible to achieve some reasonable level of secrecy and
transparency (and verifiability)... it is an active research topic per
se. Belenios came out of this research, devotee-ng could also benefit
from this research.
Disclaimer: I am upstream of Belenios in my dayjob.
And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.
Hi Holger (2022.03.04_10:42:51_+0000)
And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot, and not only as "NOTA", but as a real option.
If we were to have such an option on the ballot, my understanding of constitution 4.2.4 is that we'd have both "keep the status quo" and
"NOTA" as ballot options.
And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.
Holger Levsen <holger@layer-acht.org> writes:
And then, early 2022 is not the time for rushed changes like this, which
is also why I explicitly want to see "keep the status quo" on the ballot,
and not only as "NOTA", but as a real option.
We've been talking about secret votes for about nine months now, so I'm
not sure "rushed" is the word that you're looking for. Concretely, it's leaving me unclear what would make the change feel not rushed to you.
I understand if you are opposed to secret voting in general, but this
feels like a different objection than general opposition to the idea.
Could you be a bit clearer about what would make a proposal not rushed (whether or not you would then support it)? Are you specifically asking
that we agree on the full details of implementation before passing a GR allowing for it? Or something else?
When considering a voting system, there are a few important things to consider [1]:
1- vote-privacy: the fact that a particular voter voted in a particular
way is not revealed to anyone.
2- Receipt-freeness: a voter does not gain any information (a receipt)
which can be used to prove to a coercer that she voted in a certain way.
3- Coercion-resistance: a voter cannot cooperate with a coercer to prove
to him that she voted in a certain way.
4- Individual verifiability: a voter can check that her own ballot is included in the election's bulletin board.
5- Universal verifiability: anyone can check that the election outcome corresponds to the ballots published on the bulletin board.
6- Eligibility verifiability: anyone can check that each vote in the
election outcome was cast by a registered voter and there is at most one
vote per voter.
If I understand well the problem, we can't have all of the above. That's technically not possible, with the current state of knowledge on earth.
I haven't read enough on the topic, but I believe that's the case. If
anyone has read more and would like to explain, please do...
The current proposal, if I understand well, is that we would like to
enforce 1- and 3-. I'm somewhat ok with it, but I very much value 4-, 5-
and 6- above 1-, 2- and 3-.
I am unsure about what Holger has in mind, but for me, yes, I do want to
know about the full details of implementation to make sure we have 4-,
5- and 6-, which we currently have with a fully public voting system. Just voting on "I want my vote to be secret" without having any information
about the other properties is IMO completely silly and looses the point.
[...] Just
voting on "I want my vote to be secret" without having any information about the other properties is IMO completely silly and looses the point.
Sam's GR intentionally leaves the details open to the Project Secretary to determine. I understand why people might object to that and would prefer
to require a GR for any change to the process.
I just wouldn't
characterize that as "rushed" (it's a deliberate choice, and hasn't been
made in a hurry so far as I can tell), so wasn't sure if that was the objection here or if there was something else I was missing.
And I'd call this 'rushed' still. If someone promises foo without explaining how foo should be achieved and then a vote is held to mandate foo, I'd call this 'rushed'. Even if there has been talk about foo for a year, which btw, by Debian standards, is not a long time.
* Thomas Goirand <zigo@debian.org>:
2- Receipt-freeness: a voter does not gain any information (a receipt)
which can be used to prove to a coercer that she voted in a certain way.
6- Eligibility verifiability: anyone can check that each vote in the
election outcome was cast by a registered voter and there is at most one
vote per voter.
Property 2 is violated if the vote is confirmed in a signed email like
the public votes (I can't say because I never participated in a DPL
election yet).
Property 6 is violated, because you can trivially add arbitrary
ballots with random HMAC_SHA256_HEX values (unless the voter turnout
is 100%, which seems rather unlikely).
1- vote-privacy: the fact that a particular voter voted in a particular
way is not revealed to anyone.
2- Receipt-freeness: a voter does not gain any information (a receipt)
which can be used to prove to a coercer that she voted in a certain way.
3- Coercion-resistance: a voter cannot cooperate with a coercer to prove
to him that she voted in a certain way.
4- Individual verifiability: a voter can check that her own ballot is included in the election's bulletin board.
5- Universal verifiability: anyone can check that the election outcome corresponds to the ballots published on the bulletin board.
6- Eligibility verifiability: anyone can check that each vote in the
election outcome was cast by a registered voter and there is at most one
vote per voter.
I'm personally more interested in using something like Belenios than just >replicating the DPL election scheme mostly because I'm unsure that the DPL >election scheme has had sufficient security analysis and I'd prefer to seeThat analysis is quickly done:
us move onto the firmer footing of a voting system that's had a published >rigorous analysis of its properties and I'm not aware of one for our
current DPL election system. (I would love to be corrected if one does >exist.)
I'm not sure that I see this for DPL elections because we publish both the >list of votes and the list of voters. If those two lists aren't the same >length, that's fairly trivially detectable.You're right, I missed that when I looked at the election
When considering a voting system, there are a few important things to consider [1]:
1- vote-privacy: the fact that a particular voter voted in a particular way is not revealed to anyone.
2- Receipt-freeness: a voter does not gain any information (a receipt) which can be used to prove to a coercer that she voted in a certain way.
3- Coercion-resistance: a voter cannot cooperate with a coercer to prove to him that she voted in a certain way.
4- Individual verifiability: a voter can check that her own ballot is included in the election's bulletin board.
5- Universal verifiability: anyone can check that the election outcome corresponds to the ballots published on the bulletin board.
6- Eligibility verifiability: anyone can check that each vote in the
election outcome was cast by a registered voter and there is at most one
vote per voter.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 48:35:39 |
| Calls: | 6,710 |
| Calls today: | 3 |
| Files: | 12,243 |
| Messages: | 5,354,640 |
| Posted today: | 1 |