Different branch, though. This policy only covers certain executive branch agencies.
1,284 karma · joined October 26, 2012
I currently work for as a technology advisor to the General Services Administration. I help 18F and other technology programs at GSA build open, secure technology inside the US federal government. Before that, I spent 5 years with the Sunlight Foundation working on open data infrastructure and policy.
[ my public key: https://keybase.io/konklone; my proof: https://keybase.io/konklone/sigs/9Iwmw27600DiYlztkLB1x2b2vIGIiPJ6DpXE76ekFkY ]
> Even then, I'm pretty sure they don't offer hosting/authorizing deployments from party sources. So they essentially have a monopoly on the ability to use OSS freely for bulding government websites.
That's not quite the case. Many agencies use a ton of OSS to build websites and other services.
https://github.com/cfpb/source-code-policy https://github.com/uscensusbureau/open-source-policy https://github.com/18F/open-source-policy
The policy links above refer to those teams releasing their own code as open source, but you will find huge amounts of outside open source code being used there, and in many other agencies.
The Department of Defense is famous for (in 2003!) making sure their department knew that open source software was A-okay to use, and people refer to their amazing FAQ all the time:
http://dodcio.defense.gov/OpenSourceSoftwareFAQ.aspx
(I'm an 18F employee.)
If the attacker MITMs an HTTPS request, then they have to provide a forged certificate (whether HSTS is set or not).
If the attacker MITMs an HTTP request which would have normally been redirected (e.g. typing "facebook.com" into the URL bar), then HSTS is required. Without it, no forged certificate required.
HTTPS and HSTS should have just been the baseline the web shipped with, but the web shipped before people thought about these things, and arguably before encryption was stable/secure/fast enough to be practical for the whole web.
I'm very happy that the federal HTTPS-policy includes an HSTS requirement for federal agencies: https://https.cio.gov/
Of course, if the certificate changes to an untrusted one, the browser should flag it -- and if the server specifies HSTS, then the browser should block the user from clicking through anyway (increasing the pressure to make sure the cert is always trusted and unexpired).
https://www.whitehouse.gov/blog/2015/06/08/https-everywhere-...
As an 18F employee, I can't speak for USDS, but I know 18F can (and does, I think) employ non-US citizens who are already authorized to work (we can't sponsor). I've also never taken a drug test.
Just a small note, immigration is DHS.
Thanks! We loved the opportunity to assist the Digital Analytics Program (DAP) with the dashboard. They've been around since ~2012 and have been doing the legwork to get agencies to participate in the program for years:
Well, I like it. =)
They were previously customers of that market. They found it suited their needs better to replace the thing they were purchasing from.
> You can call this elitist or patriarchal. But my suggestion is that the EFF and Sunlight do exactly what you are doing at 18F (which I suggested to you 2 years before you took the job, scoffed at, and as I recall were quite argumentative about it. So...): go on the inside and work on problems from there...
I didn't scoff at working on the inside. I scoffed at the notion that working on the inside is required in order to have a valid opinion about what government should do. And that's something I continue to scoff at.
> because if you're connecting firehoses to drinking straws, you're doing more harm than good.
It's not zero sum. I'm glad for the companies that tackle the inside game here too. It's not the only game worth playing, and if democracy.io increases the pressure further for more people to work on the inside sector, then everyone wins.
> Finally if you want to make it so Congress is well represented by its constituents, make it as easy and delightful to hear from your constituents as it is from a lobbyist. Until then, the lobbyists will always win.
That's a pretty fluffy notion. Lobbyists can show up in person, and can get special access to events and meetings that ordinary constituents can't.
Sometimes that's earned by virtue of subject matter expertise, and a lot of the time it's just people who know each other. You can't make it more delightful to hear from a constituent than it is to get a call from a friend.
You can certainly argue democracy.io doesn't help with that particular problem, and that's fine. Arguing that it actually hurts democracy to help people send emails to Congress without having to go through a for-profit vendor is what gets into the territory of elitism.
Nothing below the radar about it:
https://www.whitehouse.gov/blog/2015/06/08/https-everywhere-...
That's definitely an accurate description of the US federal government.
EFF and Sunlight collaborated to create the data ecosystem necessary for this project in order to change that dynamic and make it possible to mechanize the sending of letters to Congress for free. That EFF and Sunlight could justify spending a pretty amazing upfront investment of staff labor and resources to create that ecosystem demonstrates that the existing vendor-driven market was limiting who could participate.
> I'd encourage you to hop on a plane, and go visit some congressional staffers and ask them how they'd like to receive your messages. Then build a tool starting from there. Like it or not, they're the customer.
They're not the customer, and to treat them that way is a great way to ensure that Congress is never made uncomfortable. It doesn't matter how many staff complain to the CMF about it.
Congressional staffers definitely are the customer to Intranet Quorum and any attempts to compete with it. Those are the pieces of software that need to bend over backwards to take their needs into consideration.
For sending messages to Congress, the burden is appropriately on Congress to find a way to handle receiving them.
Responding to frustrated Congressional staff by reducing the information below between Congress and constituents would be patrician and elitist. Responding to frustrated Congressional staff by limiting the intermediaries to a narrow range of mostly partisan for-profit vendors would represent an interesting and dangerous form of capture.
shrug You're not wrong, but it's more important to have wires that can be trusted than to have wires that can be perfectly audited.
This is hyperbole, unnecessarily accusatory, and counterproductive. Nothing above made it look like Ryan/Slack had ulterior motives. You disagree with how they interpreted things.
https://github.com/GSA/analytics.usa.gov#deploying-the-app
We might increase that over time, but having fixes take effect within 5 minutes while the site is under the spotlight is a nice thing.
https://support.google.com/analytics/answer/2763052?hl=en
You have to trust Google to follow through, but my understanding is this was originally implemented to satisfy German privacy laws, so there's reason to think they take it seriously.
How that impacts logging at their outermost network edge, and whether logs at that level could be feasibly correlated with anything at the application layer, I have no idea. It'd be nice if they clarified that.
https://developers.google.com/analytics/devguides/reporting/...
It's pretty handy, since queries are so commonly exactly that: "the last 30 days" or whatever, and it saves the client from having to perform date calculation code to figure out just what that is.
[1] https://18f.gsa.gov/2015/02/09/the-first-gov-domains-hardcod...
IMO, it's more important to emphasize the idea of secure origins, and HTTPS hits that note. TLS could be swapped out, the CA system could be changed, but what matters is the expectation that connections across the web are expected to be secure by default.