HN user

ben509

4,046 karma

I'm an engineer presently working for Capital One Investing, prior work at AWS for the CloudHSM team, before that Novetta, and before that I did 6 years in the army.

I'm also working on the Tenet language; see https://tenet-lang.org/

Also at https://keybase.io/ben509

YdRK9Q3mIBRWsRBonHhJCsgLnurwJk9eHbw1Jg4wz9M

Posts4
Comments1,545
View on HN

because I am ... most likely to have a functional dishwasher and even if yours is better I am not going to buy one more.

Break the population into groups:

1. Have a working dishwasher / don't need one

2. Old dishwasher is failing, looking for a new one

3. Just bought a new dishwasher, it works great

4. Just bought a new dishwasher, going to return it

I suspect group 4 is who they're targeting.

The main narrative is the usual war mongering. You're doing it in your post.

These are criminal actions, as they're not endorsed by the state.

But it doesn't have to reach the scale of war to be bad. The broader narrative is We Have To Do Something. And that Something is always grant the government more power. Why is it a good thing, for instance, that we're taking "unprecedented" steps?

The US has been dealing with ransoms, piracy, extortion since its founding. "From the halls of Montezuma, to the shores of Tripoli," the latter was one of our first expeditions to deal with piracy.

As there is plenty of precedent for dealing with this stuff, we should be very skeptical when the government insists it needs new powers.

I noticed that after I posted and had read a bit more; but you're also using F# which has proper ADTs. I'm typically writing support scripts in Python or the like, and even very good libraries like click[1] nevertheless reflect the idioms popular in the language.

I really came back to this post because I was struggling with Gradle and if there is a more perfect illustration of how a dry run mode could help than that, I don't know what it could be. Gradle builds are a fucking mystery, every time, and there's no excuse for it.

[1] https://palletsprojects.com/p/click/

Same here. I send everything that is firstlast@gmail straight to junk.

I also get a lot of email from idiots who don't know their own address

Holy crap there are a lot of them. I've got one bank sending me the dude's statements. He's also been on some interesting trips, seen all his hotel stays, etc.

I've done that and called the counter option --for-real, but I'd like both args so runbooks can spell out:

    1. do-step-one --dry-run
    2. (do validation)
    3. do-step-one --real-run
    4. (do validation)
Many commandline parsing libraries assume you're doing booleans, and I think --dry-run and --no-dry-run is confusing. And, internally, you have a boolean flag so there's always the possibility of some code getting it backwards.

Internally, I'd like an enum flag that's clearly dry_run or real_run, so the guards are using positive logic:

    switch(run) {
      case dry_run:
        print("Would do this...");
      case real_run:
        do_real_thing();
    }

US law derived from common law, which recognized a right to self defense. All 50 states, DC, and federal jurisdictions then codified that right as law. While the 2A is not directly about self-defense, it plainly guarantees an individual right to maintain the means for self-defense, which implies a right to self-defense.

There are cases covering a justifiable use of force because intentionally killing or harming a person is illegal, and self-defense is a defense against those charges.

It's normally perfectly legal to pay someone whatever you want. You don't need a defense against something that's not a crime. There's no conflict in paying a ransom, so there's no case law.

Regarding OFAC, as your link points out:

One issue is that victim organizations are required to check the list of sanctioned entities; however, many times the true identity of the cybercriminals are not known.

I'm guessing there's no case law regarding paying ransoms to SDNs because nobody has an identity they can check.

But do we need case law when OFAC says:

OFAC will consider a company’s self-initiated, timely and complete report of a ransomware attack to law enforcement to be a significant mitigating factor in determining the enforcement outcome if the situation is determined to have a sanctions nexus.

If someone wanted to make a law against paying ransom, it would be quite novel and courts would have to look for applicable doctrine. I think the doctrine of self-defense would be a roadblock.

The relevant blurb seems to be:

Build it Yourself

The DIY Edition is the only high-end laptop you can customize and assemble yourself from a kit of modules. Coming in at just 15.85mm thick and 1.3kg, the Framework Laptop delivers the modularity of a desktop in the form factor of a thin and light 13.5” notebook.

I don't think people here are considering all forms of ransoms, but you hit on an interesting aspect of it all the same.

It's why, I think, such a law wouldn't pass Constitutional review.

If your person is threatened with imminent danger, you have a right to self-defense, we'll even let you commit intentional homicide if the threat is serious enough.

And self-defense also covers your property and livelihood to a lesser extent.

I think it'd be extremely hard to convince courts that this right to self-defense doesn't include negotiating with an attacker. Imagine if it were a crime to toss some money at a mugger and run away, for instance.

Yeah, I was pushing that all under "recovery." Say it all sums to $C.

Arguably the bigger problem is you don't know that the ransomer will actually give you a valid key, but suppose you guess a likelihood P that they do.

Now you have some scenarios:

1. Don't pay. We're out $C.

2. Do pay, and get a valid key. We're out $R.

3. Do pay, and get no key. We're out $R + $C.

So the limit is at scenario 1 being equal to the combination of 2 and 3.

Set C = PR + (1-P)(R + C), and your max ransom R = CP

(You could probably work in additional costs for cleaning up even if the ransom is paid.)

