December 22, 2024

Archives for 2010

Needle-in-a-Haystack Problems

Sometimes the same idea comes flying at you from several directions at once, and you start seeing that idea everywhere. This has been happening to me lately with needle-in-a-haystack problems, a concept that is useful but often goes unrecognized.

A needle-in-a-haystack problem is a problem where the right answer is very difficult to determine in advance, but it’s easy to recognize the right answer if someone points it out to you. Faced with a big haystack, it’s hard to find the needle; but if someone tells you where the needle is, it’s easy to verify that they’re right.

This idea came up in a class discussion of Beth Noveck’s Wiki-Government paper. We were talking about how government can use crowdsourcing to learn from outside experts, and somebody pointed out that crowdsourcing can work well for needle-in-a-haystack problems. If somebody in the crowd knows the answer, they can announce it, and other participants in the discussion will recognize that the proposed answer is correct. This is the basis for the open-source maxim that “given enough eyes, all bugs are shallow”. It’s also the theory underlying the Peer to Patent project, in which distributed experts tried to find the best prior art document that would invalidate a patent application.

The idea came up again in a discussion of online passwords. A highly secure system doesn’t remember your password, because an attacker who managed to observe the stored password could impersonate you. But if the system doesn’t store your password, how can it verify that the password you enter is correct?

The answer is that the system can create a needle-in-a-haystack problem to which your password is the only right answer. By remembering this problem rather than your password, the system will be able to recognize your password when it sees it, but an attacker who learns what the problem is will have great difficulty determining your password. There are standard cryptographic tricks for generating this kind of needle-in-a-haystack problem.

The idea came up a third time when I read a paper with the eye-catching title “Why Most Published Research Findings Are False“. The paper explains why the vast majority of research findings in a field might be false, even if the researchers do everything right; and it suggests that this is the case for some areas of medical research.

To see how this might happen, imagine a needle-in-a-haystack problem that has one right answer and a million wrong answers. Suppose that our procedure for verifying the right answer when we see it is not flawless but instead is wrong 0.01% of the time. Now if we examine all of the 1,000,000 wrong answers, we will incorrectly classify 100 of them (0.01% of 1,000,000) as correct. In total, we’ll find 101 “correct” answers, only one of which is actually correct. The vast majority of “correct” answers — more than 99% of them — will be wrong.

Any research field that is looking for needles in haystacks will tend to suffer from this problem, especially if it relies on statistical studies, which by definition can never yield absolute 100% confidence.

Which brings us back to crowdsourcing. If we’re not perfect at recognizing proposed answers as correct — and no human process is perfect — then a crowdsourcing approach to needle-in-a-haystack problems could well yield wrong answers most of the time.

How can we avoid this trap? There are only two ways out: reduce the size of the haystack, or improve our procedure for evaluating candidate answer. Here crowdsourcing could be helpful. If we’re lucky, vigorous discussion within the crowd will help to smoke out the false positives. It’s not just access to experts that helps, but dialog among the experts.

Release Government Data, Early and Often

One of the key axioms of modern open government is that all public data should be published online in a raw but usable form. Usability in this case is aimed at software programmers. By making government datasets more usable, programmers are more likely to innovate in the civic sphere and build technologies, using the raw data, to enhance the relationships among citizens and with government.

The open government community has provided plenty of valuable guidance about what usability means for programmers. We proclaim that all datasets need to be: published in a format that is reasonably structured and machine-processable; well-documented; downloadable in bulk; authenticated using cryptographic digital signatures; version-controlled; permanent and citable; and the list goes on and on. These are all worthy principles to be sure, and all government datasets should strive to meet them.

But you’ll be hard-pressed to find any government datasets that exist with all of these principles pre-satisfied. While some are in better shape than others, most datasets would make programmers cringe. Data often only exist as informal working sets in proprietary Excel spreadsheets. Sometimes they are in structured databases, but schemas are undocumented, field values are ambiguous, and the semantics are only understood by the employee who created them. Datasets have errors and biases that are known but never explicitly corrected.

For a civil servant who is a data caretaker looking over the laundry list of publishing principles, there’s frequently a huge quality chasm between the dataset she owns and how people are asking to see it released. To her, publishing this data adequately just seems like a lot of extra work. The more attractive alternative is to put off the data publishing—it’s not in her job description or evaluations anyway—and move on to other work instead.

How can this chasm be bridged? A widely-adopted philosophy in software development and entrepreneurship would serve open government data well: release early and release often. And listen to your customers.

