Monday, October 30, 2006

Global Warming Could Devastate Economy

The San Jose Mercury News has an AP article by Thomas Wagner on a new British report.

Unchecked global warming will devastate the world economy on the scale of the world wars and the Great Depression, a British government report said Monday, as the country launched a bid to convince doubters that environmentalism and economic growth can coincide...

Blair, President Bush's top ally in the Iraq war, said unabated climate change would eventually cost the world between 5 percent and 20 percent of global gross domestic product each year. He called for "bold and decisive action" to cut carbon emissions and stem the worst of the temperature rise.

"It is not in doubt that, if the science is right, the consequences for our planet are literally disastrous," he said. "This disaster is not set to happen in some science fiction future many years ahead, but in our lifetime." ...

"Our actions over the coming decades could create risks of major disruption to economic and social activity, later in this century and in the next, on a scale similar to those associated with the great wars and the economic depression of the first half of the 20th century," he said.

The report said at current trends average global temperatures will rise by 3.6 to 5.4 degrees within the next 50 years or so, and the earth will experience several degrees more of warming if emissions continue to grow.

Labels: ,


Saturday, October 28, 2006

Florida 2006

I can hardly wait. See this post from Avi Rubin.

[Other Sources]

[And Ohio]



Thursday, October 26, 2006

This time, Internet voting is being deployed

... and that's not good news. See Avi Rubin's post. Virtually every principle of secret ballots and secure voting is being violated by the DoD in their program to let members of the armed forces vote remotely this year.

Labels: , ,


Privacy Guidelines from Microsoft

I confess that I'm generally pretty skeptical of Microsoft's dedication to the rights and interests of consumers. However, I've just read their Privacy Guidelines for Developing Software Products and Services, Version 2.1, dated October 10, 2006, and I have to say that they've done a pretty good job. If all software products and services followed these guidelines, cyberprivacy would be in much better shape than it is now.

This is a very pragmatic document that starts from user concerns and the business case for addressing them, moves on to general principles and specific definitions, and finally gives fairly detailed guidelines for nine representative scenarios. I find it credible and sensitive to most of my concerns about electronic privacy.

Protecting customer privacy is critically important. In many areas of the world, privacy is considered a fundamental human right. Additionally, protecting customer privacy can increase loyalty and be a market differentiator.

Customers are getting increasingly frustrated with software and Web sites that do not clearly communicate the behaviors that impact customer privacy and the controls available to them. Currently, there are no industry-wide practices to help standardize the user experience and the software development process. For some, ignoring this growing frustration has led to an erosion of trust, negative press, and even litigation.

The software industry as a whole would benefit from establishing a higher bar for respecting customer privacy. Giving customers more information about how their privacy may be impacted (i.e., transparency) coupled with improved controls can empower customers and raise their level of trust. At the same time, it is important not to annoy customers with a barrage of notices that ultimately may be ignored.

The purpose of this document is to propose a baseline for establishing this higher bar. It offers guidance for creating notice and consent experiences, providing sufficient data security, maintaining data integrity, offering customer access, and supplying controls when developing software products and Web sites. These guidelines are based on the core concepts of the Organization for Economic Co-operation and Development (OECD) Fair Information Practices and privacy laws such as the EU Data Protection Directive, the U.S. Children's Online Privacy Protection Act of 1998 (COPPA), and the U.S. Computer Fraud and Abuse Act (as amended 1994 and 1996). In the interest of developing a common set of industry best practices for privacy, we invite the community and other interested parties to participate in an open dialogue...

The core principle driving these guidelines is:

Customers will be empowered to control the collection, use, and distribution of their personal information.
For customers to have control over their personal information, they need to know what personal information will be collected, with whom it will be shared, and how it will be used. In addition:
  • Customers must provide consent before any personal information is transferred from their computer.
  • If a customer's personal information is transferred over the Internet and stored remotely, they must be offered a mechanism for accessing and updating the information.
Before collecting and transferring personal information, you, as the entity requesting the information, must have a compelling business and customer value proposition. A value proposition that benefits customers may create a natural incentive for them to entrust you with their personal information. Only collect personal information if you can clearly explain the net benefit to the customer. If you are hesitant to tell customers "up front" what you plan to do with their information, then do not collect their data. This applies to data collected and stored locally on the customer's machine or transferred over the Internet...