It'd have to be an international effort as there are big mining operations are in Russia, Switzerland, China, Iceland as well as the US.

Being legal means that you can run big mining operations, so you could clamp down on those and slow mining. That would not stop it, though.

Being legal means that it can be used to trade goods and services, and you could clamp down on that and harm its value as a currency.

And being legal means that legal businesses can exchange it for other currencies, so clamping down on that harms its liquidity.

Even if you can make it broadly illegal across the globe, it's hard to see how effective that would be. Illegality has made anything else on the black market go away, after all, and the whole point of a crypto-currency is to thrive despite government suppression.

Part of the problem is it's very hard to value security because, frankly, so much security is theatrics and snake oil.

For instance, look at the consumer market, which is where an executive without security knowledge is coming from. All the big VPN vendors make security promises that are, frankly, false advertising. AV products are notorious for including warnings for viruses that pad their counts. That's not counting all the security applications that are malware.

And if they talk to someone familiar with the industry side, they should hear some skepticism. All the static analyzers are full of flags for things that are there to drive up their numbers. There have been a few HN stories on junk CVEs that are filed so people can put them on their resume. I had to set up a WAF at work that proudly said it mitigated the OWASP top-ten (why the top ten? is #11 not important?) which include recommendations like logging that a WAF is plainly not doing. And then I tested its defense against SQL injection and it was trivial to bypass.

And if a business that isn't a tech company hires contractors to fix security issues, most of the time, those guys will do a lot of check the box BS. It's fundamentally difficult, from a business operations perspective, for a company to do security because: 1. the horizon problem that you bring up 2. it's a cost-center 3. it's not their core expertise 4. if you even ask what secure looks like, you either get filibustered with long lists of best practices, or a lot of hand waving but strident proclamations.

Big-endian is natural when you're comparing numbers, which is probably why people represent numbers in a big-endian fashion.

Little-endian is natural with casts because the address doesn't change, and it's the order in which addition takes place.

The XY problem is really a collaboration problem... most discussion media are all horribly transient. When you're explaining a problem you did figure out all that context, but you're guessing as to what context the next person needs. That's necessarily going to leave out things you don't know you need to explain.

At work, I have to go from team to team for some issues, and we're special (yay) because we're an acquisition, so we're doing some very odd things by corporate standards. Even the fact that we have a customer facing application is unusual, and I've essentially renamed our API to be "BackendForFrontend" entirely because each new team assumes our API must be entirely developer facing.

What I've found is it's tremendously helpful to always link back to (and quote from) Jira issues so the necessary context is present whenever I'm asking questions. Whether it's Jira or Confluence, you want to treat problem resolution the way you do development: it's a permanent thing you're building. And I mean permanent, if you solve a problem, you do a write-up for future you.

And some questioners ... really seem to dislike if my first impulse is to ask "Why do you want to do that?"

An interview works both ways. If you can suss out the interviewer's nature and help you determine it's not a place you'd want to work, then trust that impulse.

One test is to search for something that's obviously a scam: '2TB flash drive'

You know these are scams because SSD chips with a high enough density to get 2TB in a keychain form factor are going to be cost thousands. When they're advertising $40 or $50, it's likely a 64GB drive with a controller that fakes the available storage.

Run some of those listings through FakeSpot and ReviewMeta to see how they do at identifying scams.

There were reports of the dangers of asbestos back in the 1900s, and the first medical report was in 1924. It took until the '60s before people took it seriously.

Many cases of mesothelioma could have been prevented if we had listened to people who thought it was dangerous.

You can't conclude from asbestos that we should shut down new ideas on the first warnings, nor can you conclude from the history of aviation that we should disregard those warnings.

You asked:

How can we work towards a better world when people just shoot down any idea that they don't agree with instead of trying to expand their perspective?

Going back to the original comment:

Perhaps we need a new "test", like the "Turing Test", but this time for when humans can no longer tell the difference between new technology and old technology. "Mighty", for example, is just a "dumb terminal" - technology we had in the 1970s.

You want progress. We gain technological progress through a ratcheting action. A ratchet must close over the progress it has already made in order to ensure the mechanism only moves forward.

Likewise, we only progress if the new thing is genuinely better than the old. That requires that you understand the old thing.

Do you think the metric system is better than US standard measurements? Riddle me this: why is a mile 5280 feet? What's special about that number?

There is a reason for that number. There's also a reason it probably doesn't matter in modern usage, but unless we understand why we don't need that special property, we can't be sure that the metric system is actually progressing over the older systems and not regressing.

That's why you get this comment and others pointing out that this is simply tech from the '70s. If it's 50 years old tech, there's no progress going on. They are not failing to expand their perspectives, they are recognizing that this stuff is something they're already familiar with.

That's the claim made by Google and many other big corporations. It's plausible enough, but I haven't seen any hard evidence that it's true.

Suppose it is true that these companies can't reveal their decision making because there's so much to be gained by bad actors that game these highly centralized systems.

Then it seems like a larger number of smaller firms could be more transparent and still achieve the same effective level of security.

Most of my unit tests have print statements in them, permanently, because I usually know what things I expect will break. There's a ton of utility in being able to understand a problem by reading a transcript.

That's print debugging, and it's not going anywhere as long as unit tests are around.