Sunlight Labs blog

FDLP Allergic to Curl

Eric Mill — Thu, 17 Jan 2013 13:37:19 -0500

Waldo Jaquith discovered that the FDLP (Federal Depository Library Program) appears to have an allergic reaction to people downloading their data with basic command line tools.

fdlp․gov blocks requests from cURL with a 403 and a "malware detected" error. >:-/
— Waldo Jaquith (@waldojaquith) January 2, 2013

The CSV's URL (linked from this post) is not blocked by their robots.txt. Using an alternate tool, wget, worked fine. My colleague Thom Neale humorously noted that having curl tell FDLP.gov that it's "microsoft-malware-professional-2013" also worked, but Waldo found that "Mozilla/5.0" did not. So FDLP has some weird, specific logic around who is approved to download their data and who isn't.

In the course of verifying all this, after trying to download the CSV only a handful of times, FDLP blocked the entire Sunlight Foundation office from any access to FDLP.gov. This was 2 weeks ago, and this is still what Sunlight staff see when they visit FDLP.gov:

The ridiculousness of permanently blocking us after so few requests aside, considering requests to download structured data by non-browsers to be "malware" is seriously backwards thinking, especially for a government agency.

Restricting abusive behavior is obviously fine, but that abuse should be measured by behavior, not by user agent profiling. If you host structured data at a public, permanent link, expect people to want to obtain that data through a great variety of reasonable means.

The Data and Tech Behind Sitegeist

Jeremy — Mon, 07 Jan 2013 10:32:41 -0500

It's been three weeks since we launched Sitegeist and the response has greatly exceeded (my) expectations! There have been over 27,000 downloads of the iOS and Android apps and a flood of feedback emails. Thanks again to the Knight Foundation and IDEO for their help in creating the app!

There were a bunch of questions about the data and technology used to produce Sitegeist, so let's dive into how the project works.

Data

Our goal with Sitegeist was to show how government data could be made useful to the average person. We incorporated demographic information, campaign contributions, weather and other data that comes directly from the government or through a secondary source. We also use some privately owned data sets to supplement this information.

US Census Bureau

Tha majority of the data used in Sitegeist comes from the US Census Bureau and their wonderful API. To help with development, we've created census, a Python wrapper for the Census API. For example, a call to get the name and number of children under 5 years of age for every state:

c = Census("MY_API_KEY")
c.acs.state(("NAME", "B01001_004E"), Census.ALL)

I've never worked with the Census bulk downloads, but I hear from colleagues that it can be a daunting task. Their API makes it incredibly easy to slice and dice the numbers as needed, combining data across "tables" for any geography you are working with.

Influence Explorer

Campaign contributions by ZIP code is provided by our own Influence Explorer project. Contributions within a ZIP code are totaled based on party affiliation of the recipient. Pretty straightforward, not much to say about this.

EPA Easter Egg

Have you ever looked at the Environment pane and seen the oozey alert? No? Good for you, you haven't been around any contaminated sites! We wanted Sitgeist to include a number of "easter eggs" that show up or change only in certain contexts. It's an easy way to make apps like this fun and more interesting. Due to time contraints, we were only able to get a few things like this added, but there are some ideas for more that we might work on.

We loaded a bunch of locations that the EPA considers to be contaminated; Superfund sites and more. If a site exists within five miles of your current location, we show the scary ooze creeping down the Environment pane. Clicking on this ooze will show you a page from the EPA site with more information on the contaminated location.

Third-party Services

All of the previously mentioned data sets have been loaded, cached and are sitting in a database on our server. The other third-party services, whether due to terms of service restrictions or praticality, are loaded on demand via their respective APIs. These services include Yelp and Foursquare for local business information and Dark Sky and Weather Underground for weather data.

A Note On Locations

The data sets that power Sitegeist use a number of different geographries: census tracts, ZIP codes, top-n closest from a location and things within a certain radius of a location. As far as the app is concerned, you exist at a point in a 2d plane. It would be inaccurate to say you are in San Francisco if the data you are seeing is tied only to a few small blocks within the city. Likewise, the names of some geographies make no sense at all; do you really care that you are in Census Tract 107?

The goal of the design was to present a clean and readable infographic-style display of the information. Geographic metadata was left out because it only contributed to clutter that most people don't care about. I emphasize, most people; the people that do care have definitely let us know!

