January 19, 2017

Stopping SOPA's Anticircumvention

The House’s Stop Online Piracy Act is in Judiciary Committee Markup today. As numerous protests, open letters, and advocacy campaigns across the Web, this is a seriously flawed bill. Sen. Ron Wyden and Rep. Darell Issa’s proposed OPEN Act points out, by contrast, some of the procedural problems.

Here, I analyze just one of the problematic provisions of SOPA: a new “anticircumvention” provision (different from the still-problematic anti-circumvention of section 1201). SOPA’s anticircumvention authorizes injunctions against the provision of tools to bypass the court-ordered blocking of domains. Although it is apparently aimed at MAFIAAfire, the Firefox add-on that offered redirection for seized domains in the wake of ICE seizures, [1] the provision as drafted sweeps much more broadly. Ordinary security and connectivity tools could fall within its scope. If enacted, it would weaken Internet security and reduce the robustness and resilience of Internet connections.

The anticircumvention section, which is not present in the Senate’s companion PROTECT-IP measure, provides for injunctions, on the action of the Attorney General:

(ii)against any entity that knowingly and willfully provides or offers to provide a product or service designed or marketed by such entity or by another in concert with such entity for the circumvention or bypassing of measures described in paragraph (2) [blocking DNS responses, search query results, payments, or ads] and taken in response to a court order issued under this subsection, to enjoin such entity from interfering with the order by continuing to provide or offer to provide such product or service. § 102(c)(3)(A)(ii)

As an initial problem, the section is unclear. Could it cover someone who designs a tool for “the circumvention or bypassing of” DNS blockages in general — even if such a person did not specifically intend or market the tool to be used to frustrate court orders issued under SOPA? Resilience in the face of technological failure is a fundamental software design goal. As DNS experts Steve Crocker, et al. say in their Dec. 9 letter to the House and Senate Judiciary Chairs, “a secure application expecting a secure DNS answer will not give up after a timeout. It might retry the lookup, it might try a backup DNS server, it might even restart the lookup through a proxy service.” Would the providers of software that looked to a proxy for answers –products “designed” to be resilient to transient DNS lookup failures –be subject to injunction? Where the answer is unclear, developers might choose not to offer such lawful features rather than risking legal attack. Indeed, the statute as drafted might chill the development of anti-censorship tools funded by our State Department.

Some such tools are explicitly designed to circumvent censorship in repressive regimes whose authorities engage in DNS manipulation to prevent citizens from accessing sites with dissident messages, alternate sources of news, or human rights reporting. (See Rebecca MacKinnon’s NYT Op-Ed, Stop the Great Firewall of America. Censorship-circumvention tools include Psiphon, which describes itself as an “Open source web proxy designed to help Internet users affected by Internet censorship securely bypass content-filtering systems,” and The Tor Project.) These tools cannot distinguish between Chinese censorship of Tiananmen Square mentions and U.S. copyright protection where their impacts — blocking access to Web content — and their methods — local blocking of domain resolution — are the same.

Finally, the paragraph may encompass mere knowledge-transfer. Does telling someone about alternate DNS resolvers, or noting that a blocked domain can still be found at its IP address — a matter of historical record and necessary to third-party evaluation of the claims against that site — constitute willfully “providing a service designed … [for] bypassing” DNS-blocking? Archives of historic DNS information are often important information to legal or technical network investigations, but might become scarce if providers had to ascertain the reasons their information was being sought.

For these reasons among many others (such as those identified by my ISP colleague Nick), SOPA should be stopped.

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.

Deceptive Assurances of Privacy?

Earlier this week, Facebook expanded the roll-out of its facial recognition software to tag people in photos uploaded to the social networking site. Many observers and regulators responded with privacy concerns; EFF offered a video showing users how to opt-out.

Tim O’Reilly, however, takes a different tack:

Face recognition is here to stay. My question is whether to pretend that it doesn’t exist, and leave its use to government agencies, repressive regimes, marketing data mining firms, insurance companies, and other monolithic entities, or whether to come to grips with it as a society by making it commonplace and useful, figuring out the downsides, and regulating those downsides.

…We need to move away from a Maginot-line like approach where we try to put up walls to keep information from leaking out, and instead assume that most things that used to be private are now knowable via various forms of data mining. Once we do that, we start to engage in a question of what uses are permitted, and what uses are not.

O’Reilly’s point –and face-recognition technology — is bigger than Facebook. Even if Facebook swore off the technology tomorrow, it would be out there, and likely used against us unless regulated. Yet we can’t decide on the proper scope of regulation without understanding the technology and its social implications.

By taking these latent capabilities (Riya was demonstrating them years ago; the NSA probably had them decades earlier) and making them visible, Facebook gives us more feedback on the privacy consequences of the tech. If part of that feedback is “ick, creepy” or worse, we should feed that into regulation for the technology’s use everywhere, not just in Facebook’s interface. Merely hiding the feature in the interface, while leaving it active in the background would be deceptive: it would give us a false assurance of privacy. For all its blundering, Facebook seems to be blundering in the right direction now.

Compare the furor around Dropbox’s disclosure “clarification”. Dropbox had claimed that “All files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password,” but recently updated that to the weaker assertion: “Like most online services, we have a small number of employees who must be able to access user data for the reasons stated in our privacy policy (e.g., when legally required to do so).” Dropbox had signaled “encrypted”: absolutely private, when it meant only relatively private. Users who acted on the assurance of complete secrecy were deceived; now those who know the true level of relative secrecy can update their assumptions and adapt behavior more appropriately.

Privacy-invasive technology and the limits of privacy-protection should be visible. Visibility feeds more and better-controlled experiments to help us understand the scope of privacy, publicity, and the space in between (which Woody Hartzog and Fred Stutzman call “obscurity” in a very helpful draft). Then, we should implement privacy rules uniformly to reinforce our social choices.