At 11:34 PM -0700 9/8/99, Tim Stowell wrote: >Do I hear a motion regarding Fred's Formal Complaint? Can we ask Fred what action he wanted to see taken in response to his protest? He said "Be advised that I am protesting..." and then listed 6 objections to the run-off election process, but the only action he specifically requested was that "a copy of this Formal Protest be posted to BOARD-L@rootsweb.com." Which has already been done. If he simply wanted to get his objections officially logged, then we're done with the Formal Protest per se. However, I can envision some changes being made for next year's elections that might prevent similar complaints from arising, so maybe we ought to start working on some changes to the election process. "1. No certified lists of eligible voters were ever published." The Election Committee did the best they could with the time they had, but we should have got things moving early enough that they weren't so rushed. The Election Committee shouldn't have had to go around gathering email addresses from state web pages. SC's are supposed to send in their lists, but what happens when they haven't by the time the ballots need to go out? The regional SC and CC and Special Project voter lists need to be maintained continuously. And a procedure for what it means to "certify" them should be defined. "2. The election was not conducted by a neutral third party, but by an organization, Rootsweb.com, Inc., which had a vested interest in the outcome of the election" It is inaccurate to say that the election was conducted "by" Rootsweb. It was conducted by the Election Committee, some of whom have nothing whatsoever to do with Rootsweb. Nevertheless, it was conducted using software and accounts on a Rootsweb server, and given that there are controversies over Rootsweb's relationship with The USGenWeb Project, it would probably help allay fears if the election process did not use any Rootsweb accounts. Unfortunately, it is not easy to find a neutral third party who is so willing to let us write custom scripts to be run on their servers, and which an experienced programmer who is a member of the Election Committee has an account on. Given the tight time constraints, it was probably the best that could be done. But with sufficient time to search, can next year's Election Committee try to find such a neutral third party? "3. The change in software for the run-off election was not approved by the Advisory Board." I don't personally think the Advisory Board should need to approve election software. That's what the Election Committee has expertise on, that's what we pick them for, and they're just as neutral as the Advisory Board, maybe more so. Has the Board ever approved ANY of the election software before? But, I'm all for majority rule, so rather than going on my personal opinion, I would favor polling the CC's as to whether they think that future election software should be approved by the Advisory Board. "4. The software used in the 2nd election was insecure. Anyone with FTP access to the software and data could have easily hacked the results." This could be said about any election conducted anywhere. While strictly speaking it is true that "anyone with FTP access to the software and data could have [feasibly] hacked the results" (although not 'easily', since it would also require expertise in how the software worked), what the statement ignores is that EXTREMELY few people have "FTP access to the software and data" and the technical know-how to hack it. It isn't sufficient to have FTP access to the server, one would need at the very minimum the password to the election account. It would be hard to write an election script running anywhere that couldn't be hacked by the owners of the account that it runs on. (Maybe some kind of double key system, where multiple copies of data and program are stored on different servers, and the owner of each account does not have access to the other, but if you could hack one program you might be able to make it fool the other, so I'm not sure even then.) The software used was as secure as it is reasonable to expect polling software to be. Since the only people with the level of access to an account that would be necessary to hack it are the programmers of the software and the system administrators of the server that it runs on, rather than concentrating on programming a paranoic level of security into the software itself, it should suffice to have procedures for guaranteeing the neutrality of anyone who has "wizard" access to it. Hence there is no substantial difference between point 4 and point 2. "5. Although voting closed on 8/18/1999, the web page http://www.usgenweb.org/elections/election-central.html indicated that the polls would not close until the 23rd." I wasn't comfortable with this, either. Even though the web page was wrong, and everyone who hadn't voted was informed by email of the correct closure date, it was a short enough difference that I think the longer date should have been given precedence. It's like when a wrong (and lower) price is printed in a newspaper ad - it will usually be honored unless the difference is extreme. The 23rd was a week before the term began. But, it's water under the bridge by now. The same problem is unlikely to arise next year. "6. Requests by myself for additional data necessary to attempt to determine if results were valid based on software used, etc. were denied." Not sure what this refers to. Fred was sent every line of the software, a description of the double-check procedures, and the certified statements of all the election committee members that the procedures had been followed. It would be a serious breach of voter privacy to release the names of the voters and how they voted, and I would hope that no candidate would have even requested such a list. If anyone made such a request, certainly it should be denied. So, if not that, what else was this "additional data" that was requested and denied? Teri Pettit pettit@adobe.com CC Rep, SE/MA region