February 28, 2017

Archives for July 2008

Where are the Technologists on the EAC Advisory Board?

Barbara Simons, an accomplished computer scientist and e-voting expert, was recently appointed to the Election Assistance Commission (EAC) Board of Advisors. (The EAC is the U.S. Federal body responsible for voting technology standards, among other things.) This is good news.

The board has thirty-seven members, of which four positions are allocated for “members representing professionals in the field of science and technology”. These four positions are to be appointed by Majority and Minority leaders in the House and the Senate. (See page 2 of the Board’s charter.) Given the importance of voting technology issues to the EAC, it does seem like a good idea to reserve 10% of the advisory board positions for technologists. If anything, the number of technologist seats should be larger.

Barbara was appointed to the board position by the Senate Majority Leader, Harry Reid. Kudos to Senator Reid for appointing a genuine voting technology expert.

What about the other three seats for “professionals in the field of science and technology?” Sadly, the board’s membership list shows that these seats are not actually held by technical people. Barbara Arnwine holds the House Speaker’s seat, Tom Fuentes holds the House Minority Leader’s seat, and Wesley R. Kliner, Jr. holds the Senate Minority Leader’s seat. All three appear to be accomplished people who have something to offer on the board. But as far as I can tell they are not “professionals in the field of science and technology”, so their appropriate positions on the board would be somewhere in the other thirty-three seats.

What can be done? I wouldn’t go so far as to kick any current members off the board, even if that were possible. But when vacancies do become available, they should be filled by scientists or technologists, as dictated by the charter’s requirement of having four such people on the board.

The EAC is struggling with voting technology issues. They could surely use the advice of three more expert technologists.

License for an open-source voting system?

Back when we were putting together the grant proposal for ACCURATE, one of the questions that we asked ourselves, and which the NSF people asked us as well, was whether we would produce a “bright shiny object,” which is to say whether or not we would produce a functional voting machine that could ostensibly be put to use in a real election.  Our decision at the time, and it was certainly the correct decision, is that we would focus on innovating in the technology under the covers of a voting system, and we might produce, at most “research prototypes”.  The difference between a research prototype and a genuine, commercial system are typically quite substantial, in general, and it would be no different here with voting system prototypes.

At Rice we built a fairly substantial prototype that we call “VoteBox”; you can read more about it in a paper that will appear on Friday at Usenix Security.  To grossly summarize, our prototype feels a lot like a normal DRE voting system, but uses some nice cryptographic machinery to ensure that you don’t have to trust that the code is correct.  You can verify the correctness of a machine, on the fly, while the election is ongoing.  Our prototype is missing a couple features that you’d want from a commercial system, like write-in voting, but it’s far enough along that it’s been used in several human-factors experiments (CHI’08, Everett’07).

This summer, our mission is to get this thing shipped as some sort of “open source” project.  Now we have several goals in this:

  • Allow other researchers to benefit from our infrastructure as a platform to do their own research.
  • Inspire commercial voting system vendors to build better products (i.e., solving the hard design problems for them, to reduce their cost for adopting innovative techniques).
  • Allow commercial voting system vendors to build on our source code, itself.

All well and good.  Now the question is how we should actually license the thing.  There are many, many different models under which we could proceed:

  • Closed source + patents + licenses.  This may or may not yield revenues for our university, and may or may not be attractive to vendors.  It’s clearly unattractive to other researchers, and would limit uptake of our system in places where we might not even think to look, such as outside the U.S.
  • Open source + a “not for commercial use” license.  This makes it a little easier for other researchers to pick up and modify the software although ownership issues could get tricky.
  • Open source with a “BSD”-style license. A BSD-style license effectively says “do whatever you want, just give us credit for our work and you’re on your own if it doesn’t work.”   This sort of license tends to maximize the ease with which companies can adopt your work.
  • Open source with a “GPL”-style license.  The GPL has an interesting property for the voting system world: it makes any derivatives of the source code as open as the original code (unless a vendor reimplements it from scratch).  This sort of openness is something we want to encourage in voting system vendors, but it might reduce vendor willingness to use the codebase.
  • Open source with a “publication required” licenseJoe Hall suggested this as another option.  Like a BSD license, anybody can use it in a product, but the company would be compelled to publish the source code, like a book.  Unlike GPL, they would not be required to give up copyright or allow any downstream use of their code.

