Right, except the researchers are the ones that added the button, pressed it and now are upset at Ford, in your example.
GitHub agents don’t have access to unrelated private repos by default, nor respond to public issue comments by default. The researchers manually configured the agent to have access to unrelated private repos and also process untrusted public comments.
How is this a Github vulnerability? The researchers are the ones that grant the agent access to private repos and then ask it to answer questions in public repos.. of course this allows extracting private information?
This is like setting up a normal CI job with access to secrets and running it on public PRs. If you configure GitHub to allow public code or LLM instructions to run in contexts that have access to sensitive things, they will leak; that’s not GitHub’s fault, it’s yours.
There are attacks that allow dumping RAM if the device is powered on though and you have physical access. Depending on config it may be very easy (just plug in a dumper over Thunderbolt on USB C and do direct memory access) or hard (freeze and swap physical RAM to an unlocked machine).. but the idea was defense-in-depth here; a well configured device should both be hard to dump RAM on and it should not give encryption keys if an attacker succeeds.
I’ve had very good success in similar setups where you have some sort of “oracle” and can generate enormous corpuses of test data, such that you really, really trust the LLM code must work for the inputs you expect it’ll ever need to handle.
Makes me think of all the algorithms we specify in proof languages and then hand-implement in production languages - this setup could maybe let you just specify the proof of an algorithm and then let LLMs derive efficient implementations with the (slow) proof as an oracle
The point of “durable” implying stored to durable media is precisely that it allows the operator of the system to make that kind of calculation. They know the disks they picked and the replication chosen, and as long as the database calls fsync, their calculations will work.
My beef is with database systems that use the argument you made further up thread to skip fsync to juice their performance numbers. Data is not “durable” if turning off the machines storing it means it’s lost, that’s a category difference, not a pure probability difference as you are claiming.
It is of course totally fine to not store data to durable media and say the risk of devops doing a coordinated reboot is as low as the risk of raid disk data loss, but then don’t use the word “durable”.
I used to say this as well but like.. industry has, for a long time now equated “durable” with “stored on disk”. Any DBA will assume that’s what it means, and use that fact when they work out the replication they need either in clustering or in raid.
If you’re building a data storage system and are using the term “durable” to mean “it’s in RAM on three virtual machines”, for example, I don’t think it’s unfair to say that you are lying to your customers, because you are intentionally misusing a well-established term.
If a company says “encrypted at rest” that is generally compliance-speak for “not encrypted, but the hard drive partition is encrypted”.
Various certifications require this, I guess because they were written before hyper scalers and the assumed attack vector was that someone would literally steal a hard drive.
A running machine is not “at rest”, just like you can read files on your encrypted Mac HDD, the running program has decrypted access to the hard drive.
I feel like I’ve seen elsewhere that the argument there is that you often must have this optimisation working in algos that rely on it or you will get stack overflows. Having a keyword to force it then becomes a very useful thing, vs relying on hopes that future compiler versions and different arch targets will all discover the optimisation opportunity.
Utility solar is cheaper in studies that do not factor in the cost of distribution, but the picture is much less clear when total system cost is considered - not having to pay for expanded distribution grids or new interconnects is a major benefit of residential production.
As for the last part not being true, can you clarify? The majority of the earths population lives between the 20th and 40th latitude, the band around the earth approximately between Madrid and the Sahara desert. Sure you can’t run a poorly insulated home in northern Michigan on solar year around without considerable expense, but that’s nowhere near where the majority of humanity lives.
No reason to be rude or hyperbolic - I agree with you that cars destroy communities and we should strive to reduce the need for cars and parking.
For solar powered homes specifically though, multi-story buildings are much harder to run solar powered from the simple ratios - even if you reduce energy use 75%, at 4 stories you are break-even in roof-ratio-to-energy-need. I’ve worked in this space a while, and it’s now pretty straight forward to run single-family homes 24/7/367 on solar in most of the world, but multi story buildings are much harder.
Respectfully, 30kWh is not much in this context. In 10 years every modern 2-car home will have 200kWh on the driveway just from the EVs; add a 100kWh whole home battery at a price point close to a 10kWh battery today and the calculus changes in most of the world.
The cost of materials going into modern batteries easily leaves room for another 10x reduction in price, IMO where this all is heading is obvious. Zero marginal cost will win every day of the week.
FWIW we run our cabin on 15kWh battery today year around, though we do run a small wood stove to supplant the heat pump on cold winter days.
Fooled by Randomness talks a good bit about this, and argues it’s true - except you don’t know what to bet on. Hence the outlier successes will be from extreme risk takers, and for each such person there will be 1,000s of other gamblers that bet on the wrong thing.
Taleb does the math as well IIRC, assuming there are x hundred thousand extreme risk takers, and outlier “correct bets” are y% chance, then you will have a surprisingly high number of people with a long series of “correct” bets behind them looking like business geniuses, from pure chance & basic statistics.
This was really good, and second leaning on property testing. I’ve had really good outcomes from setting up Schemathesis and getting blanket coverage for stuff like “there should be no request you can generate as logged in user A that let’s you do things as or see things that belong to user B”, as well as “there should be no request you can find to any API endpoint that can trigger a 5xx response”
You also need to choose optimal instruction encoding, and you need to understand how relocs work - which things can you resolve now vs which require you to encode info for the linker to fill in once the program is launched, etc etc.
Not sure why I'm on this little micro-rant about this; I'm sure Claude could write a workable assembler. I'm more like.. I've written one assembler and many, many parsers, and the parsers where way simpler, yet this thread is littered with people that seem to think assemblers are just lookup tables from ascii to machine code with a loop slapped on top of them.
I am surprised by the number of comments that say the assembler is trivial - it is admittedly perhaps simpler than some other parts of the compiler chain, but it’s not trivial.
What you are doing is kinda serialising a self-referential graph structure of machine code entries that reference each others addresses, but you don’t know the addresses because the (x86) instructions are variable-length, so you can’t know them until you generate the machine code, chicken-and-egg problem.
Personally I find writing parsers much much simpler than writing assemblers.
I don’t understand this summary - isn’t this a summary of the authors recitation of Masleys position? It’s missing the part that actually matters, the authors position and how it differs from Masley?
lol no, but if you are in a regular vehicle, you can see under the front of the bus as you pass it, it’s a standard safety practice? The first picture of the bus in this random article shows what I mean, you should be checking under the bus ahead of the front wheel as you pass: https://www.nvp.se/2026-01-08/bil-i-sparviddshinder-stoppade...
Aye, and to always look for feet under and by the front wheel of vehicles like that.
Stopped buses similarly, people get off the bus, whip around the front of them and straight into the streets, so many times I’ve spotted someone’s feet under the front before they come around and into the street.
Not to take away from Waymo here, agree with thread sentiment that they seem to have acted exemplary
I previously built virtual power plants at Tibber, databases at Neo4j and fleet management Equipmentshare.
[email protected] https://tech.davis-hansson.com http://github.com/jakewins