RootsWeb.com Mailing Lists
Total: 1/1
    1. Re: [BOARD-L] Fred's Formal Complaint
    2. jpowelljr
    3. Very Good points Teri... I'll add some of my thoughts... Jim Teri Pettit wrote: > > 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? This may be worthwhile. I believe he would like for us to concentrate on a "Neutral" Server. (Personal Opinion here ... You could not have found much more of a neutral server than Rootsweb was on this election, but the appearance and the possibility were there.) > 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. I would like to see each SC keep a current voter list and then post it on a state website at a set time before each election, allowing for a period of time to accept challenges or additions of missing eligible voters. When the Election Committee receives these lists all they should have to do is remove any duplicates that cross state lines within Regions or any duplicates that cross region lines in the Project wide races. > "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. I more or less agree with this, see above comment. I have also previously commented on the comments below. > "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? Right... Nobody actually approved the first system. But portions of it had been used before. The second system actually had more votes cast with less complaints. And the system allowed us to deal with complaints in a much more efficient manner. > > 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. I wasn't comfortable with it either. The date on the page was based on earlier discussions on Election-L. After the Board approved the 18th, we were worried about debugging the system and no one caught the erroneous date. The Vote of the Election Committee was to follow the time table adopted by the Board, change the date on the page and notify everyone that had not voted of the ending date. > 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? Fred and his campaign manager did request a list of votes with the time they were made, no names, no email addresses. I have created such a list. The Election Committee decided that the Board should decide if it should be released. > Teri Pettit > pettit@adobe.com > CC Rep, SE/MA region

    09/09/1999 07:24:44