Same in Python, Rust, Haskell and probably many others.

But apparently JS does work that way, that is its filter always iterates over everything and returns a new array and not some iterator object.

It could also be this: Cheang, R. T., Skjevling, M., Blakemore, A. I., Kumari, V., & Puzzo, I. (2024). Do you feel me? Autism, empathic accuracy and the double empathy problem. Autism, 0(0). https://doi.org/10.1177/13623613241252320

Oracle trilateration refers to an attack on apps that have filters like “only show users closer than 5 km”. In case of the vulnerable apps, this was very accurate, so the attacker could change their position from the victim (which does not require physical movement, the application has to trust your device on this, so the position can be spoofed) until the victim disappeared from the list, and end up a point that is almost exactly 5 km from the victim.

Like if it said the user is 5km away, that is still going to give a pretty big area if someone were to trilateral it because the line of the circle would have to include 4.5-5.5km away.

This does not help, since the attacker can find a point where it switches between 4 km and 5 km, and then this point (in the simplest case) is exactly 4.5 km from the victim. The paper refers to this as rounded distance trilateration.

I really need to try out Mercury one day. When we did a project in Prolog at uni, it felt cool, but also incredibly dynamic in a bad way. There were a few times when we misspelled some clause, which normally would be an error, but in our case it just meant falsehood. We then spent waaay to much time searching for these. I can’t help but think that Mercury would be as fun as Prolog, but less annoying.

I actually use from time to time the Bower email client, which is written in Mercury.

Ultimately you can configure these however you want. On my 5600X, I easily got one full execution of scrypt to last 34.6 seconds (--logN 27 -r 1 -p 1 in the example CLI), and one full execution of bcrypt to last 47.5 seconds (rounds=20 and the bcrypt Python library).

This kind of configuration (ok, not this long, but definitely around 1 second per execution) is very common in things like password managers or full disk encryption.

I’m betting there’s probably something that generates the key from a vastly smaller player input, i.e what gameobjects you interacted with, in what order, or what did you press/place somwhere. But that also means that the entropy is probably in the bruteforcable range, and once you find the function that decrypts the secrets, it should be pretty easy to find the function that generates the key, and the inputs it takes.

When handling passwords, it is standard practice to use an intentionally costly (in CPU, memory, or both) algorithm to derive the encryption key from the password. Maybe the dev can reuse this? The resulting delay could easily be masked with some animation.

I really love watching ARAMSE and Brian Quan, they have a lot of knowledge about coffee and are very entertaining at the same time.

I also enjoy watching The Real Sprometheus. He is more focused on espresso hardware, which is a topic that doesn’t really interest me that much, but I still find his videos interesting.

The paper is linked in the reference section at the bottom :) Direct link: https://www.nature.com/articles/s41586-023-06668-3

Edit: Actually, I thought about it, and I don’t think clang’s behavior is wrong in the examples he cites. Basically, you’re using an uninitialized variable, and choosing to use compiler settings which make that legal, and the compiler is saying “Okay, you didn’t give me a value for this variable, so I’m just going to pick one that’s convenient for me and do my optimizations according to the value I picked.” Is that the best thing for it to do? Maybe not; it certainly violates the principle of least surprise. But, it’s hard for me to say it’s the compiler’s fault that you constructed a program that does something surprising when uninitialized variables you’re using happen to have certain values.

You got it correct in this edit. But the important part is that gcc will also do this, and they both are kinda expected to do so. The article cites some standard committee discussions: somebody suggested ensuring that signed integer overflow in C++20 will not UB, and the committee decided against it. Also, somebody suggested not allowing to optimize out the infinite loops like 13 years ago, and then the committee decided that it should be allowed. Therefore, these optimisations are clearly seen as features.

And these are not theoretical issues by any means, there has been this vulnerability in the kernel for instance: https://lwn.net/Articles/342330/ which happened because the compiler just removed a null pointer check.