Re: Sun Ray and alternative hardware (was rudy de haas)

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Fri May 28 2004 - 14:31:18 CDT

I think the idea of networking voting machines together incurs risks
we want to avoid. The concept is to have standalone machines with

Best regards,

At 9:29 AM -0600 5/28/04, charlie strauss wrote:
>Sun-Rays are Sun's ultimate in ultra-thin terminals. It's not just
>a x-windows display terminal but rather the actual video signal is
>sent via ethernet. Sun claims they can support a large fleet of
>responsive terminals up to 17"s this way. They also have card
>recognition systems. In use the user has a card that when swiped on
>ANY sun-ray terminal the terminal literally becomes his terminal.
>that is it actually sends the same video signal the user had on his
>previous terminal to the new terminal. I would imaging one could
>co-opt this hardware for any card based system in which allows the
>user to vote once. So you save on the heads and pay for a central
>server, which in the case of a voting machine could probably be
>quite cheap.
>I wonder if there are any concepts here OVC could steal to make a
>better system. OVC does not need the "hot desking" feature of being
>able to move from one terminal to another. But Instead of every
>computer being standalone in the current OVC scheme, one could have
>a single computer that was broadcasting VNC sessions to a fleet of
>voting stations via ethernet. The advantage here might be that the
>terminals could be even dumber which is good from a
>security-by-infrastructure point of view. VNC was in fact developed
>with really really dumb toaster like terminals in mind (ATM
>machines, store kiosks). So by limiting the complexity of the end
>terminal one has less to worry about in terms of software security.
>and also it makes upgrades, code review, and parallel testing a snap
>since there aren't any on the voting stations.
>An even simpler thought would be to put multiple video cards, or
>video cards that can drive multiple terminals in single PC.
>transmitting standard video signals over a 25 foot cable is not a
>problem. the security pro is that you only have one computer whose
>integrity you have to assure and transport. The con is that it
>means that if that computer is subverted the entire precint is
>My own preference however is not to use PCs at all but to use
>something like a palm pilot. These compact devices could literally
>be locked in a safe between elections and even delivered to poling
>places in safes. their small foot print means fewer delivery men
>involved (lower cost, more security) and lower storage costs: most
>counties would not even fill a broom closet.
>-----Original Message-----
>From: Arthur Keller <>
>Sent: May 28, 2004 3:19 AM
>Subject: [voting-project] Non-member submission from [Rudy de Haas
>--- begin forwarded text
>Date: Thu, 27 May 2004 18:23:13 -0400 (EDT)
>From: Rudy de Haas <>
>Reply-To: Rudy de Haas <>
>Subject: Re: "Using Tech To Fix Elections"
>While I ("Paul Murphy" is a psuedonym) am not on your list I was glad
>to get your note. There are several things worthy of comment here:
>1- As I said in the column, politics will drive this process to
>disaster. It is
>possible to fix it in time, but action is not probable. I plan,
>however, to make
>sure the chair of all of the congressional committees investigating the
>2004 presidential election get copies - -:)
>2- Sunray pricing is both absurd and confusing. The price
>is the public dissuasion price, like the $300 SCSI terminator (for the 3310),
>aimed (I think) at establishing an inclusive base price for pentagon
>buyers. In
>reality, the 1g (the first "smart display" Sunray and quite different from
>earlier models) runs around $359 plus monitor so $650 is quite
>realistic and not
>actually a discounted price; merely a real world one. In reality
>you'd probably
>get 19" flat screens with them with the kind of volume this contemplates.
>3- the snippy version of my response to the comment about sunrays is that
>I've used PCs but you haven't used a 1g, have you? The more realistic
>response is twofold:
>3.a - first, anything you can show on a PC, I can do on a 1g - and I do mean
>anything since you can use them to show wintel services too. Sun recommends
>citrix for that; I use VNC, either way the underlying issue is ms licensing,
>not technology.
>3.b second, from a security and audit perspective the key issue that
>the simpler
>you make things, the fewer things that can go wrong - accidently or
>otherwise. I
>really like the idea of open source PC voting software - it's more likely
>to get used than my idea - but that PC is dangerous whether it runs
>some windows
>brand OS, Linux, BSD, or even Solaris. Fundamentally it's not transperent and
>the sunray is because there's nothing there for anyone to bugger around with -
>and there are lots of reasons for thinking that getting at the data after
>the sunray transmits it will be almost impossible. Check next week's column
>for details.
>You have a comment about my taking networking for granted. I am - sort of. You
>can use sunrays on PC networks, but its a bad idea. In my approach
>the local server will connect to a hub (a dumb hub) which will fan out to
>the local sunrays as well as pass a connection to the local school net. All
>traffic to/from that net is automatically encrypted; all local traffic can
>be but doesn't have to be. The actual load on the school's connection to the
>internet is small, but there's no doubt that this will be the most common
>point of failure. On the other hand implementation won't happen this
>year - and getting it in by 2008 will allow for a month or two of set-up,
>testing, and debugging!
>And, finally, you have a comment about timestamps and local law. There are
>at least three thousand sets of bylaws, real laws, and opinions on these
>issues. In principle federal legislation can over ride them all; in practice
>that would take leadership empowered by an understanding of what can, and
>should be done. It's not there yet.
>>Mime-Version: 1.0 (Apple Message framework v618)
>>Content-Transfer-Encoding: 7bit
>>From: David Mertz <>
>>Subject: "Using Tech To Fix Elections"
>>Date: Thu, 27 May 2004 14:08:43 -0400
>>On May 27, 2004, at 1:37 PM, Alan Dechert wrote:
>>>> <>
>>> He's got some good commentary until he arrives at his proposed
>>> solution,
>>> which suffers from the "pretend politics doesn't matter and everyone
>>> just
>>> does as I say" syndrome.
>>Paul Murphy also gets some technical details wrong. In the same ways
>>some very smart people have, so there's no shame in that. I don't
>>really get the fixation on Sun, maybe he owns stock in them. But if
>>Sunray's with 17" touchscreens really are $650, that's a nice price
>>compared to those people have mentioned recently.
>>He's also a little too sanguine about local for my tastes, but that's
>>not wrong per se. Well, maybe more than just a little too much. And
>>why he always refers to the interface as a "web page" is mysterious,
>>since it isn't on "the Web." Probably HTML is the wrong display
>>technology, as list readers know, but even if it weren't, the casual
>>mention of "web page" conflates issues.
>>Where Murphy really goes wrong is in not understanding the anonymity
>>> Election officials at the polling place login each smart display using
>>> an assigned ID that identifies the device. Both the Sunray and local
>>> Web services are handled by a nearby server, but ballot submissions
>>> are automatically routed to state servers, where they are added to
>>> transaction tables defined by unique ballots. As will be noted in next
> >> week's column on the software for this, serialization will replace the
>>> timestamp for audit purposes to break the link between the time the
> >> voter leaves the booth and the voting record compiled at the state
>>> level.
>>I've discussed the "covert-videotaping-voters" attack many times.
>>Sequence information still compromises anonymity. I think Murphy
>>intends to address that by having an elaborately networked (i.e.
>>crackable/interceptible) scheme to dump everything in central
>>databases, thereby making the sequence attack more difficult. It just
>>screams "fragile" at so very many levels. But even apart from that,
>>the sequence masking doesn't really work if ballots can be reassociated
>>to particular precincts, which is very often the case because of
>>per-precinct ballot customization (different places have different
>>collections of contests).
>>It's kinda the "fresh faced engineer" approach, even if his picture
>>suggests he's a bit older than "fresh faced" suggests :-). As Alan is
>>often good at pointing out, the problem isn't one for engineers (at
>>least not in isolation).
>>Apart from the anonymity attack, Murphy runs afoul of the law. In a
>>way I did not know until Doug Jones recently pointed it out on the
>>list. Vote timestamps are REQUIRED, but as the time of casting a vote
>>only, not the vote content. Murphy's idea isn't entirely inconsistent
>>with this, he just needs to quickly start adding more layers to address
>>the law, once he finds out about it. There would be lots more layers
>>he'd discover if he started following the OVC list, until eventually he
>>arrived at a Sun-powered Rube Goldberg voting station.
>>I do want to compliment Alan, yet again, for managing to strip away
>>complexities, and get at the core issues. I have a set of minor
>>divergences from Alan on OVC design--as Karl or Arthur has slightly
>>different ones--but at heart it's a remarkably elegant concept.
>Rudy de Haas
>1-519-896-2560 (EST)
>Author (As Paul Murphy) of:
> column on Unix and Telecom
>The Unix Guide to defenestration (see )
>Multiple Series on Linux and business issues
>--- end forwarded text
>Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA 94303-4507
>tel +1(650)424-0202, fax +1(650)424-0424

Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Mon May 31 23:18:12 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:17 CDT