One of the best ways to protect a customer's privacy is to not collect his or her User Data in the first place. The questions that should constantly be asked by architects, developers, and administrators of data collection systems include:

  • "Do I need to collect this data?"
  • "Do I have a valid business purpose?"
  • "Will customers support my business purpose?"
The answers must explicitly address both the primary use of the customer's data (such as providing the feature or service the customer is requesting) and any planned secondary use (such as marketing analysis). Only collect data for which there is an immediate planned use. In addition, only transfer data that is absolutely necessary to achieve the business purpose, reduce the sensitivity of the data retained (e.g., aggregate data where possible), and delete data that is no longer needed for the business purpose.

Another important area to consider is how customers will react to the collection of their data. For example, while one customer may appreciate product recommendations derived from his or her purchase history, another may see such personalization as an invasion of his or her privacy...

The longer data is retained, the higher the likelihood of accidental disclosure, data theft, and/or data growing stale. User Data should be retained for the minimum amount of time necessary to support the business purpose or to meet legal requirements. Any User Data stored by a company should have a retention policy that states how long the data should be kept and the manner in which it should be removed from all data stores...

All products and services that collect User Data and transfer it must provide an explanation ("give notice") to the customer. The customer must be presented with a choice of whether to provide the information, and consent must be obtained from the customer before PII can be transferred from the customer's system. The type of notice and consent required depends on the type of User Data being collected and how it will be used...

Security is an essential element of privacy. Reasonable steps should be taken to protect PII from loss, misuse, unauthorized access, disclosure, alteration, and destruction. Preventive measures include access controls, encryption in transfer and storage, physical security, disaster recovery, and auditing. Security requirements vary depending on the type of User Data collected and whether it will be stored locally, transferred, and/or stored remotely. When storing Sensitive PII on a customer's system, it must be stored using appropriate security mechanisms to prevent unauthorized access (e.g., file permissions and encryption). Sensitive PII transferred to or from a customer's system over the Internet must be transferred using a secure method that prevents unauthorized access...

[My thanks to Cameron Wilson of USACM for a pointer to this document.]

Labels: ,


Wednesday, October 25, 2006

Building a Better Voting Machine

Wired News has a really nice article by Kim Zetter about electronic voting, and what we can hope to do about it by 2008. It is based largely on advice from Professors Ed Felten and David Wagner.

It's been six years since the Florida presidential fiasco launched a flurry of spending around the country to replace antiquated punch-card and lever voting machines with expensive new electronic touch-screen machines. Yet new controversies over the security of e-voting machines continue to crop up, making it clear that the new machines are just as problematic as the ones they replaced.

Why can't the voting machine companies get it right?

With election season upon us, Wired News spoke with two of the top computer scientists in the field, UC Berkeley's David Wagner and Princeton's Ed Felten, and came up with a wish list of features we would include in a voting machine, if we were asked to create one.

These recommendations can't guarantee clean results on their own. Voting machines, no matter how secure, are no remedy for poor election procedures and ill-conceived election laws. So our system would include thorough auditing and verification capabilities and require faithful adherence to good election practices, as wells as topnotch usability and security features.

Here, then, is our nomination for the best voting machine for 2008. Use the comments tool below to tell us how your perfect voting machine would look...

Combine the best features of touch-screen and optical-scan machines in a single device...

Eliminate removable memory cards...

Simplify voting machine software to use minimal lines of code...

Make self-policing software...

Create transparent code...

Employ mandatory audits...

Random spot checks...

Post-election hand audits...

Post-election voter verification...

In the meantime, [Felten] says, all we can do is take steps to "reduce the window of vulnerability (with elections) -- not to zero, but to far below where it is now."

Labels: ,


Tuesday, October 24, 2006

Three parses

People sometimes complain about the length of this blog's title--although others like it as a quotation. Many do not realize that it is crafted to be "tribiguous," i.e., to have three distinct parses. I like it because I believe all three to be true, though diferent. Here are three related sentences to help you see the three parses:
  1. When we start something, we always hope that it will be simpler than it turns out to be.
  2. We hope that each thing will eventually become simpler than it is now.
  3. The only thing that is perfectly simple is "nothing."
