As stated in the note from the Sunlight Foundation′s Board Chair, as of September 2020 the Sunlight Foundation is no longer active. This site is maintained as a static archive only.

Follow Us

Tag Archive: Security

Reasons (Not) to Release Data

by

Earlier this year, Sunlight was issued a challenge: Collect and refute the most common reasons not to release data. As many open access advocates, journalists, and government employees themselves will tell you, there are a variety of "no's" given when the question of data disclosure arises. Many are predictable, some are political, some personal, many practical, and all deserving of attention. Pioneers looking to move their government toward exploring and advancing information release have already come up with rebuttals to many of these refusals, but the collective knowledge is hard to share, usually trapped in email groups, discussion boards, blogs, and the memories and experiences of individuals. So, we're going to meet our challenge with an experiment.

Continue reading

The Worst Government Website We’ve Ever Seen?

by

Yesterday the government's Federal Awardee Performance and Integrity Information System (FAPIIS) came online. This is something we've been looking forward to for a while. It's easy to find horror stories about the mismanagement of contracts; this isn't surprising when you consider the disorganized constellation of contractor oversight databases that exists, many of which aren't open to the public. Getting FAPIIS online should be a step toward fixing that problem. Yesterday government took that step.

POGO has some thoughts about it that are certainly worth your time. But we can't help chiming in as well. In short: this site is terrible. As one colleague said, "This might be the worst website I've ever seen."

This is at least debatable. Contracting databases are part of the world of procurement, procurement is heavily influenced by the Defense Department, and DoD has a proud heritage of producing websites so ugly that they make you want to claw out your eyes. So FAPIIS has company. But if this was just a question of aesthetics, we wouldn't be complaining.

Assuming you're using one of the few web browsers in which the site works at all (Chrome and Safari users are out of luck), the experience is off-putting from the start, as users are warned that their use of the site may be monitored, surveilled, or otherwise spied upon (you don't necessarily surrender your right to speak privately to your priest by using the website, though--thanks for clearing that up, guys!). Perhaps this is why their (arguably superfluous) SSL certificate is utterly broken. But let's click past the security warnings and proceed.

Here's the next screen. It contains a captcha.

Let's be clear: the use of a captcha to gate government data is outrageous. Government should be making its data more accessible and more machine-readable. Captchas are designed to interfere with automated tools that facilitate malicious acts. But downloading government data is decidedly not a malicious act. Why are we trying to limit machines' ability to use this data?

But our irritation with the captcha is softened a bit by how laughably inept its implementation is. It's made of black and white text, unrotated, unskewed, superimposed on the same black and white grid every time. Here's a stab at how you'd beat it:

  1. Subtract grid
  2. Flip every white pixel that's bordered by 2 or more black pixels to black
  3. Identify columns of all-white pixels and slice the image by them
  4. Crop the resulting slices, then recombine
  5. OCR

You could probably get this done using a stock PHP distribution in about an afternoon. But you don't need to, because even this pathetic level of security isn't properly implemented! Instead the human-readable text is sent to the client as a SHA1 hash in a hidden field. That hash is compared to the hash of what the user enters for the captcha code. So a scraper can just ignore the captcha and resend a solved hash for every request -- it'll work just fine1. They didn't even salt the hash. Whoever wrote this has absolutely no idea how to implement a secure system.

After the captcha, things start to get really weird, with radio buttons with onclick handlers being used as hyperlinks. It's unclear to me whether the programmers responsible for this interface had ever actually used the web or simply had it described to them. Either way, whoever built this should be embarrassed. Whoever managed the project should be embarrassed. Whoever signed off on delivery should be embarrassed! But we haven't even gotten to the worst part yet.

That's because while all of the above will be embarrassing to any developer who takes pride in his or her craft, the quality of a government website is ultimately less important than the data it exposes. And there is no FAPIIS data in FAPIIS. Not yet, anyway. Such data exists, mind you. But the decision was made not to include any historical data when FAPIIS went public. Presumably the contractors who did a bad job, and who were reported for doing so, are concerned that people might look at those reports and get the impression that, uh, they did a bad job. Others may be concerned that the database could cast them in a bad light and raise uncomfortable questions. That government caved in to the demands of these vendors -- vendors who are supposed to be serving government! -- can only be described as an act of craven capitulation. We've FOIAed for this data, and if we're lucky, perhaps we'll even get it. But it ought to be online right now.

As a matter of principle, it's good to see government opening closed databases, and Congress deserves credit for deciding to open this one. But what has followed that decision deserves only whatever the smallest quantity of plaudits is that's still distinguishable from zero. I hope that the site removes the captcha, offers bulk downloads, and fills up with useful, unsanitized data. But whoever built this travesty deserves to have an entry in FAPIIS of their own.

1: You do need to update the JSESSIONID cookie and get a fresh value for the org.apache.struts.taglib.html.TOKEN hidden variable, but this is easy enough to do.

Continue reading

CFC (Combined Federal Campaign) Today 59063

Charity Navigator