brb taking out a 10:1 bet on a new project which will print money and then rm -rf'ing all the code so i get a payout

If a single engineer can sabotage a project, then the company has bigger things to worry about. There should be backups, or you know, GitHub with branch protection.

Aside from that, perverse incentives are a real problem with these systems, but not an insurmountable one. Everyone on the project should be long on the project, if they don't think it will work, why are they working on it? At the very least, people working on the project should have to disclose their position on the project, and the project lead can decide whether they are invested enough to work on it. Part of the compensation for working on the project could be long bets paid for by the company, you know like how equity options work, except these are way more likely to pay out.

If no one wants to work on a project, the company can adjust the price of the market by betting themselves. Eventually it will be a deal that someone wants to take. And if it's not, then why is the project happening? clearly everyone is willing to stake money that it will fail.

<insert dilbert comic about wally coding himself a yacht>

SSRF is not just a DoS.

To have a significant impact SSRF needs to be combined with a second worse vulnerability: An endpoint that trusts unauthenticated requests just because they come from within the local network. Sadly several popular clouds have such a vulnerability out of the box (metadata endpoint).

Yeah, that's less of a "vulnerability" and more of how I expect 99% of companies to handle authentication within a network (sadly).

I think it would be very cute to train a model exclusively in pre-information age documents, and then try to teach it what a computer is and get it to write some programs. That said, this doesn't look like it's nearly there yet, with the output looking closer to Markov chain than ChatGPT quality.

Amazon Fire Tablet, one of the only things I've ever returned.

100%. Ours has become so inexplicably slow it’s wild, even after factory resets. The Amazon OS experience is also terrible. It sits unused.

Signal is an end-to-end encrypted messaging app. People continue to breathlessly mentioning the lack of database encryption as a problem, but that never made it a real security issue: its job is not, and has never been, dissuading an attacker who has local access to one of the ends, especially because that is an incoherent security boundary (just like the people who were very upset about Signal using the system keyboard which is potentially backdoored - if your phone is compromised, of course someone will be be able to read your Signal messages).

Database encryption isn't comparable to the keyboard drama. Protecting against malware in your keyboard can be done by using a different meyboard and is of course out of scope.

But if my phone gets taken and an exploit is used to get root access on it, I don't want the messages to be readable and there's nothing I can do about it. It's not like I can just use a different storage backend.

It's also a very simple solution - just let me set an encryption password. It's not an open-ended problem like protecting from malware running on the device when you're using it.

If someone has root access to your apparently unencrypted phone, then they can just launch the Signal app directly and it'll decrypt the database for them.

Which is to say this is an incoherent security boundary: you're not encrypting your phone's storage in a meaningful way, but planning to rely on entering a pin number every time you launch Signal to secure it? (Which in turn is also not secure because a pin is not secure without hardware able to enforce lock outs and tamper resistance...which in this scenario you just indicated have been bypassed).

Any modern Android is encrypted at rest, but if your phone is taken after first unlock, they get access to the plaintext storage. That's the attack vector.

A passphrase can be long, not just a short numeric PIN. It can be different from the phone unlock one. It could even be different for different chats.

No one is using an Alpha, Motorola 680x0, PA-RISC, or SuperH computer because that's the only thing they can afford. Rust supports 32bit x86.

They're vulnerable to "High-S" malleable signatures, while ed25519 isn't. No one is claiming they're backdoored (well, some people somewhere probably are), but they do have failure modes that ed25519 doesn't which is the GP's point.

UMass Lowell has a 1MW research reactor as well.

CodeQL compiles to the Souffle datalog engine and I use it for static analysis. I've also used ascent for a few random side projects in Rust which is very convenient.

The human brain is just really bad at evaluating risk, especially over long periods of time. A lot of people are wanted overseas for years or even decades without anything happening, which makes it hard to maintain the mindset of being at risk without falling back to "eh, I've been fine this long"; a lot of them do foreign travel anyway and get away with it, which makes it hard to not fall into "what's one more vacation to a extradition-friendly country".