10 ms·

> “I don’t have confidence that DoD could build a unique texting system with proper security protocols that would beat any commercial, off the shelf, version,”

> “I don’t have confidence that DoD could build a unique texting system with proper security protocols that would beat any commercial, off the shelf, version,” the former official said. so $700B in defense spending can't match some motivated, talented FLOSS devs? that's rich.

zamadatix 7y ago
Quote is about beating not matching. If the FLOSS software matches all of their requirements then there isn't a way to beat it and it's already made.
- dpeck 7y ago
  Not once has that ever stopped an RFP from being put out or a contract from being awarded.
  - retbull 7y ago
    Hopefully this is the first time. Honestly the government needs to make more open decisions like this (hard because of tracking budgets and how contracts are awarded and defined as complete). A bit more flexibility and open decisions with easy input from their users would do our country a HUGE service and save a metric fuck ton of money.
  - mattlutze 7y ago
    Lots of RFPs are awarded to companies with existing commercial technology, or to solution providers who bid on a plan to integrate open-source software and maybe add a little flavor.
  - ineedasername 7y ago
    Even if there was a FLOSS option that checked every box on features, there would still need be an RFP for implementation. You can't create and manage the infrastructure of a system at that scale without spending enough money to require an RFP.
    - ineedasername 7y ago
      Always fun to get downvoted for voicing a statement of fact: an RFP is required, if I remember correctly, for any purchase in excess of $25,000. It's not a high bar, and would easily be surpassed by having to pay a contractor to implement and integrate even the simplest of tools if it's to be used across the entire DoD Enterprise.
dogman144 7y ago
fwiw RHEL is all over Army systems under the hood
- erikbye 7y ago
  This is true for DoD, NATO, etc...
xedeon 7y ago
That's the sad reality. Not just on the DoD side, but from the entire federal IT workforce/teams. With the exception of: 18F https://18f.gsa.gov/ https://18f.gsa.gov/ USDS https://www.usds.gov/ https://www.usds.gov/ The motto seems to be: "Open Source is BAD! How are we going the get support?! Let's just buy a product or solution from a vendor" Even though they have people/teams who were hired as developers. I have so many horror stories, it's not even funny.
- mikekhusid 7y ago
  Check out Kessel Run as well. https://kesselrun.af.mil/ https://kesselrun.af.mil/ DoD mindset re: digital acquisitions is changing.
  - dogman144 7y ago
    how each branch is implementing tech commands is fascinating. - DDS in general seems like a great program. - KR dudes are great and will probably unfuck the AF's tech if they have enough wiggle room and command support against Lockheed and co. Hiring at GS-12s, few weeks approval, quick clearances, other unheard of comp strategies to get good civ talent. - Army futures command is ..... near retired E9s and O6s in cargo shorts and underarmour polos, hiding out in the Austin Wework
    - 2StepsOutOfLine 7y ago
      Sadly it's hard to argue the effect that KR is having is "positive". KR stood up by working closely with Pivotal who supplied both the Pivots to pair program with the comparatively inexperienced AF devs as well as the deployment platform. While the means are debatable, the ends that Units supplying devs to KR had to face we're not. Those Units got back programmers completely reliant on Pivotal Cloud Foundary. You would get devs that had no concept of what happens to their code after they run `cf push` and the Units had to face the reality that their devs were ineffective without PCF which costed 10's of millions to purchase and maintain by a team of Pivotal engineers. Obviously Pivotal is a company that exists to make profit but smaller units that supplied devs to KR largely felt taken advantage of. And after that you had things like SpaceCamp, LevelUp, Platform1, that are very similar to KR just without the heavy reliance on Pivotal or their products popping up left and right. Now that it's gone on for so long even leadership in KR is getting pressured to actually produce a product ready app for all the money that's been dumped. They have plenty of MVP's but afaik nothing to big AF's satisfaction. At least from a lowly enlisted programmers perspective you can live in Boston in civilian clothes for 6 months.
reaperducer 7y ago
Maybe not DoD, but perhaps NSA. If the NSA can make it secure against themselves, that's not a bad start.
UncleMeat 7y ago
Crypto is a tiny community and doing it right is very hard. It is not surprising to me that access to talent is worth more than raw dollars.
hadtodoit 7y ago
The first iteration of healthcare.gov cost $1B iirc and it was a broken mess. The task was herculean but no doubt a lot of that money filled bureaucrat pockets. The public sector, and contractors just don't attract top talent like the private does, nor are they spearheaded by people who earned their position.
- wpietri 7y ago
  Bureaucrats in the US rarely end up with full pockets. As with a great deal of government IT work, it's private companies that are raking in the money. Healthcare.gov in particular was outsourced. I don't think the problem is "top talent". I think the problem is how people think about software, and therefore how they budget for and manage it. And I don't think the problem is unique to government. I've heard about plenty of private sector giant-project boondoggles where enormous sums were wasted in similar fashions. It's just that those don't make the newspapers, but instead get gossiped about by tech people over beers.
