From paul.suh at ps-enable.com Tue Sep 12 01:30:31 2006 From: paul.suh at ps-enable.com (Paul Suh) Date: Tue Sep 12 01:30:41 2006 Subject: [Newsletter] MOSXSWebPassword and some more Plone sites (#8) Message-ID: <9658BBCD-C45E-4728-B588-6031516E718C@ps-enable.com> Folks, Mac OS X Server Web Password 1.0 -------------------------------------------------- I've updated my Mac OS X Server Web Password application so that the installer package now works properly, and added a page where an administrator can reset a user's password. If you're already using version 0.9, the upgrade should just go on top of the existing package seamlessly. The application is written in WebObjects, which is in turn based on Java. This is nice from a number of points of view, but for changing passwords it has one serious downside: you can't make any system calls directly. One of the key points behind Java is that it runs the same anywhere -- on a Mac, on a Windows server, on a Linux box, on a Solaris box; but this means that you can't make operating-system specific calls from your Java code directly. You need to use the Java- Native Interface (JNI) to make operating system calls, which is what I did in the files OpenDirJNI.c and OpenDirJNI.java. An alternative approach would be to call the passwd binary from within the WebObjects application. However, this has a serious security hole -- if someone is in a position to run /bin/ps on your server at the right time, they might be able to see the user's new password being passed as a command line argument to passwd. I use direct Open Directory API calls instead, which don't have this vulnerability. Using the Open Directory API's also opens up a set of tricks that you couldn't do using passwd. If your Mac OS X Server is bound to an Active Directory domain, Mac and Windows users can use the web page to change their AD passwords by editing the file /Library/WebObjects/ Applications/MOSXSWebPassword.woa/Contents/Resources/Properties. Change the line that reads: directoryNodeList=("/NetInfo/root","/LDAPv3/127.0.0.1") to read: directoryNodeList=("/NetInfo/root","/ActiveDirectory/AllDomains") then stop and re-start the WebObjects service in Server Admin. If your web server is not your Open Directory master, change the LDAPv3 entry so that it points at the correct LDAP server. E.g., if your OD master is at 192.168.17.33, then change the directoryNodeList to be: directoryNodeList=("/NetInfo/root","/LDAPv3/192.168.17.33") then stop and restart the WebObjects service. It's free, released under the GNU GPL, and source code is available. Give it a try and let me know how it works for you. You can download it from my website at: http://ps-enable.com/software/MOSXSWebPassword_1_0.dmg/view Plone Sites ----------------- Just to give you an idea of what you can do with Plone, here are a few Plone sites that I've set up recently: http://ncac-cubscoutspack8.org/ http://ccespta.org/ http://btrcapitalgroup.com/ The ccespta.org website is the closest to the basic Plone appearance, with only a change to the logo graphic and some re-ordering of the portlets in the left and right columns. The ncac-cubscoutspack8.org website is a more radical makeover, with some serious CSS work to change the color scheme and some workflow security work to hide some folders. In particular, there are members-only folders that don't appear to people who are not logged into the website. The btrcapitalgroup.com website is a full appearance makeover, with heavy CSS modifications and graphic design work. The cub scouts website is hosted on a Mac Mini, with another Mac Mini serving as a caching front end. The other two websites are hosted at highspeedrails.com, using their Starter service at $340 per year. It's a pretty affordable way to set up a website where all you need is the ability to use Word in order to maintain the content on the website. --Paul Paul Suh http://www.ps-enable.com/ paul.suh@ps-enable.com (240) 672-4212 From paul.suh at ps-enable.com Tue Sep 19 11:47:44 2006 From: paul.suh at ps-enable.com (Paul Suh) Date: Tue Sep 19 11:48:06 2006 Subject: [Newsletter] Electronic voting machines, and why it's hard Message-ID: Folks, This newsletter is a bit ahead of schedule, but I've got something else on tap for next week and this newsletter is timely. Voting System Failures in Maryland We just received a gilt-edged reminder of just how fragile our democracy is here in Maryland. In Montgomery county, where I live, the voter access cards for the Diebold voting machines were not distributed to the precincts before the election started. As a result, many people were unable to vote in the morning until the Board of Elections was able to send the cards over by courier. People voted on paper provisional ballots, until the precincts ran out of the provisional ballots. Some places resorted to photocopying ballots. Polls were ordered to stay open an hour later than scheduled, but this still doesn't compensate for people like my neighbor Scott, who had to leave on a plane that afternoon. This was a garden variety logistical screw up with no direct connection to the electronic voting machines. However, the Diebold system did have an indirect effect, via the Keep It Simple, Stupid principle. The Diebold system has many elements -- the cards, the voting machines themselves, power requirements, the technical support, the setup instructions for modem connections, etc. The probability of a problem arising is directly proportional to the number of things that the logistics people need to keep track of. Adding in the Diebold electronic poll books for this election squared the complexity of the system. Is it really surprising that there was a logistical snafu? To compound the problem, the current system does not have obvious ways to degrade gracefully. It either works or it doesn't -- and if it doesn't then the result is chaos. It is possible to design a system that does degrade gracefully -- the space shuttle is an example, albeit an imperfect one. The engineers for the space shuttle have designed a system where a known potential failure point leads to a known path for recovery. To set this up takes time and skill and effort -- three elements that are in notoriously short supply among the people at the Maryland State Board of Elections. Even at NASA, they know that some failures are too catastrophic, and cannot be recovered from -- but at least they've thought through some of the possible failure modes. Note: one of the arguments that electronic voting machines proponents use is the human error argument. Electronic voting machines are supposed to take human error out of the equation. This last fiasco was the direct result of human error. How did electronic voting machines protect against human error in this situation? This is a perfect example of how electronic voting machines move the place where human error can occur from the individual voter to the programmer or the board of elections. Where previously an error would cause problems for an individual voter or at most a single precinct, now errors result in chaos county-wide or state-wide. People who know computer systems understand that the way to avoid these sorts of problems is to reduce the number of single failure points via redundancy -- RAID, failover, etc. The electronic voting machines have *no* redundancy, and are begging for failures. A good place to look for coverage on this issue is the Washington Post: http://www.washingtonpost.com/wp-dyn/content/article/2006/09/12/ AR2006091200535_pf.html http://www.washingtonpost.com/wp-dyn/content/article/2006/09/14/ AR2006091401614_pf.html http://www.washingtonpost.com/wp-dyn/content/article/2006/09/16/ AR2006091600804.html In the last article, there's an interesting quote: "Jensen [Jean Jensen, secretary of the Virginia State Board of Elections] said that not a single vote was lost in 2004 and that 8,000 to 10,000 voting machines were in use on Election Day." How can she prove this? In fact, it's an unprovable statement -- if you think about it, in an anonymous voting system you can only prove that a vote was lost. It is impossible to prove that a vote was *not* lost. Why Is It Hard to Create an All-Electronic Voting System? Why have the systems become so complex (beyond the desire for higher fees from the voting machine makers)? It's because they're facing a hard problem, whether or not they recognize it. I maintain that there are three fundamental elements to an election as we know it. I call them the three A's: 1) Accuracy - the votes must be counted accurately. 2) Anonymity - must not be able to tie a ballot to a voter after the fact. 3) Auditability - recounts can be done by anyone. Accuracy would seem to be a given -- if you can't get the count right it's not a good system. Yet, this is the place where traditional paper-based voting systems fail. Traditional paper-based systems are subject to human fallibility in determining the vote counts, but they were all we had until recently. Anonymity is now a given, although it was not always the case. Nevertheless, a cursory study of voting in the Tammany Hall era in New York City or voting in the Soviet Union leads quickly to the conclusion that this is a necessary condition for a fair election. Interestingly enough, most electronic record systems NOT associated with voting attempt to do the exact opposite -- they attempt to create an irrefutable trail associating a transaction with a person (non-repudiation). Auditability is critical to public confidence in elections. If Joe or Jane Citizen who has no specialized skills cannot reach the same counts as are posted, then there will be no public confidence in the election. It may take an ordinary person longer to reach the conclusion than the election system, but the result should be the same. And if the original count and the recount come up with different numbers, there must be a way to resolve the discrepancy. Any two of these requirements can be fulfilled easily enough. Straight paper-based systems (such as Florida's notorious hanging chads) sacrifice (1) in favor of (2) and (3). DRE's in their present form sacrifice (3) in favor of (1) and (2). A voting system based on digital signatures would sacrifice (2) in favor of (1) and (3). At least for now, the best choice are the precinct-based optical scan machines. These fulfill all three elements also provide for two additional goals: protectipm against mis-votes (alert to undervotes and prevent overvotes) and accessibility to other voters (such as the blind and visually impaired, or non-English speakers). Places to Go for More Information http://truevotemd.org/ http://blackboxvoting.org/ --Paul Paul Suh http://www.ps-enable.com/ paul.suh@ps-enable.com (240) 672-4212 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : http://mail.goodeast.com/pipermail/newsletter/attachments/20060919/92d65cd0/smime.bin From paul.suh at ps-enable.com Thu Sep 28 00:19:11 2006 From: paul.suh at ps-enable.com (Paul Suh) Date: Thu Sep 28 00:19:36 2006 Subject: [Newsletter] How to Split a Server part 3, How NOT to Test a System, and Request for Feedback Message-ID: Folks, How to Split a Server, part 3 I've posted part 3 of my article series, How to Split a Server on my website, and it should be up on http://afp548.com/ shortly. It covers separating out the e-mail and web parts of the example.org domain from the example.com domain, including forwarding old e-mail addresses, having the same address independently for both domains, and how to organize your web server's file system. http://ps-enable.com/articles/how_to_split_a_server_part_3.html How NOT to Test a System The Diebold electronic poll book system is designed to check in registered voters at a precinct -- not actually to record votes, but to make sure that a voter gets to cast only one ballot. It had a number of serious problems in the September 12 primary, but the egregious one that makes me really steamed is the one that Diebold supposedly just fixed. From the Washington Post article: http://www.washingtonpost.com/wp-dyn/content/article/2006/09/25/ AR2006092501480.html "Diebold technicians showed what happened to an unmodified e-poll book after 40 to 50 voters had registered: An error message appeared on the screen, displaying the words "can not continue;" the screen went black; and the unit rebooted, as if a polling judge had just turned it on." OK, this tells me that the software was never stress-tested -- this was a consistent, repeatable bug, the kind that is relatively easy to find and to fix. I can't believe that this was not caught -- 40-50 voters is not all that many at a given precinct. Since there are 5500 electronic poll book units and turnout for the last primary (2004) was 646,000 people, this gives a an average of 117 voter check-ins per electronic poll book unit. (That's an optimistically low number, by the way -- the voter turnout in the 2002 primary was 2.76 million.) The fact that the poll book units failed after less than half of that number is a sign that the units were not stress tested. "Then, Diebold technician Euel Kirk Cowal began registering voters on a unit with the modified software. Cowal reached 138 voters without a freeze. The Diebold executives, including one from the company's Texas headquarters and another from a subsidiary in California, looked relieved." OK, so at least one test unit exceeded the likely primary numbers. We would want to repeat the test multiple times to make sure that it's really fixed, but we'll give them that much. What about the general election? If you run the numbers, each electronic poll book should be tested to handle around 2500 voters check-ins. This is not that many voter check-ins by any standard. In other words, the software has been tested to 1/18th of the level it should be tested to. Bleah. That system should never have been deployed for the current election -- it hasn't passed reasonable acceptance tests. Request for Feedback This is now the tenth newsletter that I've sent out, and I'd like to get some feedback from you. What articles did you like or not like? Are there topics that you would like me to cover that I haven't so far? If you would like to see some of the back issues, all of my newsletters are archived on my website at http://ps-enable.com/ articles/newsletters/. --Paul Paul Suh http://www.ps-enable.com/ paul.suh@ps-enable.com (240) 672-4212 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2508 bytes Desc: not available Url : http://mail.goodeast.com/pipermail/newsletter/attachments/20060928/fe81ec0f/smime.bin