whyever

There was Quelle, Europe's largest mail-order and retail company. They were excited about mailing their catalogue on CD-ROM, but slept on the Internet. In 2009, they went bankrupt.

LLMs are vulnerable to prompt injection attacks, so I'm not sure they are in advantage.

Note that N=1 for the memory safety vulnerabilities they had with Rust, so the error of the estimated average number of vulnerabilities per LOC is quite large.

It's missing which point?

I agree, but https://www.pcg-random.org/ still advertizes PCG as "challenging" to predict, and critizises other RNGs as predictable and insecure.

Yes, but this relation does but apply to statistical mechanics and statistical physics, they mean the same: https://en.wikipedia.org/wiki/Statistical_mechanics

What is included in "statistical physics" that is not included in "statistical mechanics"?

They are synonyms.

Signal asks you to repeat the key immediately before even enabling backups. It cannot fail much later unless you modify the digit after the check.

That's a good question! Especially after Frank McSherry's COST paper [1], it's hard to imagine where the sweet spot for Spark is. I guess for Databricks it makes sense to push Spark, since they are the ones who created it. In a way, it's their competitive advantage.

[1] https://www.usenix.org/system/files/conference/hotos15/hotos...

It's a quantitative problem. How big is the error introduced by the simplification?

I know some people who do trunk-based development with pair programming: You write the code together, and once you are satisfied, you merge it to the main branch, from where it is deployed to production if the tests pass. It works well for them.

It would require a lot more memory, because you have to remember every generated UUID. And how would you do the partial match? You are not going to observe any collisions.

Doesn't the clustering make collisions strictly more likely?

You can also look at the expected number of collisions instead, which is approximately the number of random numbers squared, divided by the size of the space of random numbers.

Then you can choose how many collisions to accept on average. (If the answer is zero, then it makes more sense to look at the probability of one or more collisions.)

With that access you can also "do" things, like sending messages or delete stuff.

If you break E2E encryption, you can likely also impersonate and "do" things.

I know some conservative newspapers (Frankfurter Allgemeine Zeitung) kept using the old orthography for a while, but even they started using the new one in 2007, ten years after the reforms.

Yes, in this case it would be easier to brute-force the key instead of the password, so the additional characters don't really help.

Such long passwords are silly, they will be effectively truncated by the key length of the underlying cryptography.

That's not how errors add up, it's nonlinear. You have to take the sum of squares. So in your case, it wouldn't be 10 * 0.01 = 0.1, but sqrt(10 * 0.01^2) = 0.032, which is less than one third of a tenth.

I think the argument was about automated killing, not automated weapons.

There are already drones from Germany capable of automatic target acquisition, but they still require a human in the loop to pull the trigger. Not because they technically couldn't, but because they are required to.

All the attacks you described also apply to downloading and executing a file. I don't think `curl | sh` is worse in this regard.

Ok, so how would such a secret end up in a commit? E.g., I don't see why I would have my home address anywhere close to a code repository. Maybe if I used the wrong "secret" email address when authoring the commit?

If it's not possible to invalidate your compromised software secrets, I would argue that you have bigger and more urgent problems to fix. But fair enough: Deleting them from GitHub might reduce the impact in such cases.

If you rotated the secret, why do anything else? I don't think there is any potential further damage (except maybe reputational).

I mean, webp was made by Google and we know how many of their heavily promoted creations are dead already...

I don't understand this argument. WebP is an algorithm, not a service. You cannot kill it once it's published.

Docker is not really a security boundary (unless you use something like gVisor), so it's a bit of a red herring here.

The idea is to make your app immutable and store all state in the DB. Then, with every deployment, you throw away the VM running the old version of your app and replace it with a new VM running the new version. If the VM running the old app somehow got compromised, the new VM will (hopefully) not be compromised anymore. In this regard, this approach is less vulnerable than just reusing the old VM.

If it is a disagree button, then why is it disabled for new users?

Access logs do help with this. They have been successfully used by the police to identify rogue officers abusing their access to police databases.

They main defense against internal attacks is bookkeeping. Banks have been dealing with this for thousands of years. I recommend the corresponding chapter in Security Engineering by Ross Anderson: https://www.cl.cam.ac.uk/archive/rja14/Papers/SEv3-ch12.pdf

by choosing to write safe Rust you're sacrificing many perfectly good patterns that the compiler can't understand in exchange for safety

Historically, programmers drastically overestimate their ability to write perfectly safe code, so it's an enormous benefit if the compiler is able to understand whether it's actually safe.

How often do you care about the order in which objects are dropped?