>“If nearly half of all Blacks are not OK with white people, according to this poll, not according to me, according to this poll,” Adams says calmly in the clip. “That’s a hate group. That’s a hate group and I don’t want anything to do with it. And I would say based on the current way things are going, the best advice I would give to white people is get the hell away from Black people. Just get the f-ck away. Wherever you have to go, just get away.”
Dilbert’ Creator Scott Adams Compares Women Asking for Equal Pay to Children Demanding Candy:
"The reality is that women are treated differently by society for exactly the same reason that children and the mentally handicapped are treated differently. It’s just easier this way for everyone. You don’t argue with a four-year old about why he shouldn’t eat candy for dinner. You don’t punch a mentally handicapped guy even if he punches you first. And you don’t argue when a women tells you she’s only making 80 cents to your dollar. It’s the path of least resistance. You save your energy for more important battles." -Scott Adams
"It's real" and "it's not real" are both poor explanations of gender pay gaps that aren't educational.
Claudia Goldin won a Nobel last year partly for explaining them - a rough summary is whether women work has changed over time (highest when everyone was a farmer, lowest 1950sish, now up again), the pay gap does exist currently and appears to be caused by having children, and prior to having children the current generation of women are paid more likely due to being more educated than men.
The "it doesn't exist" argument is something like "it doesn't exist if you control for job choice and seniority level", which is an example of conditioning on a collider because those things are /caused by/ motherhood, so you can't control for them.
It's a vague aphorism from a guy who went nuts with no added context to explain why it's relevant here. It's not offensive so much as low-quality and unrelated to the link.
I don't doubt that this happened, but if you use e-verify and fill in Form I-9 how does this happen? I'm in the middle of hiring an F-1 student on OPT and I need to look at his EAD and verify it's not fake according to my lawyer. So I do. Nice and easy.
Here in the US that likely means a state ID, such as a driver’s license, and a Social Security Number (SSN). None of which anyone would reasonably consider secure. I’m sure any national intelligence agency could probably manage stealing an SSN and forging a driver’s license to go with it, at least to the degree necessary to fool an employer for a little while.
They can forge a real one by providing enough forged identity documents and paying the right bribes. They don't need to suborn the private keys - Just the people who have "use" access to them.
You can create a forged chipped passport, just have the chip not work. Won't work at the border, but would be fine everywhere else you show a passport. I've never had anyone (bars, hotels etc) read a chip.
Of course they can. Have you not seen any Bond or Mission Impossible Movies?
But seriously, why would they not be able to? They will almost certainly have high-level connections into the State Dept. (or whatever agency issues passports for your country) that allows them to create any passports they need. Same way the Police can get license plates for undercover vehicles from the DMV that don't list "One Police Plaza" if someone (i.e. "other" Police) runs the plates.
They can and also now you know why they use specific countries like Brazil, etc to forge fake identities (other than the fact it’s easier to mask the accent / cultural things). Also not all passports are chipped - it is not a requirement for us visa, only vwp
The likely approach would probably be less technical and more covert ops, tricking the target country into issuing a (technically) genuine passport. No need to break encryption/signing this way.
> No record for him nor his social security number seemed to check out
This is the part that doesn't make sense. But the other sibling comment is probably right. It might have been before e-verify was widely in use. Besides, you just run through Checkr and friends unless you know the guy, so this "no record of him" thing would pop up these days.
I suppose I'm not too concerned about this attack vector now that we have this stuff.
E verify was definitely not ubiquitous two decades ago. Even during Covid one of my friends didn’t have his new employer actually verify i9 docs until a year into employment…
I remember a few months ago there was a discussion[1] here about how fossil, the VCS for sqlite, should bring in a dependency on mermaid charts already.
Nothing against mermaid, but I guess supply chain attacks are hard to conceptualise until they happen. When we're shortsighted we risk our mitigations against vague but serious threat models losing out against convenience.
Many moons ago, I was active on the fossil list (right before it became a forum, one of the many things fossil has built-in), hoping to achieve the opposite of this: a libfossil containing the core technology for a fossil repo, without all the other stuff that comes along with it.
Someone had started work on this, but was unable to complete it. The maintainers were willing to consider the idea, but not do it themselves, which is (always, for any request, on any open source project, at any time) completely understandable.
I still think it would be great if someone with the ability/interest/time made it happen. Version control is useful for many things other than software, and fossil's architecture is well-suited for a linkable all-purpose revision control library.
Well... supply chain attacks are trivial to anticipate. A lot of modern programming (I'm thinking JavaScript especially when I say this) involves what seems to be 100s of dependencies. If there is a 1% chance of a random repo having a backdoor, the project will be compromised. That is clear and obvious.
The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage to those who don't. A project with high risk tolerance has to write a fraction of the code and solve a fraction of the problems as someone who carefully writes secure software.
The trade off isn't just "convenience", we're talking massive differentials in productivity that favour insecure models. It is much cheaper to accept that data will leak sooner or later, to the point where we can assume that if something is economically developed that is evidence it can't possibly be secure. That isn't an argument for more security though; if possible it is better to just design systems where leaks don't matter (eg, here in HN it isn't clear why I'd care about a leak - everything is already public except for the IP address in the server log).
> The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage to those who don't
People say this, but it my experience, it simply isn't true. You're at a _slight_ economic disadvantage, and if you anticipate it, and correctly staff and plan for it, it's entirely manageable. The huge win is that in the long run you are massively more productive and you're not held back by framework incompatibilities, version updates, or web standards changing faster than you can keep up.
Many shops don't have the mentality or the expertise to actually do this, partly I feel because this canard as taken as rank truth and no one ever dares to challenge it. Web standards have gotten much better in the past 10 years, they're actually pleasant and useful now.
> we're talking massive differentials in productivity
You have an ability to get something that feels "fully featured" off the ground more quickly. I'd wait for the actual user reviews before I make a decision on the quality of the output.
1) Best of luck in an audit explaining that there is almost a 14% chance that your project is free of backdoors given reasonable assumptions. I recommend taking a photo of the auditor's expression and reporting back.
2) There are quibbles to be had about the IID assumption here; dependencies tend aren't selected randomly and attackers aren't targeting them randomly.
3) You don't need a for loop for that, you can calculate directly with `1-(0.99*200)`.
Sorry, what does being Norwegian have to do with it? Going to the physical bank with a physical check seems like too many steps no matter what country you're from.
At least in Canada, the numbers provided for direct deposit are the same numbers used for direct/pre-authorized debit (i.e. withdrawals). So, while your employer likely wouldn’t abuse that information? People may be wary of giving out those numbers unless absolutely necessary, since someone could indeed drain their bank account. They’re also the same numbers that appear on cheques, so someone could easily forge a cheque in your name with those numbers.
> the numbers provided for direct deposit are the same numbers used for direct/pre-authorized debit (i.e. withdrawals)
Reading up on that, it seems similar in nature to our AvtaleGiro[1]. While indeed having my account number would allow a business to issue a AvtaleGiro request, it's just a request. I would then have to go to my (online) bank and approve it, including setting up a monthly withdrawal limit. So it can't happen without action on my part.
> They’re also the same numbers that appear on cheques, so someone could easily forge a cheque in your name with those numbers.
Cheques I don't know about because they were going the way of the Dodo even when I was young, but we did have BrevGiro[2] which was a way to transfer money. However it relied on the bank sending me serialized pre-filled forms, so someone would have to steal one of those as well to be able to withdraw money from my account.
That’s the biggest difference - here there isn’t a request, the money’s just gone. I can of course go through the process of calling my bank, filing a fraud claim, waiting 6-8 weeks and then hopefully getting my money back, but that’s not particularly ideal. Especially since lots (most?) of the population is living paycheck to paycheck, and all that they have is probably sitting in the same bank account that they receive said paycheck in.
The median US household has $8k in checking+savings accounts, three months of expenses saved, and a net worth of $193k and therefore is probably not "living paycheck to paycheck" in the sense you meant. Also, "living paycheck to paycheck" is a made up status with no clear definition, invented by payday loan companies for lobbying purposes.
However, many Americans do say on surveys that they are doing it. This happens even if they say their income is $200k/year. The likely explanation for this is that nobody knows what it means and are answering something like "if I missed a paycheck I'd feel bad about it".
A funny thing that happens with this discourse is that it comes up all the time, and every single time a hundred people reply those numbers are a trick because of outlier rich people, and then it turns out none of them know what a median is.
In America they can and do also take money out of your account, to correct errors supposedly, but sometimes also in error. I still get paid on paper to this day because to me the terms of the direct deposit agreement are overbroad.
In the US, if you know someone's routing/bank number, name, and address, you can write cheques in their name.
There's companies that make their money on selling (now, usually older folk) literal books of cheques. One of the ways you can pay is literally for them to write themselves a cheque from "you" that gets processed digitally.
The US is a strange banking system wherein I have had the unpleasant experience of putting my card into the reader at a 7-11 and it just... Not work. Why? Nobody knows. ApplePay sometimes works -- some readers know how to handle it, others lose their shit and crash.
I'm a tech contractor. I prefer payment by check from my clients. Most can't or don't want to set up direct deposit for a part time contractor. Amounts are too large for Zelle, and I don't want to pay the fees for paypal or credit card processing if I can avoid it.
My clients usually issue paper checks online. Their bank prints the check and mails it. My receiving address is my bank, which deposits checks for me when they arrive.
It’s even easier to do it the way described. The banks are printing and mailing and processing the checks, which they can do with high efficiency. From the payor’s pov, it’s easier not to worry about tracking account numbers and just using the address which they already know.
And the payee doesn’t need to share their bank info.
It does. The US banking system is still predicated on paper checks, however, and efforts to change that face considerable inertia. There have been posts on HN explaining how (insanely) it all works.
ACH takes days to weeks to clear anyway, especially if new sender or large amounts = untrusted. There is no real exception handling so you are given the amount on credit.
Maybe I'm a bit to naive since I don't know the US banking system, but at least in the EU you just need to tell someone your IBAN and Name and they can transfer money to your account. Is it that much harder in the US?
Yes, you can get wire transfers or ACH at most banks with a routing number and account number. But wire transfers usually cost money to send, and sometimes cost money to get. Generalized ACH transfers usually come through a service provider, and that costs money too.
Also, the same numbers can be used to credit and debit an account, and also to forge checks. So giving your payment credentials (or writing a check) is a security risk. I'm a little fuzzy on details, but someone at my employer at the time (Facebook) had my payroll data on a device in a laptop bag that got stolen in San Francisco, and as a result I had to be hyper vigilant on checking for unauthorized transactions (or get a new account number, but that's more disruptive, assuming the theft was just normal SF theft, like it probably was)
Developer in the Midwest. I was paid by paper check brought to my desk by the office manager from early-aughts until 2012 when they switched to direct deposit.
I certainly got checks at internships in 1999-2000 and at a job I briefly held in 2001. I guess my first real-real job was 2006 and for sure I got checks for at least the first few months. It was a mild pain to do the (literal) paperwork for direct deposit, and a mild pain to receive checks (I'd categorize it as a major pain now, but you were running errands more often then and even at the bank for other crap), so laziness won for a while.
We're approximately the same age, and the first time I held job at which I had the option for direct deposit was 2003. I remember it particularly because I thought it was cool, and evangelized it to co-workers, many of whom did not trust it and opted to continue receiving paper checks.
I had the option to be paid by paper check as recently as 2017, and probably still would if I had remained working for that employer (a US-based legacy insurance carrier).
Pretty common in the US back then. Direct deposit is (still) only required to be provided at the company's bank, though I doubt anyone implements that minimum any more.
Back in the 90s when I worked for Atari (Back in the terrible Warner period) you could only get DD at the company's bank, which was a small bank with one branch, in Sunnyvale (surely the company had another bank or two as well?). I was told they did this so they could invest the float over the week end and early in the week.
Not really. More like, “we could make an extra hundred bucks a week by doing X”. So they do X. If it’s annoying to the employees, that cost is not considered.
Using money you owe for something else for as long as you get away with is hardly alien in business in general. It is why most companies (almost every company?) delay payment of invoices for as long as legally possible, no point losing that fraction of whatever in interest (or interest saved on debt). Heck, with regard to cheques it is why banks held on to 3+ clearing periods on those and other payments for as long as they did. Doing the same with outgoings to employees isn't a stretch that would surprise me in the slightest.
I don't understand this. You go through all this trouble to build a fake identity and then you don't do this one simple thing to make sure you look like a real employee?
Why go through the risk of trying to deposit a cheque when the plan worked perfectly fine as is?
Once you get banks involved, seems like more of a risk of something getting flagged there rather than someone in payroll noticing cheques weren't deposited within the time you were there.
People with fake identities because they're working as a spy have real bank accounts. But more importantly, cheque-cashing places give a god-awful return but would still look more legitimate then just not ever cashing anything.
In short: the details of this story make no sense for the implied narrative (spy). They make a lot of sense for "not mentally well person" or "guy who suddenly had to disappear for other reasons". Combined with just "regular software developer things".
For example - I've cloned the entire git repository server of every place I've ever worked at. I have a script which does it for Github and Gitlab, because usually when you're exploring a codebase you wind up needing just "every repo" and it's easier to dump it all in a folder on my work machine ahead of time. I've run "find" on a network share because have you ever tried to figure out where a particular word document might be after looking through 10+ years of random SMB share naming systems and empty folders?
Read the stories of long-term agents from the Cold War - for both sides, but Russians in America is easier to find the stories of. Spies don't act secretive, spies blend by acting normal. They're an unremarkable next door neighbor who never draws any attention and works a respectable job. They're polite to their neighbors but keep to themselves, they do things on time and promptly, they have identities that check out and do normal things like "get paid from a regular job".
Whereas people absolutely can and do simply ghost jobs all the time. Like a simple explanation here for this guy would be "was actually an illegal immigrant and someone told him that going from contractor to full time employee might be too much exposure, got spooked and bailed". Probably was just an actual software developer. And if you here "illegal immigrant" and think "Mexican" you're also wrong - plenty of people overstay or exceed the bounds of their visas in the US.
P.S. "contributed a large number of commits to the project he was assigned to" - you know, as would be expected when you're hired to work on something? What was in those commits? Why is it omitted from the story?
Two months is short enough that it doesn't look abnormal; I've left my paychecks uncashed for a month or more while I dealt with everything else around moving for a new job.
I don't disagree that it was poor opsec, but the rest of the story makes it clear enough that they were burning the identity/employee quickly enough that it really didn't matter.
Banks have a stricter KYC than companies that hire someone. The person would have needed to forge an identity that stood up to the scrutiny of the bank or risk linking it to their real identity or something. If they aren't doing it for the pay check seems like a bunch of extra work for not much gain.
> in that he had apparently downloaded a copy of everything
… is a day in the office? I've done this, particularly at places that are "one repo == one project" organized (i.e., not monorepo): e.g., if I make a breaking change to a library, I'm going to update all the uses of that. Still to this day, the easiest way to do that is locally, with command line tooling.
If you look at the Nintendo Gigaleaks, you'll discover that most of Nintendo hardware had one single CVS (later SVN) repository that held everything. Same with BroadOn, even up into 2010, when the cvs backup was taken.
It's fairly well known that Google maintained a Stinky monorepo for a long time and one of the risks is someone just going and slurping the whole thing up onto a big enough drive and walking out the door.
I'd much rather this than needing to agree to hundreds of commercial entities eating my data and spreading it to [deity] knows how many more, or clicking hundreds of "legitimate interest in our position as a stalker" checkboxes to opt out, which is required for taking stuff using many other publishing options.
Requiring JS to read a simple article is undoubtedly wasteful, of course, but there are far worse insults you can make to you readership.
98 comments
[ 5.0 ms ] story [ 153 ms ] threadThe Death of Dilbert and False Claims of White Victimhood:
https://time.com/6259311/dilbert-racism-scott-adams/
>“If nearly half of all Blacks are not OK with white people, according to this poll, not according to me, according to this poll,” Adams says calmly in the clip. “That’s a hate group. That’s a hate group and I don’t want anything to do with it. And I would say based on the current way things are going, the best advice I would give to white people is get the hell away from Black people. Just get the f-ck away. Wherever you have to go, just get away.”
Dilbert’ Creator Scott Adams Compares Women Asking for Equal Pay to Children Demanding Candy:
https://comicsalliance.com/scott-adam-sexist-mens-rights/
"The reality is that women are treated differently by society for exactly the same reason that children and the mentally handicapped are treated differently. It’s just easier this way for everyone. You don’t argue with a four-year old about why he shouldn’t eat candy for dinner. You don’t punch a mentally handicapped guy even if he punches you first. And you don’t argue when a women tells you she’s only making 80 cents to your dollar. It’s the path of least resistance. You save your energy for more important battles." -Scott Adams
Claudia Goldin won a Nobel last year partly for explaining them - a rough summary is whether women work has changed over time (highest when everyone was a farmer, lowest 1950sish, now up again), the pay gap does exist currently and appears to be caused by having children, and prior to having children the current generation of women are paid more likely due to being more educated than men.
The "it doesn't exist" argument is something like "it doesn't exist if you control for job choice and seniority level", which is an example of conditioning on a collider because those things are /caused by/ motherhood, so you can't control for them.
Not saying this helps in any way for employment purposes today, but the technology is out there in many places.
Here (.nl) you need either a passport or an ID card and you are supposed to verify its authenticity.
Meaning you can use a social security number of a dead person. A common form of immigration fraud.
In Germany you definitely don't have to. None of my past or current employers has ever seen my ID.
But seriously, why would they not be able to? They will almost certainly have high-level connections into the State Dept. (or whatever agency issues passports for your country) that allows them to create any passports they need. Same way the Police can get license plates for undercover vehicles from the DMV that don't list "One Police Plaza" if someone (i.e. "other" Police) runs the plates.
This is the part that doesn't make sense. But the other sibling comment is probably right. It might have been before e-verify was widely in use. Besides, you just run through Checkr and friends unless you know the guy, so this "no record of him" thing would pop up these days.
I suppose I'm not too concerned about this attack vector now that we have this stuff.
Nothing against mermaid, but I guess supply chain attacks are hard to conceptualise until they happen. When we're shortsighted we risk our mitigations against vague but serious threat models losing out against convenience.
[1]https://news.ycombinator.com/item?id=38886344
Someone had started work on this, but was unable to complete it. The maintainers were willing to consider the idea, but not do it themselves, which is (always, for any request, on any open source project, at any time) completely understandable.
I still think it would be great if someone with the ability/interest/time made it happen. Version control is useful for many things other than software, and fossil's architecture is well-suited for a linkable all-purpose revision control library.
The problem is that the people who act on this and minimise dependencies are at a significant economic disadvantage to those who don't. A project with high risk tolerance has to write a fraction of the code and solve a fraction of the problems as someone who carefully writes secure software.
The trade off isn't just "convenience", we're talking massive differentials in productivity that favour insecure models. It is much cheaper to accept that data will leak sooner or later, to the point where we can assume that if something is economically developed that is evidence it can't possibly be secure. That isn't an argument for more security though; if possible it is better to just design systems where leaks don't matter (eg, here in HN it isn't clear why I'd care about a leak - everything is already public except for the IP address in the server log).
People say this, but it my experience, it simply isn't true. You're at a _slight_ economic disadvantage, and if you anticipate it, and correctly staff and plan for it, it's entirely manageable. The huge win is that in the long run you are massively more productive and you're not held back by framework incompatibilities, version updates, or web standards changing faster than you can keep up.
Many shops don't have the mentality or the expertise to actually do this, partly I feel because this canard as taken as rank truth and no one ever dares to challenge it. Web standards have gotten much better in the past 10 years, they're actually pleasant and useful now.
> we're talking massive differentials in productivity
You have an ability to get something that feels "fully featured" off the ground more quickly. I'd wait for the actual user reviews before I make a decision on the quality of the output.
Apologies for nit-picking, but that's not quite how sum-of-probabilities work. Total probability across 200 tries of 1% chance each, is ~87%:
Your "sooner or later, to the point where we can assume" conclusion, still stands, of course.1) Best of luck in an audit explaining that there is almost a 14% chance that your project is free of backdoors given reasonable assumptions. I recommend taking a photo of the auditor's expression and reporting back.
2) There are quibbles to be had about the IID assumption here; dependencies tend aren't selected randomly and attackers aren't targeting them randomly.
3) You don't need a for loop for that, you can calculate directly with `1-(0.99*200)`.
I don't understand this. People were paid by cheque in the early 2000s?
Quite unusual for a tech contractor though.
As a Norwegian that sounds so alien. They couldn't do anything but deposit money, so why wouldn't you?
Almost everyone does direct deposit. But it’s not a legal requirement for an employee to be paid that way.
Good point, good point...
I went to check, and it seems we've just recently plugged[1] that hole here in Norway. Salary and other benefits must be paid to a bank account now.
[1]: https://www.gpokonomi.no/2022/01/26/forbud-mot-kontant-utbet...
Presumably to avoid this:
> Because you’re trying to plant backdoors you don’t want any paper trail?
Reading up on that, it seems similar in nature to our AvtaleGiro[1]. While indeed having my account number would allow a business to issue a AvtaleGiro request, it's just a request. I would then have to go to my (online) bank and approve it, including setting up a monthly withdrawal limit. So it can't happen without action on my part.
> They’re also the same numbers that appear on cheques, so someone could easily forge a cheque in your name with those numbers.
Cheques I don't know about because they were going the way of the Dodo even when I was young, but we did have BrevGiro[2] which was a way to transfer money. However it relied on the bank sending me serialized pre-filled forms, so someone would have to steal one of those as well to be able to withdraw money from my account.
[1]: https://no.wikipedia.org/wiki/AvtaleGiro
[2]: https://no.wikipedia.org/wiki/Brevgiro
However, many Americans do say on surveys that they are doing it. This happens even if they say their income is $200k/year. The likely explanation for this is that nobody knows what it means and are answering something like "if I missed a paycheck I'd feel bad about it".
https://twitter.com/besttrousers/status/1753260817389162516
A funny thing that happens with this discourse is that it comes up all the time, and every single time a hundred people reply those numbers are a trick because of outlier rich people, and then it turns out none of them know what a median is.
There's companies that make their money on selling (now, usually older folk) literal books of cheques. One of the ways you can pay is literally for them to write themselves a cheque from "you" that gets processed digitally.
The US is a strange banking system wherein I have had the unpleasant experience of putting my card into the reader at a 7-11 and it just... Not work. Why? Nobody knows. ApplePay sometimes works -- some readers know how to handle it, others lose their shit and crash.
My clients usually issue paper checks online. Their bank prints the check and mails it. My receiving address is my bank, which deposits checks for me when they arrive.
And the payee doesn’t need to share their bank info.
https://engineering.gusto.com/how-ach-works-a-developer-pers...
(From parent) > And the payee doesn’t need to share their bank info.
And this is a US concept where having the magic numbers lets you pull any amount you want, with no ability to have a "push only" number...
The account number is on the invoice..
Yes, you can get wire transfers or ACH at most banks with a routing number and account number. But wire transfers usually cost money to send, and sometimes cost money to get. Generalized ACH transfers usually come through a service provider, and that costs money too.
Also, the same numbers can be used to credit and debit an account, and also to forge checks. So giving your payment credentials (or writing a check) is a security risk. I'm a little fuzzy on details, but someone at my employer at the time (Facebook) had my payroll data on a device in a laptop bag that got stolen in San Francisco, and as a result I had to be hyper vigilant on checking for unauthorized transactions (or get a new account number, but that's more disruptive, assuming the theft was just normal SF theft, like it probably was)
Back in the 90s when I worked for Atari (Back in the terrible Warner period) you could only get DD at the company's bank, which was a small bank with one branch, in Sunnyvale (surely the company had another bank or two as well?). I was told they did this so they could invest the float over the week end and early in the week.
To me late payment means they are possibly insolvent so I am looking for another job.
Once you get banks involved, seems like more of a risk of something getting flagged there rather than someone in payroll noticing cheques weren't deposited within the time you were there.
In short: the details of this story make no sense for the implied narrative (spy). They make a lot of sense for "not mentally well person" or "guy who suddenly had to disappear for other reasons". Combined with just "regular software developer things".
For example - I've cloned the entire git repository server of every place I've ever worked at. I have a script which does it for Github and Gitlab, because usually when you're exploring a codebase you wind up needing just "every repo" and it's easier to dump it all in a folder on my work machine ahead of time. I've run "find" on a network share because have you ever tried to figure out where a particular word document might be after looking through 10+ years of random SMB share naming systems and empty folders?
Read the stories of long-term agents from the Cold War - for both sides, but Russians in America is easier to find the stories of. Spies don't act secretive, spies blend by acting normal. They're an unremarkable next door neighbor who never draws any attention and works a respectable job. They're polite to their neighbors but keep to themselves, they do things on time and promptly, they have identities that check out and do normal things like "get paid from a regular job".
Whereas people absolutely can and do simply ghost jobs all the time. Like a simple explanation here for this guy would be "was actually an illegal immigrant and someone told him that going from contractor to full time employee might be too much exposure, got spooked and bailed". Probably was just an actual software developer. And if you here "illegal immigrant" and think "Mexican" you're also wrong - plenty of people overstay or exceed the bounds of their visas in the US.
P.S. "contributed a large number of commits to the project he was assigned to" - you know, as would be expected when you're hired to work on something? What was in those commits? Why is it omitted from the story?
I don't disagree that it was poor opsec, but the rest of the story makes it clear enough that they were burning the identity/employee quickly enough that it really didn't matter.
Leaving the checks uncashed means there's less of a paper trail to follow.
They are still ubiquitous today, let alone in the early 2000s.
> in that he had apparently downloaded a copy of everything
… is a day in the office? I've done this, particularly at places that are "one repo == one project" organized (i.e., not monorepo): e.g., if I make a breaking change to a library, I'm going to update all the uses of that. Still to this day, the easiest way to do that is locally, with command line tooling.
It's fairly well known that Google maintained a Stinky monorepo for a long time and one of the risks is someone just going and slurping the whole thing up onto a big enough drive and walking out the door.
Requiring JS to read a simple article is undoubtedly wasteful, of course, but there are far worse insults you can make to you readership.
They'll just release a package that has extra code than a clean build from source.