All the Perl that's Practical to Extract and Report

Open Source in Government

chromatic on 2003-04-02T19:14:52

Tomorrow, Oregon House Bill 2892 (also here) goes before the General Government Committee for discussion. If successful, it will then go before the Ways and Means Committee, then to the House floor for a vote.

I'm particularly interested in the discussion of open standards and document formats. Open Source and Free Software have several advantages here. The text of the bill mentions a few. Here's what I see:

  • Data will remain accessible where proprietary software might change document formats and licensing terms.
  • It is possible to switch vendors, as no one vendor can sell software to read documents of that type exclusively.
  • Citizens are free to choose software from several vendors to access public documents. It's possible they can run this software on their choice of computer at their choice of location -- home, work, a free lab, a library, a government office. This is immensely important: the cost or availability of a software package should not be a barrier to public involvement.
  • Where possible, the government should encourage development of resources for the public good. Support and development resources should go toward projects and knowledge that is freely accessible to the public, not locked away in one company or another.

Anything I've overlooked?

Security

vsergu on 2003-04-02T19:46:20

Especially in the current environment, it's good to raise the point that open-source software is more auditable (and, some claim, more audited) than closed-source. You never know sort of backdoors and security holes might be in the proprietary software you install. The fact that many jurisdictions are now using proprietary software for voting machines (with no paper trail) and not even being allowed to look at the software is making me far more paranoid than I used to be.

Of course, the other side has its own arguments about how keeping the source secret improves security, and they'll certainly be making that argument.

Re:Security

chromatic on 2003-04-02T20:13:46

That's a very good point. I'm certainly all for transparency in government and government software. It's also mentioned in the bill. Other people will likely cover that in their testimony and supporting documentation.

Is there a way to cover the auditability aspect of Open Source while discussing open standards and protocols? I'd like to stay within that narrow topic -- it helps to be laser-precise when talking to lawyers and legislators. :)

Re:Security

ziggy on 2003-04-02T20:51:10

Is there a way to cover the auditability aspect of Open Source while discussing open standards and protocols? I'd like to stay within that narrow topic -- it helps to be laser-precise when talking to lawyers and legislators. :)
Perhaps. Is there any chance you can get Whitfield Diffie on your side? (On second thought, he's a pretty great mind and a deep thinker, but he rambles almost incomprehensibly at times.)

Diffie's argument revolves around a fundemental tenet of security: a secret is only as good as your ability to change it. For example, suppose you have a combination lock on the front door of the office. You may consider it secure because it cannot be cracked(!), and furthermore it is a closed, proprietary combination lock -- no one knows what goes on inside.

Now suppose you have 100 employees in your facility. Each and every one of them knows the combination. That's fine, because each and every one of them is trustworthy(!) and no one would squeal.

Now suppose your impenetrable combination lock gets cracked. What do you do? You can't change the combination because your 100 employees won't be able to get into the office anymore. Because you can't change your cracked combination, someone else who is not trustworthy can enter your building any time he wants without your permission, simply because you cannot change the combination.

Oh, and let's not forget that an untrustworthy cracker is unlikely to be afraid of breaking the law or even the Patriot act....

This analogy is the basis of Diffie's refutation of security by obscurity. A closed source package has its source code obscured. You cannot change it easily. It will have security holes -- every piece of software of value does. However, you cannot fix them -- only your vendor can fix them, and only on his timescale. Furthermore, because closed source software relies on a secret that cannot be easily changed (the binaries), it is fundementally insecure.

Open source, on the other hand, does not have this property. It is a secret that can be easily changed (much like a PGP key can be revoked and reissued). It is open to inspection, so it is more likely people will find security bugs. Furthermore, because it is easily changed, it is more likely to keep your secrets.

(I hope that makes some sense. It was early in the morning and Diffie was wandering pretty far afield when I heard him speak...)

Re:Security

brev on 2003-04-03T04:35:50

Changeability: that is a brilliant insight.

Excellent refutation of biometrics for free, too.

Unfortunately security-by-obscurity seems to be the first instinct of every layperson out there.

Perhaps it's because their only experience of security is dealing with passwords. They know that they are supposed to be all tricksy with their passwords, so they have the sense that computer security == being tricksy.

Perhaps one should meet that head on, explain that the ideal security system has no secrets at all, except for the password.

Re:Security

wickline on 2003-04-02T21:21:16

> cover the auditability aspect of Open Source
> while discussing open standards and protocols

HTTP Basic Auth clearly defines how your auth info is sent over the network, and so folks know not to use it for Important Things. If it wasn't defined, you might just cross your fingers and hope it was sufficiently secure. Instead, you know to use digest auth or basic auth over HTTPS.

A DTD can clearly define the content of a document, and that document can be determined to be well-formed by freely available tools. If the DTD is sufficiently strict, you can be sure that no mystery data is being included accidentally. Compare this with the fuss some folks made a number of years back when they learned that MS Word documents contained
        - the path to the document on their machine
        - information about which printers they used
        - their contact information
        - occasional random hard drive data from allocated
            storage space which hadn't been zero'ed out

-matt

Re:Security

vsergu on 2003-04-02T21:30:42

Another worrisome thing MS Word documents can contain internally is text from previous versions that the user thinks has been completely deleted, especially if "Fast Save" is enabled (the default configuration, at least at one time).

other advantages.

gav on 2003-04-02T20:34:20

The main advantages of open source to me is that if it breaks, or doesn't do something you need it to, it's possible to hire somebody to fix it.

You also don't worry about support way into the future, it should be trivial to find somebody in 10 years time to work on it, there's no fear that the company you bought it from will cease to be.

The role of Government

ziggy on 2003-04-02T21:10:52

I vague remember someone reminiscing a question that came up at some sort of government and technology event recently:
  • Raise your hand if you are using the same software you were using 10 years ago. (no hands go up)
  • Raise your hand if you have data that is 10 years old in your organization that is still meaningful to you. (all hands go up)
Government data has a long life. Government is also funded by the people to serve the public good. Choosing proprietary document formats can impede the government from fufilling its mission in any number of ways:
  • increasing the cost of accessing public data
  • decreasing the utility of public data
  • increasing the cost for government to maintain and create public data (e.g. paying for format conversions down the road because today's choice of format is inaccessible)
  • decreasing the lifespan of public documents
A good example of this is the EDGAR filings database maintained by the SEC. The last time I looked at this about 4-5 years ago, all SEC filings were made electronically -- in SGML. Sure, SGML is a baroque format, but at the heart of it all, it's just text. Sure, there are formatting differences between filers, but at the heart of it all, it's just text. (I won't mention that the world's most preferred SGML tools are open source.) I have no doubt that I can read the first SEC filings that were made available through EDGAR, nor do I have any doubt I'll still be able to do so in 20 years time.

There's a similar example with the IRS -- all forms are made available in PDF.

There's also a growing body of experience in Europe using Open Source.

That's about all I can think of at the moment about open document formats. There's a lot more to be said about using open standards and open source.

Re:The role of Government

gnat on 2003-04-03T11:24:39

I vague remember someone reminiscing a question that came up at some sort of government and technology event recently
You're thinking of Tim Bray. See "XML Confers Longevity" in this blog entry.

--Nat

Re:The role of Government

jdavidb on 2003-04-03T18:30:26

I won't mention that the world's most preferred SGML tools are open source

And the nice thing is that you don't have to. Anyone getting into those will find them anyway.

Sometimes I think if the open source community just keeps quietly creating better and better stuff, they will eventually win the war.