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.
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).
> 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 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.
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…
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.
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.
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).
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 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?
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.
[+] [-] jddj|2 years ago|reply
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
[+] [-] roenxi|2 years ago|reply
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).
[+] [-] datascienced|2 years ago|reply
[+] [-] dilyevsky|2 years ago|reply
[+] [-] deathanatos|2 years ago|reply
> 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.
[+] [-] indrora|1 year ago|reply
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.
[+] [-] jonhohle|1 year ago|reply
[+] [-] 77pt77|1 year ago|reply
They'll just release a package that has extra code than a clean build from source.
[+] [-] bandrami|1 year ago|reply
[+] [-] renewiltord|2 years ago|reply
[+] [-] greyface-|2 years ago|reply
[+] [-] kortilla|2 years ago|reply
[+] [-] furyofantares|2 years ago|reply
[+] [-] dboreham|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] curiousgal|2 years ago|reply
I don't understand this. People were paid by cheque in the early 2000s?
[+] [-] gumby|2 years ago|reply
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.
[+] [-] astrange|2 years ago|reply
Quite unusual for a tech contractor though.
[+] [-] furyofantares|2 years ago|reply
[+] [-] nimih|2 years ago|reply
[+] [-] donatj|2 years ago|reply
[+] [-] NelsonMinar|2 years ago|reply
[+] [-] leoh|2 years ago|reply
[+] [-] 77pt77|2 years ago|reply
They are still ubiquitous today, let alone in the early 2000s.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] crotchfire|2 years ago|reply
[deleted]
[+] [-] dspillett|2 years ago|reply
Requiring JS to read a simple article is undoubtedly wasteful, of course, but there are far worse insults you can make to you readership.
[+] [-] smitty1e|2 years ago|reply
[deleted]
[+] [-] astrange|2 years ago|reply
[+] [-] smitty1e|2 years ago|reply
[+] [-] leoh|2 years ago|reply