DOGE has 'god mode' access to government data
theatlantic.com836 points by perihelions a day ago
836 points by perihelions a day ago
At my first gig, I had "god" level access to our production database.
All I learned is that nobody should have this level of access unless it is some sort of temporary break glass situation. It is extremely dangerous and even experienced engineers can cause irreparable data loss or some other bad outcome. In our case, some engineer accidentally sent around 10,000 invoices to customers that shouldn't have gotten them.
There are far better data access patterns. In the case of US gov data, I don't see why the DOGE team would need anything more than a read replica to query. It could even be obfuscated in some way to protect citizens' identities.
I've worked with older governmental systems, and chances are they are running a wide variety of systems, some of which, the oldest and most critical, are probably written in COBOL running on IBM mainframe hardware. In those environments, there is no real distinction between "database" and "application". COBOL systems are very file- and batch-oriented, and are "monolithic" in the extremist sense. The technology itself makes it impossible to give read only access to such systems.
> The technology itself makes it impossible to give read only access to such systems.
This isn't true. Mainframe COBOL systems commonly store data in VSAM files, or DB2, or IMS, or sometimes some more obscure non-IBM database (e.g. CA/Broadcom's Datacom/DB or IDMS, or Software AG's ADABAS). But whichever one they use, there are multiple ways of granting read-only access.
For example, if it is VSAM, you can configure RACF (or TopSecret or ACF2) to allow an account read (but not write) permission to those VSAM datasets. Or, you can stick DB2 in front of VSAM (on DB2 for z/OS, CREATE TABLE can refer to a pre-existing VSAM file, and make it look like a database table), and then you can have a readonly account in DB2 to give you access to that database schema. Or, there's a lot of other ways to "skin this cat", depending on exactly how the legacy app is designed, and exactly how it stores data. But, probably this is already implemented – most of these apps have read-only access for export into BI systems or whatever – and if it happens for whatever reason not to be, setting it up should only be a modest amount of work, not some multiyear megaproject.
>Or, there's a lot of other ways to "skin this cat", depending on exactly how the legacy app is designed, and exactly how it stores data. But, probably this is already implemented
Given that neither of us knows the actual systems in question, what is more likely, that it's a well-designed system or one that has organically accreted over time? It seems like you tend to believe the former, and I the latter. I suppose my view is based on the fact that, like in statmech, you enumerate all possible systems that can do a particular job, the vast majority of those solutions will not have any organizing principle and will not be amenable to surgical analysis or change.
I think the difference is that I know that getting data out of mainframe COBOL systems is a long-known and long-solved problem, and I can list lots of different ways to do it (I mentioned a few, there's several more I didn't mention). Without knowing the details of the exact system, I'm not sure which one would be the best one to use, but the odds that you'd have a system for which none of these existing solutions is suitable is rather low – and indeed, likely most of these systems are already using one or another – there are whole teams of sales people who have spent the last 20-30 years convincing government agencies (inter alia) to buy these solutions.
Whereas, you don't seem to know anything about that topic, and are speculating based on parallels with completely different disciplines (such as statistical mechanics).
We both are speculating due to lack of details about the specific systems under discussion, but wouldn't you expect the person whose speculations are based on greater relevant knowledge to be more likely to be correct?
I'm sorry, but just because I didn't pepper my post with shibolleths like z/OS or VSAM or the vagaries of ACCEPT and DISPLAY keywords, doesn't mean I don't know what I'm talking about. I worked specifically on connecting COBOL system to a DB/2 database, and one thing was for certain: understanding the data format was the hardest part of the problem. Those definitions, in our system, were tightly coupled to the user interface code, AND the batch processing code.
No, it's not my specialty and didn't work with this system for long, but my overall impression was that COBOL programmers get (understandably) low-level abstractions, and therefore had to build higher level abstractions themselves. This is not like modern software development where you have an embarrasment of riches from any level of abstraction you want, and a large system where every part of the stack is a custom solution is generally going to be more chaotic. To put some numbers on it, to add a column of data to the system I worked on required on average about 20k hours of coding work. No doubt some of this was sand-bagging, but I'd say 80% of it was legitimate.
> I worked specifically on connecting COBOL system to a DB/2 database, and one thing was for certain: understanding the data format was the hardest part of the problem.
But now you are shifting the goalposts: from getting readonly access to the data, to understanding what it actually means. Yes, I totally agree, a lot of legacy COBOL systems, it can be very hard to work out what the data actually means - even though you probably have a COBOL copybook telling you what the columns/fields are, they can be full of things like single letter codes where the documentation telling you what the codes mean is incorrect. And likewise, you are right that seemingly simple tasks like adding a field can be monumental work given the number of different transaction screens, reports, batch jobs, etc, that need to be updated, and the fact that many mainframe programmers don’t know what “DRY” stands for
But simply getting read-only access to data? Most mainframe COBOL systems would already support that. Could there be some really badly maintained ones in which it was never configured properly and they just give DOGE read-write access because DOGE refuses to wait for it to be done properly? I doubt that’s the norm but it might be a rare exception. Such a system would likely violate security standards for federal IT systems, but agencies can get exemptions.
> To put some numbers on it, to add a column of data to the system I worked on required on average about 20k hours of coding work.
20,000 hours is 10 years of full-time work for a single person. If you "didn't work with this system for long," it is quite simply statistically impossible that you could have witnessed enough projects to have anything resembling an accurate "average".
>20,000 hours is 10 years of full-time work for a single person.
Or, while we're mythical man-monthing it, 6 months of work for 20 people? Or merely a single sprint for 240 people!
[flagged]
You know that annoying thing where someone joins a new team, looks around, declares all their friction points to be easily solvable, dives in & starts making changes, and turns out to make a big giant mess?
And the reason is they don't understand the specific domain & context well enough to know what the actual hard problems are. Instead they're just pattern matching to things they do know and extrapolating. And it usually doesn't go well.
Dealing with a system that's replicating 50 years of regulatory rules is going to be that times infinity.
I don't think that's annoying. If they make a mess, then by the time they're done cleaning it up, they'll be an expert, and you won't even have to train them. That is exactly what you need when the system is broken. The existing people should be encouraging, let them try, and lend their wisdom when they can. Disruption has always helped the tech economy thrive and government should welcome the opportunity to learn this aspect of our culture.
>They don't even know how to build a website that works.
What percentage of people who know how to make a "website" do you think could make an automated tax system?
>the tech industry has been the beating heart of this country
Agriculture? Construction? The heart means something without which you can't function. How did people in the 1950s survive?
The agriculture industry is a skeleton crew for something that's largely been automated by tech: https://justine.lol/tmp/agriculture.jpg There's not much of a construction industry either, since the government doesn't let us build anything except sprawl.
The USG does in fact know how to build a website and it is intellectually lazy (so very lazy) to suggest otherwise. A high profile illustration of this is login.gov, which is SSO used across USG agencies. It's not possible to take a comment like this seriously, at all.
Elon Musk is also not an auditor. DOGE is not an auditing entity. You bring in accountants to audit. These are 20 y/o something programmers. How DOGE has been operating has been completely opaque and this lack of transparency just plays to the point that what someone says their goals are and what their actual goals are are not mutually exclusive, so no, Elon Musk shouldn't be allowed anywhere near these systems.
Are you familiar with healthcare.gov? It was a disaster. So the government let some people from the tech industry come in and help. Techies saved Obamacare and then founded an agency called USDS, who did other sites like login.gov. DOGE is basically doing what USDS pioneered, except now tech people have earned enough trust to fix the government itself, rather than just being the wiz kid who fixes their website.
Why haven't you responded to the substance of my point? Again:
> Elon Musk is also not an auditor. DOGE is not an auditing entity. You bring in accountants to audit. These are 20 y/o something programmers. How DOGE has been operating has been completely opaque and this lack of transparency just plays to the point that what someone says their goals are and what their actual goals are are not mutually exclusive, so no, Elon Musk shouldn't be allowed anywhere near these systems.
Your comments throughout this thread have a lot of baked-in assumptions (again in your reply with the bit about "tech people having earned enough trust" and reducing the whole tech industry to that of a "whiz kid who just doesn't fix websites anymore". Seriously? You really don't grasp how reductionist of a thought process this is?) and a closer examination on your behalf is warranted. Complex questions never have simple one-liner answers.
Even in this very thread there is stuff like this [0] being posted.
[0] https://apnews.com/article/nuclear-doge-firings-trump-federa...
"fixing the government" in this case seems to mean "destroy the government" for somewhat hidden purposes.
hidden? I think tearing down government is a pretty damned good fix, and so does many others
Why do you think this? Have you ever been to a country with a non-functioning government?
Somalia comes to mind, plenty of guns too, yet the Randians never last more than 10 minutes when they go
And then the person dropping this load of nonsense moves on without ever having to defend their point.
How do you combat this kind of bad-faith propagandizing? How do communities maintain some level of connection to reality and decency? It seems to infect every online space I visit.
Are you talking about me? Click parent a few times. I've brought back fresh nonsense just for you.
Have you been to China? It's like a science fiction movie. Now consider how Mao destroyed the old world, killed the old guard, and led the few remaining through decades of poverty rebuilding the glorious smart city society they have today. Trump is basically Gandhi compared to Mao. So I don't understand the weeping and wailing. Those people have all the guns in this country. If they want to try to fix America's government rather than murder us, I say let them try.
[flagged]
[flagged]
You’re the one arguing in bad faith. This administration is the most protective of the core functions of government of any GOP administration in decades. Bush wanted to privatize social security. Trump took that off the table.
You’re acting like DOGE is about turning the U.S. into some libertarian paradise. But look at what they’re actually focused on. Foreign aid is completely optional, but PEPFAR (an effective foreign aid program) promptly got a waiver. What’s been targeted for cuts? Stuff that detracts from the core mission, such as meddling with elections in India. The federal government is full of this shit—and full of people who care about distractions rather than the core mission.
I’m no libertarian, just a citizen who lived in Baltimore and rode Amtrak and has been to functional countries like Germany and Japan. I like government. But our government sucks at governance. And I’m fine with someone taking an axe to all the distractions so government can refocus on maintaining order and providing fundamental services.
