Pages

Friday, May 14, 2010

Producing content like we develop software: Felten

Ed Felten thinks that writers might have a lot to learn from software developers. 
"There is something distinctive about how computer scientists write: we tend to use software development tools to "develop" our texts. This seems natural to us. A software program, after all, is just a big text, and the software developers are the authors of the text. If a tool is good for developing the large, complex, finicky text that is a program, why not use it for more traditional texts as well?
Like software developers, computer scientist writers tend to use version control systems. These are software tools that track and manage different versions of a text. What makes them valuable is not just the ability to "roll back" to old versions -- you can get that (albeit awkwardly) by keeping multiple copies of a file. The big win with version control tools is the level of control they give you. Who wrote this line? What did Joe write last Tuesday? Notify me every time section 4 changes. Undo the changes Fred made last Wednesday, but leave all subsequent changes in place. And so on. Version control systems are a much more powerful relative of the "track changes" and "review" features of standard word processors.
Another big advantage of advanced version control is that it enables parallel development, a style of operation in which multiple people can work on the text, separately, at the same time. Of course, it's easy to work in parallel. What's hard is to merge the parallel changes into a coherent final product --- which is a huge pain in the neck with traditional editing tools, but is easy and natural with a good version control system...
While version control and parallel development have become standard in computer science writing, there are other software development practices that are only starting to cross the line into CS writing: issue tracking and the release early and often strategy.
Issue tracking systems are used to keep track of problems, bugs, and other issues that need to be addressed in a text. As with version control, you can do this manually, or rely on a simple to-do list, but specialized tools are more powerful and give you better control and better visibility into the past...

"Release early and often" is a strategy for rapidly improving a text by making it available to users (or readers), getting feedback, and rapidly turning out a new version that addresses the feedback. Users' critiques become issues in the issue tracking system; authors modify the text to address the most urgent issues; and a new version is released as soon as the text stabilizes. The result is rapid improvement, aligned with the true desires of users. This approach requires the right attitude from users, who need to be willing to tolerate problems, in exchange for a promise that their critiques will be addressed promptly.
What does all of this mean for writers who are not computer scientists? I won't be so bold as to say that the future of writing will be just exactly like software development. But I do think that the tools and techniques of software development, which are already widely used by computer scientist writers, will diffuse into more common usage. It will be hard to retrofit them into today's large, well-established editing software, but as writing tools move into the cloud, I wouldn't be surprised to see them take on more of the attributes of today's software development tools."
Content producers, including my own wonderful employer, the Open University, should take note.

Wednesday, May 12, 2010

Astroturfing net neutrality

Cory Doctorow is fuming over telcos secret plans to kill net neurality.
"ThinkProgress has a leaked copy of a telcoms industry PowerPoint presentation laying out their plans to use astroturf to kill Network Neutrality. The industry is hiring the same turfers who work with the Tea Party movement to carry their message to the people.

What the telcos want to do is reduce your access to websites and services unless those services have paid a bribe for "premium carriage" to you. So Google buys its bandwidth from its ISP. You buy your bandwidth from your ISP. Then your ISP goes to Google and says, "If you want to send your bits to our customers when they ask for them, you'll have to pay us too." If Google doesn't pay, the ISP slows down its bits when you ask for them.

They call this "free and unregulated internet access for content flow and connectivity speed free and unregulated internet access for content flow and connectivity speed."

Here's how I see it: the telcos and cable operators got a huge public subsidy when we agreed to let them use our public sewers, tunnels and streets (not to mention our houses and basements) for their wires. We give them all this for free or far below the market costs. They put their wires in our dirt.

Now they're saying they don't want to give us the service we want. Literally. That's what fighting Net Neutrality is about: it's ISPs fighting for the right to slow down or discard the bits you, the customer, ask for.

I say, it's our dirt, so we make the rules. If they don't like those rules, let them get their goddamned wires out of our dirt, off our streets, out of our basements. Let's give them 60 days, and if they haven't pulled up their wires by then, we'll buy them for the scrappage price of the copper. Then we'll turn over those wires to companies that are willing to give us the bits we want in exchange for the billions (trillions?) worth of public subsidy these greedy corporate welfare bums are currently enjoying.

Nowhere in the Constitution does it say, "Congress shall give away the public's priceless assets to companies and then sit around sucking its collective thumb while the companies screw the public." If AT&T and Comcast don't want to give us the service we want, let them buy every inch of conduit and right-of-way at market prices. Until then, they can STFU and give us the network we demand."
Update: ThinkProgress on same.

Tuesday, May 11, 2010

Electronic voting insecure

After the shambles last week of many people being turned away from the polls we have the inevitable call for electronic and internet voting.  We know however that the electronic voting systems currently deployed are seriously insecure. Hari K. Prasad, J. Alex Halderman, Rop Gonggrijp have reinforced this with a study of India's evoting machines which they demonstrate are vulnerable to fraud.



From the team's press release:

"Says Gonggrijp: "Never mind what election officials say, this research once again shows that the longstanding scientific consensus holds true—DRE voting machines are fundamentally vulnerable. Such machines have already been abandoned in Ireland, the Netherlands, Germany, Florida and many other places. India should follow suit."
Gonggrijp continues: "In order to have any transparency in elections, you need to have votes on paper. Computers can be programmed to count votes honestly, but since nobody can watch them, they might just as easily be programmed to count dishonestly. How is the voter supposed to tell the difference?""
Alex Haldemann comments:
"I've studied electronic voting machines for years, but I've never had such a strong sense that actual fraud might be taking place. There have been dozens of reports from around India that politicians have been approached by engineers offering to manipulate the machines to steal votes. My Indian coauthor, Hari Prasad, was himself approached by a prominent party and asked to help them with such manipulations! It's just too easy, thanks to the simple design of the machines and the lack of adequate safeguards, and there are probably a million people in India with the necessary electronics skills.
Many people believe that using a simple design makes these machines safer than the complex machines used in the U.S. (which sometimes contain almost a million lines of code), but simple machines are much easier to attack via hardware, and simplifying too much means giving up standard security techniques like strong cryptography. Essentially, you're left with a system that depends entirely on the physical security of the machines, just like paper ballots depend on the security of the ballot box, but with much less transparency than paper voting. What India and other democracies need is a system that's both secure *and* transparent, so that voters can have well-founded confidence their votes count."

Ed Felten says:
"The independent Electoral Commission of India, which is generally well respected, has dealt poorly with previous questions about EVM security. The chair of the Electoral Commission has called the machines "infallible" and "perfect" and has rejected any suggestion that security improvements are even possible. I hope the new study will cause the EC to take a more realistic approach to EVM security.
The researchers got their hands on a real Indian EVM which they were able to examine and analyze. They were unable to extract the software running in the machine (because that would have required rendering the machine unusable for elections, which they had agreed not to do) so their analysis focused on the hardware. They were able to identify several attacks that manipulated the hardware, either by replacing components or by clamping something on to a chip on the motherboard to modify votes. They implemented demonstration attacks, actually building proof-of-concept substitute hardware and vote-manipulation devices.
Perhaps the most interesting aspect of India's EVMs is how simple they are. Simplicity is a virtue in security as in engineering generally, and researchers (including me) who have studied US voting machines have advocated simplifying their design. India's EVMs show that while simplicity is good, it's not enough. Unless there is some way to audit or verify the votes, even a simple system is subject to manipulation."
Update: Check out also ORG's briefing on why evoting systems are difficult to secure.