April 23, 2014

avatar

Google+Motorola = Software Patent Indictment

Google’s announcement this morning that it had agreed to purchase Motorola Mobility for $12.5Billion sent MMI’s stock price soaring and set off another conversation about software patents and the smart-phone ecosystem.

Larry Page himself emphasized the patent angle of the merger in the corporate blog post:

We recently explained how companies including Microsoft and Apple are banding together in anti-competitive patent attacks on Android. The U.S. Department of Justice had to intervene in the results of one recent patent auction to “protect competition and innovation in the open source software community” and it is currently looking into the results of the Nortel auction. Our acquisition of Motorola will increase competition by strengthening Google’s patent portfolio, which will enable us to better protect Android from anti-competitive threats from Microsoft, Apple and other companies.

Android-users already faced several patent lawsuits, and after a coalition of Google’s opponents, including Microsoft, Apple, and Oracle, purchased Nortel’s patent portfolio for $4.5 Billion, Google and its Android partners (including HTC and Motorola) had reason to fear a deepening thicket. Without many patents of its own, Google couldn’t make the traditional counter-strike of suing its attackers for infringement. Motorola’s mobile portfolio (17,000 issued patents and 7,500 pending applications) adds to Android’s arsenal.

Of course Motorola also makes hardware — smartphones that run Android — but few analysts are emphasizing that point. There, the acquisition raises strategic questions for Google: Can it convincingly offer the Android platform to others with whom it now competes? Even if Google maintains Motorola as a separate business, as Page says it intends, will now-competing vendors such as HTC, Samsung, and Acer be reassured of Google+Motorola’s neutrality among them?

Owning a handset maker could improve Android, if it shortens the feedback loop for problem-reporting and new ideas, but it could hurt the platform — and its end-users — more if it scared off competing hardware vendors, shrinking the base to which new applications are written and reducing the diversity of options available to end-users. As proprietor of an open, multi-sided market, Google needs to serve Android’s hardware vendors, app developers, and end-users well enough that a good-sized group of each continue to bring it value — and so the end-users watch the ads whose sale puts money into Google’s pocket from it all. (Oh, and maybe the acquisition will revitalize GoogleTV, as Lauren Weinstein points out.)

The patent motivations are more straightforward. As we know, it doesn’t take deliberate copying to infringe a patent, and patents are granted on small enough increments of software advance that an independently developed application may incorporate dozens to hundreds of elements on which others claim patents, and at millions of dollars a lawsuit, it’s expensive to disprove them. At least if those others are also making phones or software, Google is now more likely to have patents on what they are doing too, paving the way for a cross-license rather than a lawsuit.

Wouldn’t we all be better off skipping those patent threats and cross-licensing transaction costs? As Google’s pre-Motorola travails showed, it’s almost* impossible to opt-out of the patent system by choosing to publish and not patent your own inventions. Unlike in copyright, where you can share under Creative Commons, for example, and just have to prove you never accessed another’s work if accused of infringement, you can only save yourself from patent claims by assuring that every bit of technology you use was published more than 17-20 years ago! (*Rare but not impossible: Richard Hipp of SQLite says he only uses 17-year old, published algorithms to keep his code free of patent clouds.)

In a work-in-progress, I argue that patent’s incentives aren’t working right for software, because they come at too early a stage in development. Patents for software motivate lawsuits more than they induce or reward product development. Google+Motorola may prove to have non-patent benefits too, but its early indications shine a spotlight on the thorny thickets of the patent landscape.

avatar

A review of the FVAP UOCAVA workshop

The US Federal Voting Assistance Program (FVAP) is the Department of Defense Agency charged with assisting military and overseas voters with all aspects of voting, including registering to vote, obtaining ballots, and returning ballots. FVAP’s interpretations of Federal law (*) says that they must perform a demonstration of electronic return of marked ballots by overseas military voters (**) in a Federal election at the first Federal election that occurs one year after the adoption of guidelines by the US Election Assistance Commission. Since the EAC hasn’t adopted such guidelines yet (and isn’t expected to for at least another year or two), the clock hasn’t started ticking, so a 2012 demonstration is impossible and a 2014 demonstration looks highly unlikely. Hence, this isn’t a matter of imminent urgency; however, such systems are complex and FVAP is trying to get the ball rolling on what such a system would look like.

As has been discussed previously on this blog, nearly all computer security experts are very concerned about the prospect of marked ballot return over the internet (which we will henceforth refer to as “internet voting”). Issues include vulnerability of client computers, issues with auditability, concerns about usability and coercion, etc. On the flip side, many states and localities are marching full steam ahead on their own internet voting systems, generally ignoring the concerns of computer scientists, and focusing on the perceived greater convenience and hoped-for increased turnout. Many of these systems include email return of marked ballots, which computer scientists generally consider to be even riskier than web-based voting.