I did a quick survey of several open source voting systems.  Most are distributed under the GPL:

  • Adder
  • eVACS (old version is GPL; new version is proprietary)
  • Helios (code not yet released; most likely GPL according to Ben Adida)
  • OVC (GPL with extensions to require change histories be maintained)
  • Pvote

Civitas is distributed under a non-commercial-use only license.  VoteHere, at one point, opened its code for independent evaluation (but not reuse), but I can’t find it any more.  It was probably a variant on the non-commercial-use only theme.  Punchscan is distributed under a BSD-style license.

My question to the peanut gallery: what sort of license would you select for a bright, shiny new voting system project and why?

[Extra food for thought: The GPLv3 would have some interesting interactions with voting systems.  For starters, there’s a question of who, exactly, a “user” might be.  Is that the county clerk whose office bought it, or the person who ultimately votes on it?  Also, you have section 3, which forbids any attempt to limit reverse-engineering or “circumvention” of the product.  I suppose that means that garden-variety tampering with a voting machine would still violate various laws, but the vendor couldn’t sue you for it.  Perhaps more interesting is section 6, which talks about how source code must be made available when you ship compiled software.  A vendor could perhaps give the source code only to its “customers” without giving it to everybody (again, depending on who a “user” is).  Of course, any such customer is free under the GPL to redistribute the code to anybody else.  Voting vendors may be most scared away by section 11, which talks about compulsory patent licensing (depending, of course, on the particulars of their patent portfolios).]

Plenty of Blame to Go Around in Yahoo Music Shutdown

People have been heaping blame on Yahoo after it announced plans to shut down its Yahoo Music Store DRM servers on September 30. The practical effect of the shutdown is to make music purchased at the store unusable after a while.

Though savvy customers tended to avoid buying music in forms like this, where a company had to keep some distant servers running to keep the purchased music alive, those customers who did buy – taking reassurances from Yahoo and music industry at face value – are rightly angry. In the face of similar anger, Microsoft backtracked on plans to shutter its DRM servers. It looks like Yahoo will stay the course.

Yahoo deserves blame here, but let’s not forget who else contributed to this mess. Start with the record companies for pushing this kind of DRM, and the DRM agenda generally, despite the ample evidence that it would inconvenience paying customers without stopping infringement.

Even leaving aside past mistakes, copyright owners could step in now to help users, either by enticing Yahoo to keep its servers running, or by helping Yahoo create and distribute software that translates the music into a usable form. If I were a Yahoo Music customer, I would be complaining to the copyright owners now, and asking them to step in and stand behind their product.

Finally, let’s not forget the role of Congress. The knowledge of how to jailbreak Yahoo Music tracks and transform them into a stable, usable form exists and could easily be packaged in software form. But Congress made it illegal to circumvent Yahoo’s DRM, even to enable noninfringing use of a legitimately purchased song. And they made it illegal to distribute certain software tools to enable those uses. If Congress had paid more attention to consumer interests in drafting the Digital Millennium Copyright Act, or if it had passed any of the remedial legislation offered since the DMCA took effect, then the market could solve this Yahoo problem all on its own. If I were a Yahoo Music customer, I would be complaining to Congress now, and asking them to stop blocking consumer-friendly technologies.

And needless to say, I wouldn’t be buying DRM-encumbered songs any more.

UPDATE (July 29, 2008): Yahoo has now done the right thing, offering to give refunds or unencumbered MP3s to the stranded customers. I wonder how much this is costing Yahoo.