pjc50 7y ago
Yes, that sounds about right. There are not a lot of people who can do crypto well, and they tend to be too weird to make good government or megacorp employees. The NSA will have people capable of doing it, but they undoubtedly have more important things to do than write a chat app. They could hand a billion dollars to Microsoft or Amazon, who would happily take it, but would that produce a better result? Or any results at all?
- ryanmercer 7y ago
  >and they tend to be too weird to make good government or megacorp employees. Or simply do not want to work for the government or a megacorp.
anticensor 7y ago
Not due to budget, but due to incentive structure. Low ranked military would avoid potential liability at all costs and just stay put if no order is issued.
goatinaboat 7y ago
The French company Thales basically re-invented BlackBerry for the exclusive use of their government https://www.thalesgroup.com/en/worldwide/security/telephony-and-multimedia-security https://www.thalesgroup.com/en/worldwide/security/telephony-...
ta999999171 7y ago
You serious? Defense contractors waste tons of our money, more breaking news at 11.
hamiltont 7y ago
> so $700B in defense spending can't match some motivated, talented FLOSS devs? that's rich. Not in my experience. The problem is not technical talent, it's culture. That's not to say it's impossible to solve these issues, only that a culture of top-down "get it done" does not tend to mesh well with the rigid discipline needed to make a secure product. Ever had to say "no" to a general? On any system built in house, there will be management feature requests which force security compromises. For example, "We must archive the data of this comms network - we have a legal requirement to do that!!" or "We need to ability to access user's data for internal/external investigations", etc. Solving these issues in a secure manner is incredibly hard, and IME it can be incredibly difficult to explain to someone non-technical why "just do X" will harm the security posture. More often than not, a developer (with their salary paid by the boss) will be forced into "just doing X" by someone who does not truly understand how much that compromises the system. Boss will be happy, thinking they "pushed it through" and non-crypto developer will be happy thinking "it has some authentication applied so must be secure" while cryptographer will be largely ignored or misunderstood. (Note: not a cryptographer, but I am an expert in other domains and have worked with enough to see their pain first hand) Most non-cryptographers on the project start to get confused, typically thinking all of the compromises are OK because they only open doors for the DoD and that is who the product is for, without having the training or knowledge to realize how problematic this thinking can be. IMO - listen to your cryptographer, you hired them for a reason.
scarejunba 7y ago
Well, that doesn't sound impossible. After all, it's what the dollars are attached to. Think about it: if you want to implement an echo server that can't be cracked to view previous things it echoed, you could probably do it quite well. Now imagine I bring a billion dollars, and some more requirements, and I hire a few hundred people to work with you on this, and some of them are security consultants, and some are compliance guys who want the echoed text saved for compliance, and some others are privacy experts who want the echo text inspected by DLP software so that you aren't sending PII. I rate former you more likely to succeed than latter you. In the first problem, it's technical. In the second, it's organizational.

zamadatix 7y ago

Quote is about beating not matching. If the FLOSS software matches all of their requirements then there isn't a way to beat it and it's already made.

dpeck 7y ago
Not once has that ever stopped an RFP from being put out or a contract from being awarded.
- retbull 7y ago
  Hopefully this is the first time. Honestly the government needs to make more open decisions like this (hard because of tracking budgets and how contracts are awarded and defined as complete). A bit more flexibility and open decisions with easy input from their users would do our country a HUGE service and save a metric fuck ton of money.
- mattlutze 7y ago
  Lots of RFPs are awarded to companies with existing commercial technology, or to solution providers who bid on a plan to integrate open-source software and maybe add a little flavor.
- ineedasername 7y ago
  Even if there was a FLOSS option that checked every box on features, there would still need be an RFP for implementation. You can't create and manage the infrastructure of a system at that scale without spending enough money to require an RFP.
  - ineedasername 7y ago
    Always fun to get downvoted for voicing a statement of fact: an RFP is required, if I remember correctly, for any purchase in excess of $25,000. It's not a high bar, and would easily be surpassed by having to pay a contractor to implement and integrate even the simplest of tools if it's to be used across the entire DoD Enterprise.

dogman144 7y ago

fwiw RHEL is all over Army systems under the hood

erikbye 7y ago
This is true for DoD, NATO, etc...

xedeon 7y ago

That's the sad reality. Not just on the DoD side, but from the entire federal IT workforce/teams. With the exception of: 18F https://18f.gsa.gov/ https://18f.gsa.gov/ USDS https://www.usds.gov/ https://www.usds.gov/ The motto seems to be: "Open Source is BAD! How are we going the get support?! Let's just buy a product or solution from a vendor" Even though they have people/teams who were hired as developers. I have so many horror stories, it's not even funny.