FVAP has been caught between the legal mandates and the technical experts. In an effort to break this logjam, they’ve organized a series of open fora – first in August 2010 just before USENIX Security in Washington DC, then in March 2011 just before the Electronic Verification Network workshop in Chicago IL, and last weekend just before USENIX Security in San Francisco CA. All three brought together representatives from FVAP, voting system vendors, election officials, computer scientists, and voting activists to discuss the issues. Several of the Freedom To Tinker bloggers have been present at all three meetings, and have been frustrated that the first two ended at an impasse – computer scientists saying “it doesn’t work” and FVAP (and others) saying “we need a solution anyway”.

Fortunately, the third meeting concluded in a far more constructive way. While all agree there are significant impediments, a consensus was reached that the best solution is a multi-stage competition, in much the same fashion as the National Institute of Standards and Technology (NIST) did for the Advanced Encryption Standard (AES) and is now performing for the Secure Hash Algorithm 3 (SHA-3).

The competition is structured as a series of phases that are completely open, which all expect to be at least somewhat controversial as some organizations (such as vendors) will want to protect their intellectual property. All submissions will be shared with the public, and competitive teams will be encouraged to critique each others’ submissions. In earlier phases this will be focused on the paper requirements and designs; in later phases this may include finding vulnerabilities in architectures and implementations. Submitters may claim patent and/or copyright on their submissions, but these must grant the public (including competitors) rights to use the submissions for analysis, including compiling, testing, and modifying software, for testing purposes. (However, submitters may preclude such use for production or resale purposes.) Thus, trade secrets will be precluded in the competitive process.

The competition will have three phases, each of which may include one or more iterations.

  • In the first phase (which as computer scientists was named “round 0″), submissions will focus on requirements for internet voting systems. Submitters will define characteristics that must be met in following phases. Submissions may also include use cases for which the requirements are applicable – for example, requirements that could apply in environments where all voters have smart cards, such as the US military. As described above, submissions will be open to the public, and anyone (especially submitters) will be encouraged to critique submissions to find the best aspects. At the conclusion of this round, FVAP will (possibly with the assistance of government experts) consolidate the requirements into a single set that will govern the following phase.
  • In the second phase (“round 1″), submissions will provide high level designs and detailed hardware and software architectures, along with procedures necessary for secure operation. The submissions for this round need to be detailed enough that a reasonably skilled person could implement a realization of the system, although many details such as user interfaces and database layouts will be undefined. As with the first phase, submissions will be open for critique. In this phase critiques will focus on identifying areas where designs do not meet the requirements defined in the first phase. The result may be modification of architectures to incorporate ideas from several teams. At the conclusion of this phase, FVAP will (again with assistance from government experts) narrow down the set of acceptable architectures. Or perhaps not – if no architecture is good enough to satisfy the requirements, FVAP may conclude that the experiment should not be run (and cancel the third phase).
  • In the third phase (“round 2″) submitters will create implementations of one or more of the architectures (perhaps even adopting architectures from other teams, if licensing terms permit). During the critique period, teams will seek to find security vulnerabilities in other implementations, and fix problems identified in their own implementation. Usability testing should be part of this phase, as systems too complex for voters to use effectively (even if secure) need to be identified and improved. At the conclusion of this phase, FVAP will identify one or more implementations that are adequate for meeting their demonstration project requirements. Or perhaps not – if no implementation is good enough, FVAP may conclude that the experiment should not be run.

What happens if there is no acceptable solution at the conclusion of the second or third phase? That’s possible – and if it happens, that may be cause for FVAP to request that Congress modify its charter to eliminate the requirement for online blank ballot return. If the best minds in the country conclude that internet voting is a perpetual motion machine, no amount of laws and regulations will make it possible.

How long will all this take? We estimate the entire process will take three or four years, allowing time for FVAP to publish a solicitation, organizations to create submission, the public critique period, FVAPs consolidation and decision making, and transition to the next phase.

In the meantime, there’s little doubt that some states will continue to move forward on the existing insecure solutions. We believe, and expect that most other computer scientists will agree, that this is a case to let science take its course before moving into implementation. We hope that FVAP will speak out publicly against such ill-advised experiments.

For now, we look forward to working with FVAP in realizing the first ever national internet voting competition.

(*) While there is some disagreement on interpretation of the law, since I’m not a lawyer and hence not competent to determine the accuracy of that interpretation, this blog entry presumes that the FVAP interpretation is correct.

(**) The term “military and overseas voters” means both military voters stationed away from their legal home (e.g., at a base in another state or overseas) and civilians living overseas (whether on a temporary basis such as contractors or on a permanent basis). Thus this includes people working for organizations like Peace Corps and embassies as well as expatriates. However, the FVAP mandate for internet voting only applies to overseas military voters, and not domestic military voters or overseas civilians.

Edited Aug 13 @ 12:17pmET: Changed first footnote to explain that I’m not a lawyer and hence not interpreting the law.

Edited Aug 15 @ 1:08pmET: Corrected name of EVN workshop.

avatar

The End of Gnutella?