It's definitely an interesting problem. If you have any insights, let me know in the comments.

The Web Servers

All of this wonderful data resides on our servers. When you select a location, the latitude and longitude are passed along with the ID of the pane you want to view. Of the various geographies we keep track of (census tracts, ZIP codes, etc.), the boundaries of any shape that contains your location is found. This uses a customized version of Chicago Tribune's boundaryservice. We then match those geographic boundaries with any data we have, making calls to third-party APIs as needed. The collected data is rendered into templates and returned to you as the beautiful infographics you see in the app.

In order to reduce load on our servers, the rendered panes are cached for a short period of time. So if you make a request again for the same pane in the same location, we'll just return the pane instead of making the API and database calls again. The cache timeout is very short, 10 minutes, so you'll always get relatively fresh data.

Mobile GPS devices are not incredibly accurate and your location can move around many meters even if you are standing still. I really don't want to waste the time doing database calls just because your phone corrected itself and moved you 5 meters to the left. The cache takes your location into account as well and will return cached data if you are within a certain "snap radius" of a previously rendered and cached request.

Android and iOS

Finally we have the mobile apps themselves. Though the infographic panes are HTML, the apps are native to their respective platforms. At the start of the project I looked at the possibility of using a pure HTML or cross-platform framework, but none of them allowed for the responsiveness and system integration we wanted. Going native allows us to take advantage of platform features like social sharing, maps, GPS and others while still using a single platform for generating the pane content. The other advantage of using web views for content is that we can make certain updates to the application, such as adding a new data view, without having to update both apps or waiting for Apple's App Store approval process.

Admin Dashboard

I also created an admin panel that allows us to load up panes for any combination of devices, locations and such. This has been incredibly useful when testing new features or troubleshooting data associated with specific locations.

The source for the Android app is available now and the web and iOS projects will be published within the next week.

If you haven't yet, check out Sitegeist!

Sunlight from the Command Line

Jeremy — Wed, 19 Dec 2012 11:09:52 -0500

Are you as big of a fan of Paul Tagliamonte as I am? If so, then you are well aware of python-sunlight, his awesome, comprehensive Python API client for Sunlight's APIs. The latest release includes a command line interface, or CLI, so you can interact with the Sunlight APIs directly from the shell. Cool, right?

To get started, install python-sunlight:

$ pip install sunlight

Next, you'll need a Sunlight API key. Visit http://services.sunlightlabs.com/ and register for a key. Once you have your key, save it to a convenient location in your home directory.

$ echo "THIS_IS_MY_KEY" > ~/.sunlight.key

python-sunlight will automatically look in this file for your key. No need to set it in your program or pass it as a parameter to the command!

Okay, let's do this…

$ sunlight
Usage: sunlight <service> <method> [<args>, ...]
Available services:
    influenceexplorer
    openstates
    capitolwords
    congress

So just by running sunlight we can see the endpoints that are available to us. Let's use the congress endpoint to find out information about representatives.

$ sunlight congress
Usage: sunlight <service> <method> [<args>, ...]
Available methods:
    committee_detail
    committees
    committees_for_legislator
    districts_for_lat_lon
    districts_for_zip
    legislator_search
    legislators
    legislators_for_lat_lon
    legislators_for_zip

And there are all of the methods of the sunlight.congress module, exposed to us via the command line. Arguments to the API are passed via parameters.

