[Sunlight’s Congress API](http://sunlightlabs.github.io/congress/) receives millions of requests every month for data about all things Congress. Many of these requests include information about a user’s location, generally to look up which members of Congress [represent a given zip code or latitude/longitude pair](http://sunlightlabs.github.io/congress/legislators.html#legislatorslocate).
Since June 2013, Sunlight’s Congress API has supported the use of encryption via HTTPS (`https://`). More recently, we [began recommending HTTPS as the default protocol](http://sunlightlabs.github.io/congress/#using-the-api) to use with our Congress API, though plain HTTP will continue to be supported.
If you’re using our Congress API — **especially** if you use our endpoints that look up congressional representation based upon zip code or latitude/longitude — we **strongly recommend** you use HTTPS. Doing so protects details about API requests from being seen and analyzed by anyone with access to the networks your API requests are traveling across.
Note: HTTPS can’t protect IP addresses from being exposed when you make a request to our (or anyone’s) web services. IP addresses can be used to perform some geolocation, though it’s not as precise or accurate as latitude and longitude.
We’ve updated our major applications that make use of our Congress API to ensure that requests to our API, including location requests, stay encrypted over the wire. [OpenCongress.org](http://www.opencongress.org), [Scout](https://scout.sunlightfoundation.com), and our [Congress app for Android](http://congress.sunlightfoundation.com/android) now encrypt their queries to our APIs, and our [Congress app for iOS](http://congress.sunlightfoundation.com/ios) will begin to do so as of our next app update.
Finally, we’ve made sure that prominent client libraries for our Congress API in [Ruby](http://rubygems.org/gems/congress), [Python](https://pypi.python.org/pypi/sunlight) and [Node](https://npmjs.org/package/sunlight-congress-api) each default to HTTPS for all API communication.
### Why we’re doing this
It may not seem at first glance like information about government data is all that sensitive, but it’s difficult to predict how requests to and from your application can be used in large-scale traffic analysis, and how they can be correlated to user activity on other services.
And really, it’s quite reasonable to think of individuals’ requests for government information — whether it’s for an oversight report or for information about an opposition politician — as sensitive and deserving of protection from analysis.
It’s also extremely easy to do.
### How we’re doing HTTPS
The Congress API is an [open source](https://github.com/sunlightlabs/congress) Ruby application, written in Sinatra, sitting behind nginx and running on Amazon EC2. SSL is terminated on the EC2 instance, by nginx.
We use a [brief, straightforward nginx configuration](https://github.com/sunlightlabs/congress/blob/master/config/nginx/congress-api.conf#L10-L30), with some specific cipher choices, to enable [Forward Secrecy](https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection) and protect against some basic [attacks](https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat). We also use SSL Labs’ excellent SSL benchmarker to [measure our progress](https://www.ssllabs.com/ssltest/analyze.html?d=congress.api.sunlightfoundation.com).
Here’s the relevant excerpt:
### In general
HTTPS is a good thing, whether or not you’re handling or providing sensitive information. There are good reasons [so many major technology providers are turning on HTTPS everywhere](https://www.eff.org/deeplinks/2013/11/encrypt-web-report-whos-doing-what), and that Chrome and Firefox [will require HTTP 2.0 to be encrypted](http://www.mnot.net/blog/2014/01/04/strengthening_http_a_personal_view).
We’ll evaluate the use of HTTPS for our future APIs, and please feel free to [let us know](mailto:firstname.lastname@example.org) if this is important to you. In the case of our Congress API, we’re processing highly precise, sensitive location data on behalf of users all over the United States — many of whom may not even know Sunlight is involved when our API is used as an intermediary lookup service in someone else’s app or campaign — and so we’re going the extra mile to ensure our users’ privacy.
Feb 2, 2014 – Updated text and link to clarify that browsers will be requiring encrypted HTTP 2.0, not the standard.