mikekhusid 7y ago
Check out Kessel Run as well. https://kesselrun.af.mil/ https://kesselrun.af.mil/ DoD mindset re: digital acquisitions is changing.
- dogman144 7y ago
  how each branch is implementing tech commands is fascinating. - DDS in general seems like a great program. - KR dudes are great and will probably unfuck the AF's tech if they have enough wiggle room and command support against Lockheed and co. Hiring at GS-12s, few weeks approval, quick clearances, other unheard of comp strategies to get good civ talent. - Army futures command is ..... near retired E9s and O6s in cargo shorts and underarmour polos, hiding out in the Austin Wework
  - 2StepsOutOfLine 7y ago
    Sadly it's hard to argue the effect that KR is having is "positive". KR stood up by working closely with Pivotal who supplied both the Pivots to pair program with the comparatively inexperienced AF devs as well as the deployment platform. While the means are debatable, the ends that Units supplying devs to KR had to face we're not. Those Units got back programmers completely reliant on Pivotal Cloud Foundary. You would get devs that had no concept of what happens to their code after they run `cf push` and the Units had to face the reality that their devs were ineffective without PCF which costed 10's of millions to purchase and maintain by a team of Pivotal engineers. Obviously Pivotal is a company that exists to make profit but smaller units that supplied devs to KR largely felt taken advantage of. And after that you had things like SpaceCamp, LevelUp, Platform1, that are very similar to KR just without the heavy reliance on Pivotal or their products popping up left and right. Now that it's gone on for so long even leadership in KR is getting pressured to actually produce a product ready app for all the money that's been dumped. They have plenty of MVP's but afaik nothing to big AF's satisfaction. At least from a lowly enlisted programmers perspective you can live in Boston in civilian clothes for 6 months.

reaperducer 7y ago

Maybe not DoD, but perhaps NSA. If the NSA can make it secure against themselves, that's not a bad start.

UncleMeat 7y ago

Crypto is a tiny community and doing it right is very hard. It is not surprising to me that access to talent is worth more than raw dollars.

hadtodoit 7y ago

The first iteration of healthcare.gov cost $1B iirc and it was a broken mess. The task was herculean but no doubt a lot of that money filled bureaucrat pockets. The public sector, and contractors just don't attract top talent like the private does, nor are they spearheaded by people who earned their position.

wpietri 7y ago
Bureaucrats in the US rarely end up with full pockets. As with a great deal of government IT work, it's private companies that are raking in the money. Healthcare.gov in particular was outsourced. I don't think the problem is "top talent". I think the problem is how people think about software, and therefore how they budget for and manage it. And I don't think the problem is unique to government. I've heard about plenty of private sector giant-project boondoggles where enormous sums were wasted in similar fashions. It's just that those don't make the newspapers, but instead get gossiped about by tech people over beers.

pjc50 7y ago

Yes, that sounds about right. There are not a lot of people who can do crypto well, and they tend to be too weird to make good government or megacorp employees. The NSA will have people capable of doing it, but they undoubtedly have more important things to do than write a chat app. They could hand a billion dollars to Microsoft or Amazon, who would happily take it, but would that produce a better result? Or any results at all?

ryanmercer 7y ago
>and they tend to be too weird to make good government or megacorp employees. Or simply do not want to work for the government or a megacorp.

anticensor 7y ago

Not due to budget, but due to incentive structure. Low ranked military would avoid potential liability at all costs and just stay put if no order is issued.

goatinaboat 7y ago

The French company Thales basically re-invented BlackBerry for the exclusive use of their government https://www.thalesgroup.com/en/worldwide/security/telephony-and-multimedia-security https://www.thalesgroup.com/en/worldwide/security/telephony-...

ta999999171 7y ago

You serious? Defense contractors waste tons of our money, more breaking news at 11.

hamiltont 7y ago

> so $700B in defense spending can't match some motivated, talented FLOSS devs? that's rich. Not in my experience. The problem is not technical talent, it's culture. That's not to say it's impossible to solve these issues, only that a culture of top-down "get it done" does not tend to mesh well with the rigid discipline needed to make a secure product. Ever had to say "no" to a general? On any system built in house, there will be management feature requests which force security compromises. For example, "We must archive the data of this comms network - we have a legal requirement to do that!!" or "We need to ability to access user's data for internal/external investigations", etc. Solving these issues in a secure manner is incredibly hard, and IME it can be incredibly difficult to explain to someone non-technical why "just do X" will harm the security posture. More often than not, a developer (with their salary paid by the boss) will be forced into "just doing X" by someone who does not truly understand how much that compromises the system. Boss will be happy, thinking they "pushed it through" and non-crypto developer will be happy thinking "it has some authentication applied so must be secure" while cryptographer will be largely ignored or misunderstood. (Note: not a cryptographer, but I am an expert in other domains and have worked with enough to see their pain first hand) Most non-cryptographers on the project start to get confused, typically thinking all of the compromises are OK because they only open doors for the DoD and that is who the product is for, without having the training or knowledge to realize how problematic this thinking can be. IMO - listen to your cryptographer, you hired them for a reason.

scarejunba 7y ago

Well, that doesn't sound impossible. After all, it's what the dollars are attached to. Think about it: if you want to implement an echo server that can't be cracked to view previous things it echoed, you could probably do it quite well. Now imagine I bring a billion dollars, and some more requirements, and I hire a few hundred people to work with you on this, and some of them are security consultants, and some are compliance guys who want the echoed text saved for compliance, and some others are privacy experts who want the echo text inspected by DLP software so that you aren't sending PII. I rate former you more likely to succeed than latter you. In the first problem, it's technical. In the second, it's organizational.