Compare the third sentence to the Dictionary of Philosophy entry that begins
Nobody is very comfortable with the concept of Nothing. But of course He would be.
and to Lewis Carroll's
"I see nobody on the road," said Alice.

"I only wish I had such eyes," the King remarked in a fretful tone. "To be able to see Nobody! And at that distance, too! Why, it's as much as I can do to see real people, by this light!"



Monday, October 23, 2006

Making the case for an ACM Fellow

ACM's highest membership grade is Fellow, intended to recognize and honor outstanding ACM members for their achievements in computer science and information technology and for their significant contributions to the mission of ACM. The goal is for Fellows to represent the top 1% of ACM's membership. (The other advanced membership grades are Distinguished and Senior.)

I served a five-year term on the ACM Fellows Committee, including chairing it one year. And as co-chair of the ACM Awards Committee, I have been a non-voting observer for the past five years. In those ten years, I have observed a number of commonalities that I think I can discuss without violating the confidentiality of the committee's discussions. [1]

First, I should say that this is a very dedicated and hardworking committee, who take their task very seriously. They are unpaid volunteers who each year read and consider some 500 nomination and endorsement letters. Although their collective expertise covers an impressive portion of the discipline, it is inevitable that no member of the committee will be at home in the areas of all of the candidates. But they each try to properly evaluate all of the cases presented, prior to a face-to-face meeting where they discuss each case.

Second, cases fall into three groups of roughly equal size:
  • Cases generally agreed to demonstrate that the candidate meets the criteria.
  • Cases generally agreed to not do so.
  • Cases where there is either disagreement or uncertainty within the committee.
Not surprisingly, the bulk of the committee's discussion is devoted to the latter group, and this is where the chance of mistakes is greatest.

Every year there are surely a few candidates who are rejected, not because they are not qualified, but because their nomination and endorsements fail to make the case as effectively as possible. There is no way for the committee to know which cases these are. When the discussion is inconclusive, the committee tends to make the conservative choice: A candidate who is not accepted, but should have been, can be nominated again, but a candidate who is accepted will not be re-evaluated. [2]

