Read that again. We asked to commit without revealing details, he said yes, that's what happened. I guess he changed his mind about that after the fact, but nobody promised not to commit. We didn't "defect" from an embargo unilaterally.

Perhaps "defect" is the wrong word given the circumstances, but the result is the same. There's a good reason for the embargo: this all takes cooperation, as it's not a Nash equilibrium. I still agree with their decision not to include OpenBSD so early in further disclosures, given Theo's short-sighted statement.

> Perhaps "defect" is the wrong word

It's precisely the correct word. Prisoner's dilemma are simple, mathematically. This was one. OpenBSD defected. The joke's on the security researcher, though, since this doesn't appear to have been their first time [1][2].

Robert Axelrod outlined, in his 1984 classic The Evolution of Cooperation [3] four requirements for a successful iterative prisoner's dilemma strategy. One is retaliating. Security researchers are letting OpenBSD play an iterating game as if it's an N=1, i.e. they're not retaliating. Given the community is playing "always cooperate," OpenBSD's best move is actually "always defect".

[1] https://lwn.net/Articles/726585/ thank you 0x0 [a]

[2] https://lwn.net/Articles/726580/ thank you 0x0 [a]

[a] https://news.ycombinator.com/item?id=15481980

[1] https://en.wikipedia.org/wiki/The_Evolution_of_Cooperation

So does the simple mathematical treatment also include language like "the joke's on ____”? Or was that more of a philosophical interpretation of yours?

Real life is messier than any model.

https://www.quantamagazine.org/in-game-theory-no-clear-path-...

Both your [1] and [2] seem to conclude that violating the embargo had no significant ill effects: "since... the underlying issue was already publicly known, OpenBSD's commits don't change things much." If "defecting" causes no problems for the other participants, does it actually count as defecting? (And if not, how is this a mathematically simple prisoner's dilemma?)

Nice analysis. It definitely seems to be the case.

I mean, I agree too. I sleep better not worrying about bugs that can't be fixed.

I'm mostly here just to correct misstatements of facts. You're welcome to your own interpretation, game theory optimization, etc.

Wellll to be fair, I'm sure if the researcher said no, he wouldn't have committed.

From what I've read, I don't see why everyone is giving you a hard time about this. It sounds like you did exactly what he agreed you could do, and then he changed his mind.

Sounds like a "we technically respected the embargo, just not in principle" sort of thing to me.

We're not mind readers. If he says it's ok, we think it's ok. If other vendors have fucked up months long patch cycles, that's their deal, not ours.

Now that it's more clear what role disclosure deadlines play in cooperating with security researchers, it probably makes more sense to just cooperate than point fingers.

What part of this commit description is "not revealing details"? https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_n...

All of it? The paper describing the attack is longer than one sentence.

and this one ? ctrl+f replay https://www.tedunangst.com/flak/post/openbsd-changes-of-note...

He said it's ok this time, but won't be so in the future (pretty clear from the future action). So your decision is still subject to the criticism.

They agreed, but now they regret the decision and wouldn't make it again. To prevent themselves from doing so, they will not speak with OpenBSD until later in the process.

What's the word for pressuring a person until they make a decision they immediately regret?

It's a loss, even if you use openbsd. If you break the embargo, you won't be notified in advance anymore. Basically, you get an advantage once but will get several losses for a very long time. Overall it's bad, even for OpenBSD users.