Almost exactly 2 years ago, I wrote an essay that examined the case of Arista Records et al v. Lime Group et al. It was presented on Freedom-to-Tinker in a series of three posts (1, 2, 3). These articles presented an analysis which showed that any open filesharing network, such as Gnutella, is vulnerable to spamming. Lime Wire, without advertising as much, was acting as a spam cop for Gnutella, keeping the network safe for infringers. It was my view that the decision in the case could be made to turn on the actions that Lime Wire was taking to control spammers on the Gnutella network, and if the case were examined in that light, Lime Wire could be found liable for contributory infringement while still respecting the First Amendment rights of software publishers.

Since that time, a great deal has occurred in the world of filesharing. It is worthwhile to examine the the current state of affairs, which is predictable in some ways and yet quite surprising in others.

continue reading…

The Arista Records et al. v. Lime Group case has been a victory for the plaintiffs. On October 26, 2010, the court handed down an injunction that permanently prevents Lime Wire from distributing its software or running any servers that maintain the Lime Wire system.

Interestingly, the court largely sidestepped the technical issues as to whether Gnutella itself had non-infringing uses or not, or whether a Gnutella client can be legally distributed. The court’s decision instead turned on evidence submitted by the plaintiffs that LimeWire intended to facilitate filesharing.

As a part of the injunction, Lime Wire was required to “disable … all functionality of the Legacy Software”.

In response, Lime Wire took several actions.

  • Their website no longer advertises or distributes the LimeWire software. Instead, the entire site is replaced with fearsome notice of the court order, and the only thing downloadable now is a pdf file of the permanent injunction.
  • On Oct 26, 2010 LimeWire issued a final simpp.xml file. The simpp.xml file was used by Lime Wire to control various parameters of the operation of LimeWire clients. It contained, among other things, the ban lists – specific IP addresses of machines Lime Wire deemed to be engaged in “unwanted sharing”. No LimeWire client would connect to a machine on the ban list. The final simpp.xml file had an empty ban list, which had the effect of unblocking all files and IP addresses that had been banned from the network.
  • The simpp.xml file also controlled other aspects of LimeWire client operation – it could be used to inform running clients that a new version was available. In the case of LimeWire clients of version 5.5.11 or later, a feature had been added that shut down the client until the new version is loaded. No new version, however, was actually released. This had the effect of shutting off most LimeWire users.

This last action is rather significant. Many, if not most, modern programs include a feature that “phones home” to figure out when to inform the user that a new version has been released. Many allow automatic installations of the new version, without user intervention. It is most uncommon for such a notice to shut down the program if the user does not upgrade to the new version. It is doubtless unique among programs distributed under an open source license.

Indeed, this unusual feature of verson 5 of LimeWire was also accompanied by increased intrusiveness in Lime Wire’s ability to monitor the Gnutella network. Even before v5.5.11, in which LimeWire added this “kill switch” to the client, additional ability to inspect running clients had been added. It is interesting to contemplate just how intrusive these features were, all embedded in a very widely used open source program.

This state of affairs stands in sharp contast to what LimeWire told the court in its July 18, 2008 Motion for Summary Judgement:

[The simpp.xml file does not enable LW to] control what files users search for, choose to share, or download. Also, LW has no ability to alter, disable, or upgrade LimeWire remotely once it has been downloaded and installed by the user. If LW went out of business today, users could continue using LimeWire without interruption.

It appears that, behind the scenes, LimeWire knew it would be made to shut down its network well before the October injunction was issued. Version 5.5.11 was released on July 25, 2010, so LimeWire by that point was acting with the knowledge that it was going to be shut down.

Upon the demise of LimeWire as a useful client, many people simply stopped using Gnutella altogther. Though there are a large number of Gnutella clients, (see http://en.wikipedia.org/wiki/Gnutella#Software for a list) a substantial number of former LimeWire users switched to FrostWire, which got a great deal of buzz as a result. Unlike LimeWire, FrostWire does not embed ads in the client or distribute a “pro” version, and therefore the group that writes FrostWire does not have substantial revenue, as did Lime Wire.

Accordingly, the vigilant anti-spam activities that had been performed by Lime Wire disappeared from Gnutella. In a matter of short order, spammers of various sorts, including those whose intention was to block the sharing of infringing music files, managed once again to afflict the Gnutella network. In late June 2011, the FrostWire team announced that they would remove the Gnutella functionality from their code, and focus on improving the BitTorrent client. As argued before in this space, this outcome is exactly what should be expected of a filesharing network without effective spam policing.

Despite this victory over Lime Wire, and perhaps ultimately over Gnutella itself, it is unlikely that the RIAA and MPAA are raising the champagne glasses quite yet. In essence, the resurgence of BitTorrent as a music and video-sharing protocol brings the techical architecture full circle. The BitTorrent system resembles the original Napster more than Gnutella, as it has a centralized search and seeding system. The calculation made by the file-sharers appears to be that a game of legal whack-a-mole is sustainable in their favor, especially given the global nature of the hosting of trackers.

The next step for the copyright holders appears to be to get the ISPs involved in preventing filesharing, and to that end an agreement annouced on July 7 of this year between copyright holders and some of the largest ISPs is a step in that direction. Nonetheless, it is difficult to see how the relatively slow-moving copyright holders and ISPs will be able to shut down a network that is specifically intended to work as a darknet, hiding itself and moving from place to place.