Here are some suggestions for nominators and endorsers about things they can do to strengthen (or avoid unnecessarily weakening) the cases for their candidates.
  1. Nominate the candidate: Probably the greatest single reason for people who should be ACM Fellows not being accepted is that they have not been nominated. The committee is not empowered to select candidates on its own, it can only judge the nominations it receives. [3]
  2. Follow the rules scrupulously: ACM Headquarters staff check all candidate packages strictly. If a nomination or endorsement arrives after the deadline, the committee doesn't see it. If a nominator or endorser isn't an ACM member as of the deadline, the committee doesn't see their input. If there are not five endorsements, the committee doesn't see the case at all. Etc.
  3. Summarize the case in the nomination: In addition to supplying the required data, use the 7,500 characters to describe the candidate's accomplishments briefly, but specifically.
    • Avoid flowery adjectives, multiple superlatives, and overworked words such a "seminal" and "unique." Instead, indicate the importance of the work by describing its specific consequences (e.g., a new line of research taken up by others, a system or product in widespread use, an important conjecture resolved, a popular textbook) in terms understandable to a non-specialist.
    • The ideal candidate will have distinguished personal technical accomplishments, distinguished technical leadership, and distinguished ACM and community service. The more "concentrated" the accomplishments are into one or two areas, the more outstanding they need to be in those areas.
    • Although there is no formal age or experience requirement for Fellow, evidence is needed that the candidate's accomplishments are already--not just potentially--in the top 1% of ACM's membership.
    Cases with a weak nomination letter usually end in the bottom third and get little discussion.
  4. This is not a tenure case: Performing acceptably for a sufficient number of years is not enough. Having hundreds of refereed publications is not enough. There is no "up or out"; many distinguished members will go their entire careers without becoming Fellows.
  5. Choose the endorsers carefully: Since it is assumed that likely candidates will all have strong nominations, much of the committee's discussion focuses on the endorsements.
    • Each endorser should be able to personally attest to portions of the candidate's accomplishments.
    • An endorsement from an ACM Fellow carries just a little more weight, provided that the Fellow is actually familiar with the accomplishments discussed.
    • An endorsement by someone known to members of the committee can be more readily calibrated.
    • It is helpful to have endorsers from several different organizations, and endorsers who can address each of the areas of accomplishment outlined in the nomination.
    • With few exceptions, those who endorse more than two or three candidates will not strengthen their cases. Nor will cycles in the endorsement graph. [4]
    • It is acceptable to seek more than the minimum of 5 endorsements, to guard against the contingency of an endorsement arriving late. But 5 strong endorsements will make a more convincing case than those same 5 endorsements plus 3 weaker ones.
  6. Write the endorsements as carefully as the nomination: An endorsement should focus on the accomplishments that you can personally attest to, and place them in context. Use this focus to include more specifics than are in the nomination, if you can. Merely repeating portions of the nomination letter will actually weaken the case.
    If you are endorsing multiple candidates, it is very important to rank them, and useful to compare them. (If you cannot do this, you probably don't know all of them well enough to endorse.)
[1] These are my personal observations, and should not be interpreted as representing the views or policies of any other person or organization.
[2] Nominators of rejected candidates should seriously consider whether a stronger case could have been made; if they are convinced it could have been, it is acceptable to re-nominate the next year (but not effective to do so with the same letters). If a candidate is rejected two years in a row, a third consecutive nomination is not allowed. Wait a couple of years; if the candidate then has further accomplishments to strengthen the case, consider re-nominating.
[3] And, as a matter of policy, committee members recuse themselves from nominating or endorsing candidates, as do the Awards Committee co-chairs.
[4] There are over 500 ACM Fellows; why do we always get endorsements from the same 50?

Labels: ,


Not many people get a chance to make a $2 Billion mistake [1]

... but increasingly they are going to be people associated with software.

An article in, by Randall S. Newton, Editor-in-Chief, discusses the significance of the Airbus software disaster.
Bloomberg News is reporting this morning that the use of two different versions of CATIA 3D CAD software—versions that are incompatible at the file level—is largely to blame for significant delays on the Airbus A380 project...

The real problem looks to be a lack of leadership at the top levels at Airbus. Somebody inside Airbus knew that engineers in Germany and Spain were using CATIA V4 while CATIA V5 was in use in the UK and France. Somebody made a decision not to push for a single compatible standard, or to at least invest in a translator system. As a result, Airbus has already announced earnings losses of $2.54 billion over the next three years, according to Bloomberg. I am sure the Airbus board of directors, meeting today in Amsterdam, would like to know Somebody’s name...

The third lesson is to directly address cultural issues regarding the use of design software. Time and time again I have heard engineering managers and CAD directors say the most difficult part of implementing new software is the resistance among the old guard. Why should engineers in Germany and Spain have been allowed to continue using CATIA V4 when engineers in France and the UK were already on CATIA V5? It only makes sense if appeasement is a core corporate value.
[1] I believe it was Fred Brooks who said "It is a very humbling experience to make a $100 million mistake," but that was back when $100 million seemed like a lot of money.

Labels: ,


Tuesday, October 17, 2006

Hidden complexities in tamper-proof voting

Ron Rivest has recently circulated an interesting scheme for a paper-based voting scheme that attempts to achieve the same security properties of cryptographic voting protocols, using only paper ballots.
The principles of ThreeBallot are simple and easy to understand.

In this proposal, not only can each voter verify that her vote is recorded as she intended, but she gets a “receipt” that she can take home that can be used later to verify that her vote is actually included in the final tally. Her receipt, however, does not allow her to prove to anyone else how she voted.

In this “ThreeBallot” voting system, each voter casts three paper ballots, with certain restrictions on how they may be filled out, so the tallying works. These paper ballots are of course “voter-verifiable.” All ballots cast are scanned and published on a web site, so anyone may correctly compute the election result.

A voter receives a copy of one of her ballots as her “receipt”, which she may take home. Only the voter knows which ballot she copied for her receipt. The voter is unable to use her receipt to prove how she voted or to sell her vote, as the receipt doesn’t reveal how she voted.

A voter can check that the web site contains a ballot matching her receipt. Deletion or modification of ballots is thus detectable; so the integrity of the election is verifiable.
Although the scheme seemed a bit more complicated than I think the average voter will tolerate, I was pleased to see how far it seemed possible to go in this direction with paper ballots.

Alas, it's not that simple. Ed Felten has posted clear explanations of some fairly serious flaws (first, second, third). He also provides links to more detailed critiques by Charlie Strauss and Andrew Appel.

Moral: Even security experts need to have their protocols vetted by a number of other experts--it's very easy not to see potential weaknesses in your own scheme and not to realize what assumptions you have made implicitly.

Labels: , ,


Friday, October 13, 2006

US Treasury and the North Korean Nuclear Bomb Test

Fascinating article by Simon Tisdall in the Guardian.

Twelve months ago it seemed the west's nuclear confrontation with North Korea had reached an unexpectedly happy ending. Then the US treasury department stuck its oar in. In a deal brokered by China on September 19 2005, Kim Jong-il's regime pledged to give up its atomic weapons, abandon existing nuclear programmes and rejoin the UN Nuclear Non-Proliferation Treaty that it had repudiated in 2003.

In return the US agreed to recognise North Korea's territorial integrity and eschew all hostile actions. The Bush administration thereby effectively withdrew its earlier threats of forcible regime change levelled against a founder member of President George Bush's "axis of evil"...

The September deal brought sighs of relief across Asia and in Washington, where rightwing newspaper editorials hailed a "triumph of US policy". It spawned talk of a new era of strategic cooperation between the US and China, a denuclearised Korean peninsula, and the peaceful reunification of North and South Korea.

But the celebrations were premature. For reasons that remain unclear, the US treasury department chose almost the exact moment the deal was struck to move against a Macau-based bank called Banco Delta Asia...

Apparently facing financial strangulation, Pyongyang's leadership resorted to the only diplomatic weapon it had. The foreign ministry said North Korea would boycott further talks on relinquishing its nuclear activities until the threat of US financial sanctions was lifted. North Korea has reiterated the same demand on numerous occasions since and repeated it this week following its underground weapons test. But it also said it was ready to resume dialogue if Washington eased financial pressures.

There has been no response. US officials maintain that the steps taken against Banco Delta Asia last autumn were unconnected to the nuclear talks. On Wednesday Mr Bush accused North Korea of "walking away" from the September 19 disarmament deal. Pyongyang and Pyongyang alone was to blame for recreating the crisis, he said.

Labels: , ,


Wednesday, October 11, 2006

655,000 additional Iraqi deaths?

Of course, the U.S. holds life (at least non-American life) pretty cheap. However, even by our own low standards, the latest figures from Iraq are pretty shocking:
655,000 more Iraqis died in the 40 months since the U.S.-led invasion than died during previous 40 months under Saddam Hussein. This is about 2.5% of the population of Iraq.

This number comes from a report in The Lancet, a leading British medical journal. The authors are members of the Johns Hopkins Bloomberg School of Public Health.

Pre-invasion mortality rates were 5·5 per 1000 people per year (95% CI 4·3–7·1), compared with 13·3 per 1000 people per year (10·9–16·1) in the 40 months post-invasion...

Of post-invasion deaths, 601 027 (426 369–793 663) were due to violence, the most common cause being gunfire.
See also this report and this commentary in the Guardian.

A "beacon of democracy," indeed! No wonder they want us gone.

[Other Sources]

Update: Added question mark to title. It seems that the methodoogy of the study is suspect. See following comment.

Labels: ,


Friday, October 06, 2006

Evoting: Netherlands Scandal

A Dutch post (mirrored here) discusses the ease with which the computer used by most voters in the Netherlands can be reprogrammed to produce any desired result (or even to play chess).

90% of the of the votes in The Netherlands are cast on the Nedap/Groenendaal ES3B voting computer. With very minor modifications, the same computer is also being used in parts of Germany and France. Use of this machine in Ireland is currently on hold after significant doubts were raised concerning its suitability for elections...

The Nedap ES3B electronic voting computer is a system that belongs to the DRE (Direct Recording Electronic) class of voting computers. As such it only records the votes in memory. The system requires ultimate trust, since it produces an official election outcome that cannot be verified independently. In this paper we describe the results of an independent review of the Nedap ES3B electronic voting computer that was done without consent of the manufacturer, without access to source code, and within roughly one month.

This paper details all the steps we needed to take to create and install our own demonstration software on the machine, as well as a modified version of its own software: a version that lies about the election results. It also details a practical attack that allows a remote observer to get some information about what is being voted on an unmodified Nedap ES3B computer by exploiting compromising radio emanations from the device...

We believe public elections are pointless unless people have the right and the meaningful possibility to verify that that their votes are counted correctly...

We took apart these computers because we believe we had a right to find out how our own elections work. We published this paper because we believe that you, the voter, have a right to know what independent experts think of the computers that count your vote...

Because we wanted our results to be available before the November 22nd of 2006 Dutch national parliamentary elections, we were in a hurry. This preliminary report is the result of a month’s worth of work. Much more research needs to be done and there are very definite open questions...

The key system chosen by Nedap for both the locks on the voting computer is the “C&K YL Series 4 Tumbler Camlock”. This lock always comes with the same key (marked “A126”), which probably explains why the same key is used on all 8000 ES3B machines throughout The Netherlands. Spare keys can be ordered separately online for roughly a Euro each by searching for the product number: 115140126. We ordered, payed for and were subsequently supplied with 100 of these keys without any problem. According to the product datasheet, typical applications for this lock include “copy machines and office furniture”. Even if spare keys were not so readily available: this is quite literally the type of lock we can open with a bent paperclip...

The ISS software has a ‘maintenance mode’ that is supposed to be only accessible to members of the “verkiezingswacht”, the Nedap election-day helpdesk. You need a password to get the software in this mode. A quick look in the binary revealed this password to be “GEHEIM”, the Dutch word for “SECRET”. The maintenance mode, among other things, allows the helpdesk to read the binary contents of a ballot module plugged into the programming slot of a reader unit. By sniffing the serial commands between the ISS software and the reader unit, we figured out how to issue these commands ourselves and subsequently wrote a program in Tcl that we could use to read the entire contents of a ballot memory module...

It started with what we thought was a very obvious statement. We claimed on our website that the Nedap was just another computer, and that as such it could just as easily be programmed to play chess or to lie about the election results. We didn’t think more of it until Jan Groenendaal, placed a document on the Nedap/Groenendaal website to talk about our website "Wij vertrouwen stemcomputers niet". In it, he says: “[...] And with regard to the claim that our machine can play chess: I’d like to see that demonstrated”.

So obviously, one of our first goals now that we had access to the device was to make it play chess. Apart from proving our point, programming it to do this would also confirm that we knew everything we needed to know about the hardware before getting into the election fraud business. After having learned roughly how the hardware worked we used a gcc 68000 crosscompiler to create a Nedap IO-library containing functions to initialize the system, write data to the display, read the keyboard, and write debug messages to the UART. Together with newlib, a small clib implementation, we then managed to compile and run Tom Kerrigan's Simple Chess Program (TSCP). This was non-trivial only because we had to squeeze out quite a few tables to make it run using only the available 16 kBytes of RAM. Getting the chess pieces to magnetically attach (the keyboard is mounted at an angle) was also not that easy since the foil switches are stuck to a plastic base. We ended up using using 2 and 5 Eurocent coins underneath the paper, taped such that we could press the underlying foil switches with the edge of the coin.

It knows all the rules and every now and then it can be surprisingly clever for what it is. But in all honesty we have to admit that it does not play chess all that well...

We then built “hooks” into the regular ES3B code. Every time a voter casts a ballot, our code generates a random number between 0 and 100. If the number is below the programmed percentage of votes we want to steal, that vote is not written to the ballot module but one is added to the corresponding 16-bit number in EEPROM. At the end of the election, our software determines whether this was a real election or not. It then proceeds to, either honestly or fraudulently, quickly write these votes into random locations in the ballot module, just like the real software does...

A future version of PowerFraud will also offer a “magic button” function. What this does is allow any voter during the day to press a previously-configured key combination on the voter keypad, followed by the keys needed to cast a vote. The device will then store the party that received that particular vote as the recipient for all the stolen votes, and it will not perform any vote stealing unless the magic button was pressed. This would be impossible to catch using parallel testing.

It's not just in America that DRE poses a threat to democracy.

Labels: , ,