Post election idea

[Jim Jagielski <ji...@jaguNET.com>]

One thing that the previous STV code had was that if
the code running the election itself was changed, it
invalidated the running election. This was to prevent
someone from changing the software (say, by silently
dropping 'AC' from the counts) during the election
in order to change the election.

Again, there is some limit to how much we can really
do things: even the previous could be circumvented if
one was root after all. But it Good to do what we can,
imho.

Re: Post election idea

[Jim Jagielski <ji...@jaguNET.com>]

Like I said, there are true limits to what we can do,
but that doesn't mean we don't do what we can.

> On Mar 18, 2016, at 4:15 PM, Daniel Gruno <hu...@apache.org> wrote:
> 
> On 03/18/2016 09:07 PM, Jim Jagielski wrote:
>> One thing that the previous STV code had was that if
>> the code running the election itself was changed, it
>> invalidated the running election. This was to prevent
>> someone from changing the software (say, by silently
>> dropping 'AC' from the counts) during the election
>> in order to change the election.
> 
> But couldn't that in itself be circumvented by overriding that check?
> 
>> 
>> Again, there is some limit to how much we can really
>> do things: even the previous could be circumvented if
>> one was root after all. But it Good to do what we can,
>> imho.
>> 
> 
> The current system revolves around the base assumption that whoever has
> access as a 'vote admin' does not generally have access as a 'sys admin'
> to the actual system on the machine (iow shell/disk access) and thus
> can't change anything without the alarms going off (if you change
> election data during an election, big red letters appear and you get
> very afraid ;)).
> 
> Having said that, I'd love for us to work more on the credibility
> aspects of this and especially document best-practice for people that
> might not know how this is supposed to be set up. I don't know that we
> can create a fully tamper-proof system, but we can try :)
> 
> With regards,
> Daniel.

Re: Post election idea

[Daniel Gruno <hu...@apache.org>]

On 03/18/2016 09:07 PM, Jim Jagielski wrote:
> One thing that the previous STV code had was that if
> the code running the election itself was changed, it
> invalidated the running election. This was to prevent
> someone from changing the software (say, by silently
> dropping 'AC' from the counts) during the election
> in order to change the election.

But couldn't that in itself be circumvented by overriding that check?

> 
> Again, there is some limit to how much we can really
> do things: even the previous could be circumvented if
> one was root after all. But it Good to do what we can,
> imho.
> 

The current system revolves around the base assumption that whoever has
access as a 'vote admin' does not generally have access as a 'sys admin'
to the actual system on the machine (iow shell/disk access) and thus
can't change anything without the alarms going off (if you change
election data during an election, big red letters appear and you get
very afraid ;)).

Having said that, I'd love for us to work more on the credibility
aspects of this and especially document best-practice for people that
might not know how this is supposed to be set up. I don't know that we
can create a fully tamper-proof system, but we can try :)

With regards,
Daniel.