December 23, 2024

Archives for 2010

NJ court permits release of post-trial briefs in voting case

In 2009 the Superior Court of New Jersey, Law Division, held a trial on the legality of using paperless direct-recording electronic (DRE) voting machines. Plaintiffs in the suit argued that because it’s so easy to replace the software in a DRE with fraudulent software that cheats in elections, DRE voting systems do not guarantee the substantive right to vote (and to have one’s vote counted) required by the New Jersey constitution and New Jersey statutory law.

I described this trial in three articles last year: trial update, summary of plaintiffs’ witnesses’ testimony, and summary of defense witnesses’ testimony.

Normally in a lawsuit, the courtroom is open. The public can attend all legal proceedings. Additionally, plaintiffs are permitted to explain their case to the public by releasing their post-trial briefs (“proposed findings of fact” and “proposed conclusions of law”). But in this suit the Attorney General of New Jersey, representing the defendants in this case, argued that the courtroom be closed for parts of the proceedings, and asked the Court to keep all post-trial documents from the public, indefinitely.

More than a year after the trial ended, the Court finally held a hearing to determine whether post-trial documents should be kept from the public. The Attorney General’s office failed to even articulate a legal argument for keeping the briefs secret.

So, according to a Court Order of October 15, 2010, counsel for the plaintiffs (Professor Penny Venetis of Rutgers Law School aided by litigators from Patton Boggs LLP) are now free to show you the details of their legal argument.

The briefs are available here:
Plaintiffs’ Proposed Findings of Fact
Plaintiffs’ Proposed Conclusions of Law

I am now free to tell you all sorts of interesting things about my hands-on experiences with (supposedly) tamper-evident security seals. I published some preliminary findings in 2008. Over the next few weeks I’ll post a series of articles about the limitations of tamper-evident seals in securing elections.

Join CITP in DC this Friday for "Emerging Threats to Online Trust"

Update – you can watch the video here.

Please join CITP this Friday from 9AM to 11AM for an event entitled “Emerging Threats to Online Trust: The Role of Public Policy and Browser Certificates.” The event will focus on the trustworthiness of the technical and policy structures that govern certificate-based browser security. It will include representatives from government, browser vendors, certificate authorities, academics, and hackers. For more information see:

http://citp.princeton.edu/events/emerging-threats-to-online-trust/

Several Freedom-to-Tinker posts have explored this set of issues:

On Facebook Apps Leaking User Identities

The Wall Street Journal today reports that many Facebook applications are handing over user information—specifically, Facebook IDs—to online advertisers. Since a Facebook ID can easily be linked to a user’s real name, third party advertisers and their downstream partners can learn the names of people who load their advertisement from those leaky apps. This reportedly happens on all ten of Facebook’s most popular apps and many others.

The Journal article provides few technical details behind what they found, so here’s a bit more about what I think they’re reporting.

The content of a Facebook application, for example FarmVille, is loaded within an iframe on the Facebook page. An iframe essentially embeds one webpage (FarmVille) inside another (Facebook). This means that as you play FarmVille, your browser location bar will show http://apps.facebook.com/onthefarm, but the iframe content is actually controlled by the application developer, in this case by farmville.com.

The content loaded by farmville.com in the iframe contains the game alongside third party advertisements. When your browser goes to fetch the advertisement, it automatically forwards to the third party advertiser “referer” information—that is, the URL of the current page that’s loading the ad. For FarmVille, the URL referer that’s sent will look something like:

http://fb-tc-2.farmville.com/flash.php?…fb_sig_user=[User’s Facebook ID]…

And there’s the issue. Because of the way Zynga (the makers of FarmVille) crafts some of its URLs to include the user’s Facebook ID, the browser will forward this identifying information on to third parties. I confirmed yesterday evening that using FarmVille does indeed transmit my Facebook ID to a few third parties, including Doubleclick, Interclick and socialvi.be.

Facebook policy prohibits application developers from passing this information to advertising networks and other third parties. In addition, Zynga’s privacy policy promises that “Zynga does not provide any Personally Identifiable Information to third-party advertising companies.”

But evidence clearly indicates otherwise.

What can be done about this? First, application developers like Zynga can simply stop including the user’s Facebook ID in the HTTP GET arguments, or they can place a “#” mark before the sensitive information in the URL so browsers don’t transmit this information automatically to third parties.

Second, Facebook can implement a proxy scheme, as proposed by Adrienne Felt more than two years ago, where applications would not receive real Facebook IDs but rather random placeholder IDs that are unique for each application. Then, application developers can be free do whatever they want with the placeholder IDs, since they can no longer be linked back to real user names.

Third, browser vendors can give users easier and better control over when HTTP referer information is sent. As Chris Soghoian recently pointed out, browser vendors currently don’t make these controls very accessible to users, if at all. This isn’t a direct solution to the problem but it could help. You could imagine a privacy-enhancing opt-in browser feature that turns off the referer header in all cross-domain situations.

