Hmmm, I’d have to see it. It’s basically the car saying “ooh you’re an MP3 player, play some music!”, and the phone is like, “oh, okay, you’re relaying your owner’s request so I’ll take your word for it”.
Not that I recall and I’m feeling too lazy to look at the moment. It’s really the car’s fault, though. It’s sending the “start playing MP3s” command, which the device is obeying.
Germany spent most of the last two decades shutting down nuclear power plants while blocking renewables because the politicians were sponsored by coal and gas companies.
It's also because they were addicted to Russian gas, and had to spend a fortune to wean themselves off it once the war was raging - though not before giving Russia a lot of gas money for the war - and converting its power plants to use LNG, which it ships in from the USA. That is a mad situation even before Iran.
When you know you're looking for an exploit, it's easily verifiable and you can iterate fairly rapidly and get fast feedback, you can just have a test that you don't get a 403 back or something. LLMs, in general, seem good at problems like this.
When you're developing, there's a ton of degrees of freedom, and security encompasses only some of them. To be sure, if you set up a quickly verifiable test for every security flaw, you could probably get LLMs to satisfy them somehow, but there's a lot of those, and it's not necessarily practical.
They said race conditions and specifically exempted data races. You can absolutely write race conditions in rust, they're a logic bug.
As an example, let's say you have two functions A and B. A only works properly if B has never ran for some reason. Let's say they both accept a reference to a value C, and B changes C's value somehow. Because this is rust, we can't have data races, so we wrap it in an ArcMutex or what have you. That doesn't impact the ordering of A and B at all.
If we spawn threads that execute A and B at the same time, it's up to the scheduler if A functions properly.
Thanks, I think that most people read "data races" and jump to "race conditions in general"
And that is my core complaint - data races are well-understood and preventable now, whether statically via Rust's borrow checker (or pure immutability in functional languages) or dynamically with tools like Go's -race detector.
Logic races remain an application-level problem regardless of language design.
This seems to be that there's just so many degrees of freedom, that there's a pretty reasonable chance on any day that you're in a situation where nobody has been before. Or as PG put it once, my job is to think thoughts nobody has ever had before.
That being said, that doesn't mean the majority of the situations you're in are completely novel, just that there's a reasonable chance of at least one occuring.
You're not wrong, but something can work well enough to still be useful despite falling short of the idea of a proof or any formal definition.
Let's say that 95% of individual humans can pass it and only 2% of bots. For someone maintaining a website, who has to decide between using this system and shutting down their site because of the increased costs, that may very well be good enough
That’s a pragmatic and understandable argument. And for an individual hobbyist site owner, that’s fine. Are we okay with excluding 1 person in 20 from the services of a midsized organization? What if they’re integral to the workplace? Or a major transport provider without differentiated competitors? What if the organization is a state government?
The culture of magic (and nerd-dom in general) has definitely changed, I won't argue that. But when you use an example like this, it kinda undercuts your entire point.
reply