In the software development world, a working version of the product is pushed out as soon as possible even with known imperfections—an “alpha” release—so it can be subject to real use by early adopters. Early adopters can provide helpful feedback about what works, what’s broken, and what new features would be most useful to them. The software developers then iterate quickly. They incorporate the suggested fixes and features into their code and release an updated version of the product to their users. The virtuous cycle then starts again. Under this philosophy, software developers can be efficient about how to best improve their code where it matters, and users get software that works better and has more features they desire.

The “release early, release often” philosophy should be applied to government data. For the initial release, data caretakers should take the path of least resistance to get data out the door. This means publishing datasets in whatever format is most convenient, along with as much documentation as can reasonably be mustered. Documentation is especially important with an “alpha” dataset—proper warnings about its problems, instabilities and inductive limitations must be prominently displayed. (Of course, the usual privacy and legal caveats should also be applied.) Sometimes, the “alpha” release will be “good enough” for programmers to start their work, and this will minimize any superfluous work done by caretakers. This is the virtue of “release early.”

In other cases, programmers will need assistance using the dataset and will notice problem spots with the initial release. The dataset might be confusing, contain errors or be difficult to work with. A tight feedback mechanism allows the programmer to get help quickly and continue to innovate, while the data caretaker can fix problems based on real use cases and add clarifying metadata into an updated version of the dataset. Data quality and usability increases for those working with the dataset, both in and outside of government. That’s the virtue of “release often.”

And here is the big opportunity for government: no platform currently exists to engage the prime audience for government data—software programmers. Without a tight feedback mechanism, the virtuous cycle of mutual benefit cannot exist. Government is missing its best opportunity to improve data quality by neglecting useful feedback from programmers who are actually tinkering with the datasets. Society is losing out on potentially game-changing civic innovations, which otherwise would have been built if data were more usable and the uncertainty of failure reduced.

A terrific start in turning the corner would be for government to adopt an issue-tracking system for its datasets. As a public venue, it would help ensure that data caretakers are prompt in addressing developer concerns. It would also allow caretakers to organize feedback in a formal way. Such platforms are commonplace in any successful software development venture. The same needs to be true for government data in order to drive rapid quality improvements and increase developer engagement.

Google Publishes Data on Government Data and Takedown Requests

Citizens have long wondered how often their governments ask online service providers for data about users, and how often governments ask providers to take down content. Today Google took a significant step on this issue, unveiling a site reporting numbers on a country-by-country basis.

It’s important to understand what is and isn’t included in the data on the Google site. First, according to Google, the data excludes child porn, which Google tries to block proactively, worldwide.

Second, the site reports requests made by government, not by private individuals. (Court orders arising from private lawsuits are included, because the court issuing the order is an arm of government.) Because private requests are excluded, the number of removal requests is lower than you might expect — presumably removal requests from governments are much less common than those from private parties such as copyright owners.

Third, Google is reporting the number of requests received, and not the number of users affected. A single request might affect many users; or several requests might focus on a single user. So we can’t use this data to estimate the number of citizens affected in any particular country.

Another caveat is that Google reports the country whose government submitted the request to Google, but this may not always be the government that originated the request. Under Mutual Legal Assistance Treaties, signatory countries agree to pass on law enforcement data requests for other signatories under some circumstances. This might account for some of the United States data requests, for example, if other countries asked the U.S. government to make data requests to Google. We would expect there to be some such proxy requests, but we can’t tell from the reported data how many there were. (It’s not clear whether Google would always be able to distinguish these proxy requests from direct requests.)

With these caveats in mind, let’s look at the numbers. Notably, Brazil tops both the data-requests list and the takedown-requests list. The likely cause is the popularity of Orkut, Google’s social network product, in Brazil. India, where Orkut is also somewhat popular, appears relatively high on the list as well. Social networks often breed disputes about impersonation and defamation, which could lead a government to order release of information about who is using a particular account.

The U.S. ranks second on the data-requests list but is lower on the takedown-requests list. This is consistent with the current U.S. trend toward broader data gathering by law enforcement, along with the relatively strong protection of free speech in the U.S.

Finally, China is a big question mark. According to Google, the Chinese government claims that the relevant data is a state secret, so Google cannot release it. The Chinese government stands conspicuously alone in this respect, choosing to deny its citizens even this basic information about their government’s activities.