Some may argue that this leak, whether inadvertent or not, is relatively innocuous. But allowing advertisers and other third parties to easily and definitively correlate a real name with an otherwise “anonymous” IP address, cookie, or profile is a dangerous path forward for privacy. At the very least, Facebook and app developers need to be clear with users about their privacy rights and comply with their own stated policies.

Court permits release of unredacted report on AVC Advantage

In the summer of 2008 I led a team of computer scientists in examining the hardware and software of the Sequoia AVC Advantage voting machine. I did this as a pro-bono expert witness for the Plaintiffs in the New Jersey voting-machine lawsuit. We were subject to a Protective Order that, in essence, permitted publication of our findings but prohibited us from revealing any of Sequoia’s trade secrets.

At the end of August 2008, I delivered my expert report to the court, and prepared it for public release as a technical report with the rest of my team as coauthors. Before we could release that report, Sequoia intervened with the Court, claiming that we were revealing trade secrets. We had been very careful not to reveal trade secrets, so we disputed Sequoia’s claim. In October 2008 the Court ruled mostly in our favor on this issue, permitting us to release the report with some redactions,and reserving a decision on those redacted sections until later.

The hearing on those sections has finally arrived, completely vindicating our claim that the original report was within the parameters of the Protective Order. On October 5, 2010 Judge Linda Feinberg signed an order permitting me to release the original, unredacted expert report, which is now available here.

If you’re curious, you can look at paragraphs 19.8, 19.9, 21.3, and 21.5, as well as Appendices B through G, all of which were blacked out in our previously released report.

HTC Willfully Violates the GPL in T-Mobile's New G2 Android Phone

[UPDATE (Oct 14, 2010): HTC has released the source code. Evidently 90-120 days was not in fact necessary, given that they managed to do it 7 days after the phone’s official release. It is possible that the considerable pressure from the media, modders, kernel copyright holders, and other kernel hackers contributed to the apparently accelerated release.]

[UPDATE (Nov 10, 2010): The phone has been permanently rooted.]

Last week, the hottest new Android-based phone arrived on the doorstep of thousands of expectant T-Mobile customers. What didn’t arrive with the G2 was the source code that runs the heart of the device — a customized Linux kernel. Android has been hailed as an open platform in the midst of other highly locked-down systems, but as it makes its way out of the Google source repository and into devices this vision has repeatedly hit speedbumps. Last year, I blogged about one such issue, and to their credit Google sorted out a solution. This has ultimately been to everyone’s benefit, because the modified versions of the OS have routinely enabled software applications that the stock versions haven’t supported (not to mention improved reliability and speed).

When the G2 arrived, modders were eager to get to work. First, they had to overcome one of the common hurdles to getting anything installed — the “jailbreak”. Although the core operating system is open source, phone manufacturers and carriers have placed artificial restrictions on the ability to modify the basic system files. The motivations for doing so are mixed, but the effect is that hackers have to “jailbreak” or “root” the phone — essentially obtain super-user permissions. In 2009, the Copyright Office explicitly permitted such efforts when they are done for the purpose of enabling third-party programs to run on a phone.

G2 owners were excited when it appeared that an existing rooting technique worked on the G2, but were dismayed when their efforts were reversed every time the phone rebooted. T-Mobile passed the buck to HTC, the phone manufacturer:

The HTC software implementation on the G2 stores some components in read-only memory as a security measure to prevent key operating system software from becoming corrupted and rendering the device inoperable. There is a small subset of highly technical users who may want to modify and re-engineer their devices at the code level, known as “rooting,” but a side effect of HTC’s security measure is that these modifications are temporary and cannot be saved to permanent memory. As a result the original code is restored.

As it turned out, the internal memory chip included an option to make certain portions of memory read-only, which had the effect of silently discarding all changes upon reboot. However, it appears that this can be changed by sending the right series of commands to the chip. This effectively moved the rooting efforts into the complex domain of hardware hacking, with modders trying to figure out how to send these commands. Doing so involves writing some very challenging code that interacts with the open-source Linux kernel. The hackers haven’t yet succeeded (although they still could), largely because they are working in the dark. The relevant details about how the Linux kernel has been modified by HTC have not been disclosed. Reportedly, the company is replying to email queries with the following:

Thank you for contacting HTC Technical Assistance Center. HTC will typically publish on developer.htc.com the Kernel open source code for recently released devices as soon as possible. HTC will normally publish this within 90 to 120 days. This time frame is within the requirements of the open source community.

Perhaps HTC (and T-Mobile, distributor of the phone) should review the actual contents of the GNU Public License (v2), which stipulate the legal requirements for modifying and redistributing Linux. They state that you may only distribute derivative code if you “[a]ccompany it with the complete corresponding machine-readable source code.” Notably, there is no mention of a “grace period” or the like.

The importance of redistributing source code in a timely fashion goes beyond enabling phone rooting. It is the foundation of the “copyleft” regime of software licensing that has led to the flourishing of the open source software ecosystem. If every useful modification required waiting 90 to 120 days to be built upon, it would have taken eons to get to where we are today. It’s one thing for a company to choose to pursue the closed-source model and to start from scratch, but it’s another thing for it to profit from the goodwill of the open source community while imposing arbitrary and illegal restrictions on the code.