chrisvls

PHP’s view is that Chaingiard started the clock because the video was insufficiently detailed. Not sure if that is the case, but just sharing I had a different reading of the statement.

I’d say getting called out like this is a consequence.

As someone with experience in this field (and plenty of skepticism of geographic association studies), I find the article lacking. Is there a technical write-up?

It is quite odd that the authors say that they don’t know if the original method can yield negative results. Some of the results are expressed as relative risk, so there’s a numerator and denominator. That should be enough to begin to work it out, since all possible exclusive numerators sum to the denominator. It feels like if you don’t understand whether some areas will be lower than average, then perhaps you don’t understand the method sufficiently.

It sounds like they reverse engineered the original method, but that means they could be applying an overfit model and getting spurious results that the original wouldn’t give.

That’s all speculation, hence we need the technical write up.

I am really interested in this topic, but man I had to give up reading the document because there were too many paragraphs that contained lots of words but no additional detail that I could actually use. It could be AI-generated or human-generated with too many buzzwords. Doesn't really matter, still gave up.

"a circuit board which definitely was not from 1877" ;)

Yes, I think this is an anti-pattern is similar to the one I often see, basically getting the order wrong like this:

1. Define the problem.

2. Gather information about the problem.

This seems reasonable. "We need to know what we're trying to solve, not boil the ocean."

But it is really common that the information tells us that the problem definition is slightly or really wrong. Hence the importance of gather information, then define the problem... and iterate.

"First define the problem" also feels reasonable because picking the right problem requires a lot of context and experience. Some would add "taste." So in group discussions, people often suggest bad problem definitions. Others then want to get focus and traction. That impatience often results in committing too early to the problem definition.

It’s possible there are a lot more PRs about chiropractic apps…

“I will deal with issue by ignoring it”

So love that, wish could use it more often…

Sadly, the real lesson we need to learn from Battlestar Galactica is not this. They weren't saved by old software, they were saved by not having critical systems on the network unnecessarily.

Our water and power utilities need to re-watch the pilot.

Not really practical for custom work.

Hmmm, i was looking more at the description of what appeared to be network level isolation in the original paper…

The original ExploitGym used network-layer isolation. OpenAI downgraded that to trusting the repository server's settings. Giving the agent that kind of attack surface seems like a pretty foreseeable problem. I don't think it was intentional, but it's not a stretch to say that they aren't good enough at this job.

What is astonishing to me is how little attention is given to the difference between the original, university-developed ExploitGym and the OpenAI environment. In ExploitGym, the sandbox was enforced by a network-layer policy. OpenAI downgraded that to trusting the repository server's settings. That's a foreseeable problem. Then to actually see the agents exploit it and still not upgrade the isolation to basic best practice? When the best practice was actually listed in the original benchmark and you changed it?