$ sunlight congress legislators --state MD
[
  {
    "district": "6", 
    "title": "Rep", 
    "eventful_id": "", 
    "in_office": true, 
    "state": "MD", 
    "crp_id": "N00002017", 
    "official_rss": "", 
    …

The response from sunlight is the full JSON returned by the API call. It could potentially be a lot of data! Let's write that JSON to a file so that we can do some more interesting stuff without making repeated calls to the API.

$ sunlight congress legislators --state MD > marylanders.json

Now that we've got that saved, let's use the awesome JSON filtering utility, jq, to get at just the data we want. Install jq via the binaries provided on the web site or by brew install jq on Macs. The simplest thing to do with jq is to just return the JSON as-is.

$ cat marylanders.json | jq '.'
[
  {
    "district": "6", 
    "title": "Rep", 
    "eventful_id": "", 
    "in_office": true, 
    "state": "MD", 
    "crp_id": "N00002017", 
    "official_rss": "", 
    …

But what I really want to know are the names and Twitter screen names for each Marylander.

$ cat marylanders.json | jq '.[] | {firstname,lastname,twitter_id}'
{
  "twitter_id": "",
  "lastname": "Bartlett",
  "firstname": "Roscoe"
},
{
  "twitter_id": "SenatorCardin",
  "lastname": "Cardin",
  "firstname": "Benjamin"
},
{
  "twitter_id": "",
  "lastname": "Cummings",
  "firstname": "Elijah"
}
…

Well that was easy! And just to be clear, you can use jq directly with the sunlight command, no need to write the JSON response to disk first!

$ sunlight congress legislators --state MD | jq '.[] | {firstname,lastname,twitter_id}'

Anyway, that's just a quick intro. You should check out the jq documentation and definitely register for a Sunlight API key!

Influence Explorer API, Now with Entity Type Filtering

Alison Rowland — Fri, 07 Dec 2012 13:38:08 -0500

Last year, we wrote about how to get access to our political influence data via the Influence Explorer API. That post is a great introduction, but here's an update on a small, but significant, improvement we've made to make accessing our data easier.

Calling our entity name search endpoint is the first step to accessing any of our aggregate data or wealth of metadata about political or politically influential entities, provided you don't already have the advantage of an ID from CRP, NIMSP, or the Congressional Bioguide (there's another endpoint to do ID-based lookups). For politicians, for instance, we've got not only campaign finance data and aggregate totals, but bios, photos, seats, districts, years run, and more. Say you want to find a head shot of John Boehner and how much money he raised in 2012. Play along with our examples, and go get a Sunlight API key. In the past, you would have just searched by name:

http://transparencydata.com/api/1.0/entities.json?&apikey=<your-key>&search=John+Boehner

From that, you'd get the following:

[
    {
        name: "Friends of John Boehner",
        count_given: 8,
        firm_income: 0,
        count_lobbied: 0,
        seat: null,
        total_received: 0,
        state: null,
        lobbying_firm: false,
        count_received: 0,
        party: null,
        total_given: 5701,
        type: "organization",
        id: "53ecb66245a64f0b989259b63f50bd9f",
        non_firm_spending: 0,
        is_superpac: false
    },
    {
        name: "John Boehner (R)",
        count_given: 0,
        firm_income: 0,
        count_lobbied: 0,
        seat: "federal:house",
        total_received: 31928263,
        state: "OH",
        lobbying_firm: null,
        count_received: 28267,
        party: "R",
        total_given: 0,
        type: "politician",
        id: "f990d08287c34c389cfabe3cbf3dde99",
        non_firm_spending: 0,
        is_superpac: null
    }
]

You'll notice that two entities were returned. Previously, you would have had to do an extra filtering step in your application code to get only the politician entity, which, nine times out of ten, is the one you'd want. And you'd either realize this up front, or spend some amount of time being frustrated as to why you were getting multiple results or assuming the first result returned was the one you wanted, when it wasn't really. No more! Now, you can search directly for the type of entity (politician/organization/individual/industry) you want.

http://transparencydata.com/api/1.0/entities.json?&apikey=<your-key>&search=John+Boehner&type=politician

And the result:

[
    {
        name: "John Boehner (R)",
        count_given: 0,
        firm_income: 0,
        count_lobbied: 0,
        seat: "federal:house",
        total_received: 31928263,
        state: "OH",
        lobbying_firm: null,
        count_received: 28267,
        party: "R",
        total_given: 0,
        type: "politician",
        id: "f990d08287c34c389cfabe3cbf3dde99",
        non_firm_spending: 0,
        is_superpac: null
    }
]

Isn't that better? You'll still have to do your due diligence to make sure you're getting what you really expect, but now you can just grab that ID and go get the full set of metadata for Boehner for that campaign finance total and headshot:

http://transparencydata.com/api/1.0/entities/f990d08287c34c389cfabe3cbf3dde99.json?apikey=<your-key>

With the results (JSON abbreviated):

    {
        name: "John Boehner (R)",
        totals: {
            2012: {
                recipient_amount: 12852363,
            },  
        },
        type: "politician",
        id: "f990d08287c34c389cfabe3cbf3dde99",
        metadata: {
            photo_url: "http://assets.sunlightfoundation.com/moc/100x125/B000589.jpg",
        }
    }

We hope you'll let us know if there are other ways we can make our data easier to use. Now, if you haven't already done so, go forth and get an API key and start building cool stuff with our Influence Explorer API!

Election Night Snapshots

Tom Lee — Wed, 07 Nov 2012 14:36:27 -0500

Late last week, we had an idea: election night was sure to be a confusing rush, and the closeness of the race in many states made result-reporting snafus seem possible. And the basic shape of election night data is deeply lousy (outside of media outlets that subscribe to the AP). Why not try to keep a record of what election authorities disclosed, so we could have a closer look in the morning?

Drew and Kaitlin adapted some of Politwoops' code, and we quickly researched as many URLs for election results as we could. The results are necessarily incomplete: some states don't aggregate their results in a central place, and some only went online during election night. But we managed a pretty good start.

We also decided to throw in a few media outlets, just for fun (and then a few more once the results began to come in and it became clear which sites might have to back off their predictions in a maximally screenshottable way). The results includes screenshots and HTML snapshots. Everything's timestamped -- the frequency of snapshots was determined both by when things changed (we only recorded new snapshots when something had been updated) and by the round-robining of the system (which was somewhat variable, based on the speed of the screenshot process).

We haven't had time to go through all of this data, but we'd love your help (or just the chance to satisfy your curiosity). So if you'd like, head over to electionshots.sunlightlabs.com. The content is organized by state -- ZZ is the media. We're working to put together bulk download options now.

New Districts in Sunlight Congress API

James Turk — Fri, 02 Nov 2012 11:54:35 -0400

Good news if you were one of the users waiting on our Congress API to support the newly drawn congressional districts! As of today it is possible to pass the districts=2012 flag to the Congress API's districts.getDistrictFromLatLong method to instruct the API to return the district in effect for the 2012 elections.

As you may recall, the data wasn't previously available in a uniform format but thanks to a recent data release from Census.gov we were able to get this data loaded, with days to spare until the election.

The default will remain to return the districts in effect for purposes of representation until the swearing in of the 113th Congress in January 2013 at which point the temporary districts=2012 flag will be retired (but it will be safe to continue to pass the parameter indefinitely).

This change does not yet impact other Sunlight API methods. The Open States district methods and the ZIP code related methods will be updated as that data is available, as described in our last update.)

Keeping Authentication Simple

Eric Mill — Wed, 31 Oct 2012 13:24:05 -0400

The point of publishing bulk data is so it can be reused as widely as possible. This is particularly true for government data, which belongs to the public.

Government agencies can sometimes also be concerned with ensuring the authenticity of their legal information - especially when the data might be seen as an official source. It breaks down into two major concerns: integrity (ensuring the text is accurate), and origin (proving it's official). A lot of people are used to the "wax seal" model of authenticity - the experience of opening a PDF and seeing that the document is signed and official. This model quickly breaks down for distributing bulk data.

The goals of ease of use and authentication are frequently presented as being in tension, but that tension is overstated. There are straightforward approaches to guaranteeing authenticity of bulk data that don't get in the way of reuse.

In fact, the Government Printing Office currently employs one of these approaches—cryptographic hashes—for every document it publishes on behalf of the United States. In their FDSys system, every document (take H.R. 6289 as an example) has an accompanying "PREMIS" file.

This PREMIS file contains a SHA-256 hash for every version of H.R. 6289 that GPO publishes - plain text, XML, and PDF. After you've downloaded any of those files, you can re-calculate the hash, using standard open source tools, to verify that the file is identical to what GPO published. PREMIS is an open standard, hosted at the Library of Congress.

GPO described their approach in June of 2011, saying that data integrity should not get in the way of reuse:

"The publication of the cryptographic hash values in the PREMIS metadata file, and the way FDsys structures its public URLs, makes it possible for machines to crawl and use this information to determine content integrity in bulk...

GPO recognizes the importance of ensuring that any content integrity verification method for XML content, such as digital signatures, should be structured so as not to interfere with data re-use or re-purposing. GPO is also committed to the principle of employing open, internationally recognized standards whenever possible."

In December, California's Office of Legislative Counsel wrote a report on authentication documenting several approaches, from a signature-based approach to a range of proprietary solutions. Signatures are, not surprisingly, a vastly cheaper solution.

As for guaranteeing that your signatures themselves are legitimate, the OLC presents another simple, cheap solution - using SSL:

"The primary limitation of hashes is that, by themselves, they do not authenticate the origin of the document...However, hashes can be used in combination with a secure Web site to authenticate documents. For instance, the hash for a document can be posted on a secure Web site, and consumers of the document can verify that the hash from the Web site matches the hash computed directly from the document."

This is quite true, although verifying origin like this is only necessary if you're concerned about someone pretending to be the owner of the document. It's difficult to see this as a concern for all but the most security-sensitive government materials. GPO doesn't use SSL for hosting anything on FDSys, apparently also not seeing it as an issue at present. (However, PREMIS supports verifying origin [docs], by including a version of the hash signed with a public key.)

The OLC also acknowledges another possibility: that an agency could legitimately decide that the whole issue is moot.

"The validation problem could be simplified if XML validation by the general public is determined to be unnecessary. Large document consumers that desire authenticated XML documents could be required to implement their own validation solutions."

What's clear in all of this is that authenticity can be simple, inexpensive, and optional -- for both sides. Government bodies publishing bulk data that feel it's important to guarantee authenticity can provide signatures. Consumers who don't care about authenticity don't have to, and those that do can easily verify those signatures. Everyone can win.

Edit: Replaced "signature" with "hash" where appropriate, and clarified that PREMIS does support origin verification.

Art Hack Day Boston

Paul Tagliamonte — Wed, 17 Oct 2012 13:10:20 -0400

A couple of weekends ago, I attended Art Hack Day at Harvard. The event was put on by the Big Bad Lab, where we were proud to provide the data for the event through our APIs It was a pleasure getting to show off python-transparencydata and (ok, I'm biased here) python-sunlight.

The creative juices were really flowing throughout the 3-day hackathon, folks created some amazing projects, such as a vending machine bill acceptor that sucked 100 dollar bills at the same rate money has been spent this election cycle (it was really fast!), political speech karaoke, and a voting booth that just can't accept "no". Some other creative projects included an app that would process tweets from federal Senators and Representatives (twitter IDs found off the Sunlight Congress API), and a bulletin board was covered with flyers featuring (real!) numbers for lobbyists discovered through Influence Explorer.

All in all, it was a great event, and really showed what can get done with so many great hackers, artists and researchers stuffed together for a weekend!

A Cite for Sore Eyes

Thom Neale — Fri, 12 Oct 2012 12:28:29 -0400

Earlier this week the annual Law Via the Internet conference was hosted by the Legal Information Institute at Cornell University. The conference schedule featured talks on a range of policy and technical subjects, including the topic of extracting legal citations from text and understanding them programmatically, which arises whenever people need to determine the relevance of legal documents based on the authorities they cite. Recognizing citations in text is also a vexing but fun programming challenge, so I was excited to see this issue figure prominently in at least four separate talks.

So why is parsing citations from text a difficult problem? I'll attempt to briefly explain. Beyond serving as attribution for a quotation or claim, a citation's only purpose is to identify the cited authority without too much ambiguity. For that reason, early citation manuals tended to be simple and straightforward. The citation formats they prescribed were calibrated only for authorship and consumption by humans—never machines. The first edition of the Blue Book in 1926 was a mere 26 pages in length. But by 2010, the eighteenth edition of the Blue Book had swollen to over 500 pages, hundreds of which struggled to respond to the vagaries of citing electronic resources like websites and CD-ROM sets. In addition to the constant evolution in citation rules, the idiosyncratic field of deciding how sources should be cited tends to be populated with (there's no nice way to put this) weird people who experience an aesthetic mania in arguing about—and ultimately revising—existing rules. So citation rules also tend to be in constant flux and vary widely depending on which manual you consult. A third factor is that complicated, fluid rules are difficult to comply with, so writers frequently bend or break the rules to save time. With these challenges in mind, here are some techniques that presenters at the conference are using to deal with these issues:

Michael Lissner, the co-founder and lead developer of CourtListener.com explained the approach that he and collaborator Rowyn McDonald are using to parse case citations from federal court opinions. They start by identifying a subset of acronyms for federal bound volumes, like "U.S.", "F. 2d", "F. 3d" and then search to the left and right to identify the volume number and page number, respectively (source code here). This is slightly different from the approach taken by Sunlight Labs' own Eric Mill in citation.js, which defines a set of regular expressions and callback functions to process the matches each finds.

Another presentation by Marc-André Morissette, the director of technology at Lexum, focused on specialized techniques his firm is using to parse statute and session law citations from court decisions in Canada. This presentation touched on the challenges of programmatically identifying human-written citations that deviate from the styles prescribed in citation manuals. To correctly recognize bogus references, Morissette's team precomputes all valid citations to the resources they want to extract from the cases, then computes a variety of misspellings and mistakes that commonly appear in the targeted citation types. They then generate a state machine—a decision tree, basically—and scan over the input text one token at a time, testing each against the current node in the decision tree. When a terminal node is reached, a match is found. This technique has the interesting (but also potentially limiting) characteristic of substantively verifying the citation during the extraction operation: if a citation doesn't get matched against the decision tree, it must not refer to a known resource.

I was also very pleased to see that Anurag Achary, the lead engineer of Google Scholar, was not only in attendance at LVI 2012, but presenting. In his presentation, he detailed a number of challenges his team faced in publishing and cross-referencing court opinions (and scholarly journals) on Google Scholar—issues such as how to react to changes in citation formats across jurisdictions and different time periods, how to distinguish short citations ("in the New York decision we held...") from normal prose ("she lived in New York"), and how to resolve ambiguous citations, like "ibid" to the actual source they refer to. Anurag understandably stopped short of disclosing his recipe for the secret sauce that makes Google Scholar so, so delicious, but hinted that his go-to tools included a huge corpus of test data, unit tests, Bayes' theorem, and plenty of common sense. He spoke in very simple and down-to-earth terms about his work, but I still came away from his talk dumbfounded by what he has accomplished with a team of less than three full-time developers.

A fourth and really impressive presentation was given by Frank Bennet, an associate professor at the Nagoya University law school in Japan. Whereas the other presentations focused on identifying citations in text and using them to link related documents, Frank focused on the opposite but closely related task of transforming bibliographic data into properly formatted legal citations than can be inserted into documents. Confronted with the problem of law students so confounded by the complexity of the Blue Book that they simply resorted to plagiarizing citations, Frank set out to adapt the Zotero research platform for use with legal resources. Zotero is a browser extension that enables users to select resources from sites like Amazon and Google Scholar and store their bibliographic information in a local database. Frank's work goes one step further and provides style definitions that citeproc-js can use to format the citations for publication. The session included an eye-popping demonstration of a related word-processing utility that enables users to insert formatted citations from sources in their local Zotero database.

So what does any of this have to do with Sunlight Labs? Parsing citations effectively is an inevitable task for applications that need to identify related sources in text. For us, that issue is arising in a few places. Eric's latest project, Scout, aims to provide users with alerts for proposed regulations, and one of the more effective ways to determine whether a proposed regulation affects your interests is to search its text for references to statutes you care about. In an attempt to build out this feature, Eric has started working on parsing US Code citations from the text of bills and proposed regulations. Similarly, the Open States project is also looking for ways to identify what statutes would be impacted by legislative bills so we can link users to appropriate sites (if they exist) and also enable querying of bills by the law sections they would affect. In our case, these tend to be prosaic references rather than formal citations, which lends an additional and terrifying dimension to the problem. But from a software developer's perspective, parsing citations involves the same family of techniques regardless of the underlying resources you're looking for.

All in all, LVI was a great conference and I hope to see these projects enjoy continued success.

Politwoops - Now With More Open Source Flavor

Kaitlin Devine — Tue, 09 Oct 2012 11:34:20 -0400

Thursday we released a revamped design of Politwoops! You can read about some of the changes to the features and content in Nicko's post on the main blog, but the main news of the day is that we've now open sourced the code. That means, you can create your own Politwoops instance to track the deleted tweets of any subset of people you fancy.

Of course the original concept and codebase is from the Open State Foundation. The code is split into two github repositories: one for the workers that track and import deleted tweets and their related screenshots and the other that includes the Rails project for the web frontend. The two parts simply share a MySQL database. The original OSF codebase for the web frontend included several non-Politwoops related features that were superfluous for our requirements, so we've stripped them out of our fork to make a slimmed down, twoops-only, version. However, our fork of the repository for the backend diverges relatively little from the OSF one.

Special shout out to Caitlin Weber for the fun, new design!