There’s a lot more information I’d like to see about government requests. How many citizens are affected? How many requests does Google comply with? What kinds of data do governments seek about Google users? And so on.

Despite its limitations, Google’s site is a valuable step toward transparency about governments’ attempts to observe and control their citizens’ online activities. I hope other companies will follow suit, and that Google will keep pushing on this issue.

April 27 Workshop at Princeton CITP: Internet Security, Internet Freedom

On April 27th, the Center for Information Technology Policy is hosting a one-day workshop on campus here at Princeton. We invite you to attend. Here is the summary of the event, called Internet Security, Internet Freedom:

The internet is at once a means for great openness and great control — expression and exclusion. These forces have long been at work online, but have recently come to the fore in debates over the United States’ cyber security policy and its increased focus on “internet freedom.” The country now has a Cybersecurity “czar” that has presented a 12-part national initiative, and also has a Secretary of State who has forcefully stated the case for internet freedom. But what do these principles mean in practice?

This workshop explores how security and freedom both compliment each other and compete. A spectrum of security risks at different layers of the network beg for technical and governance solutions. Flash points like the recent Google-in-China developments highlight the nexus of security and speech. A growing discourse about internet freedom calls out for workable theories and models. This event will bring together technologists, policymakers, and academics to discuss the state of play and viable ways forward.

The keynote speaker will be Alec Ross, Senior Advisor for Innovation in the Office of Secretary of State. Alec will discuss the State Department’s increased focus on the issue of Internet freedom. He recently commented that 2009 was “the worst year in the history of the Internet as it related to Internet freedom.” The panelists feature a variety of experts on issues of online freedom as well as network security.

Please join us. For more information and instructions on how to register, see the workshop page here:
http://citp.princeton.edu/internet-security-internet-freedom/

Flash, Scratch, Ajax: Apple's War on Programming

Any ambitious regulatory scheme will face pressure to expand, in order to protect the flanks of the main regulation against users’ workarounds. Apple’s strategy of regulating which apps can run on the iPhone and iPod is just such a regulation, and over the last week or so Apple has been giving in to the pressure to expand its regulation.

To illustrate Apple’s regulatory problem, consider a hypothetical iPad app called Ed’s App World (EAW). EAW lets you download items called EdApps, which consist of instructions that the EAW app carries out. Any developer can create an EdApp which expresses its instructions in Ed’s Programming Language. It’s entirely possible to create an app like EAW.

Apple’s regulatory problem is that Ed’s App World is effectively a competing app store — EdApps can do anything that apps can do, and any developer can create and distribute an EdApp. If Apple wants to prevent competing app stores, it has to keep apps like Ed’s App World from existing.

Apple has long been trying to keep specific technologies like Adobe’s Flash off the iPhone and iPad because these technologies have EAW-like features. Now Apple has expanded its regulation to say that only certain programming methods are acceptable. Here’s section 3.3.1 of Apple’s iPhone developer license agreement:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

This rules out many common programming languages and tools. To developers, it looks like Apple is trying to micromanage how they do their work.

Apple’s ban on programmable apps goes beyond just Flash. This week Apple banned Scratch, a widely used educational tool that introduces students gently to computer programming by letting them construct animations. Why did Apple ban the Scratch app? Presumably because Scratch animations involve elements of programming. Computing educators were unhappy, to say the least. Mark Guzdial of Georgia Tech put it this way: “Want to be truly computing literate, where you write as well as read? There’s no app for that.”

What’s really interesting is that despite Apple’s best efforts to block these apps, there is an enormous EAW-type system that Apple hasn’t had the guts to block: the web. Thanks to so-called Ajax technologies, the web has become a vehicle for delivering app-like functionality (within web pages). Apple’s Safari browser on the iPhone and iPad supports these apps well. It’s hard to imagine that Apple could get away with blocking all of the Ajax-enabled sites we use every day. And Apple’s Ajax problem will become even worse as HTML 5 comes online, with even better support for web-based apps.

If you’re not a techie, this stuff may seem like inside baseball to you. But it does affect what you can do and see. You may not know all of the details of why the app store starts looking more and more like Disneyland, but you’ll notice that it’s happening.

Finally, I want to address the common objection that most people don’t care about limits on programming, because they don’t know how to program. To me, this is like saying that you don’t care about restaurant closings because nobody in your house knows how to cook. If you can’t cook for yourself, you should care more about restaurant quality. If all of the good restaurants close, good cooks will just make their own good meals — but you’ll be out of luck.