Is a state actor behind the XZ backdoor?
34
169
1k
2026
68%
chance

If concrete evidence does not become available resolves PROB to my opinion at close.

Currently I'd put it around 20-30%, mainly due to:

  • clumsy and unnecessarily public exploit implementation (plus interoperability issues) characteristic of somebody without a team able to build a professional test environment and hammer out bugs

  • scope well within a determined individual's reach

  • general lack of corporate feel seen from state actors in the past

I will not trade in this market

Get Ṁ600 play money
Sort by:

I'd love to hear some arguments on the YES side, this seems awfully high, everything I have seen so far fits the "determined individual or small, non-commercial team" hypothesis better

@CodeandSolder it took years to get there, that points me to someone that has a lot of time to spend for potential future gains. State actors are a match for that.

Also, you seem to think that the sloppyness/clumsiness is a point against state actors, I don't really see why that would be the case. I would expect state actor devs to be just as sloppy and clumsy as the next guy.

@Odoacre I don't think so, actually, what state actors are known to be interested in is mechanisms for single targeted attacks right now (think Pegasus, Stuxnet) and vast access to large amounts of data (general NSA scope of work), this kind of general backdoor that will be found sooner or later, especially if they actually use it, doesn't seem to fit nicely into this. Plus in most uses an existing tool like Pegasus would be simpler and way more reliable.

And it's not just sloppiness, it's sloppiness that is avoided by structure and organizational knowledge, by having other people to consult on what you're doing. Look at Stuxnet, infected billions of computers, carried out the task and only got detected because of a literally one in a billion accident, not hanging SSH for half a second.

@Odoacre also, this approach means you either have a backdoor in every governmental system that uses Linux and have to hope you didn't mess up the authorization for it (which it seems the XZ exploit did) or have to somehow create a reason to eliminate it without making anybody suspicious, across all branches of government

Typo in title.

@MichaelWheatley fixed, thanks, feel free to edit yourself in the future

sold Ṁ100 YES

hm, just sold my bet off again because I'm not super into "PROB to my opinion at close" - because I disagree with your opinion ;)

(but it's a fair enough criteria to have, I should've read more carefully first!)

@retr0id I'm open to arguments, PROB is because I don't want it to became "probably will not resolve", especially with the current loans implementation

@retr0id my main argument against it being a state actor (or even an organized software development team) is all the clumsiness that could be eliminated by throwing resources at the project, the .1 version incredibly suspiciously changing the test files, the 5x performance impact on ssh which could for sure be optimized away, the whole thing looks like one person with a lot of time, not a professional team where you can post "the exploit slows down ssh way too much in the automated tests, can somebody clean this up for me while I finish the plugin integration" or "the build pipeline for Debian fails, who's responsible for that" on Slack

Like, this isn't what you get from an institution

bought Ṁ25 NO

@CodeandSolder problem with this setup is that since it's unlikely there will be any evidence, the best thing to do is to just bet market towards the probability you have stated. Maybe resolve to a poll?

@Weezing this setup has worked well in my previous markets, often ending up far from my initial probability, the poll would need to be somewhat selective to be usable, not sure how to achieve that
I expect there to be new evidence (P~60%) and will observe the expert consensus as it forms.

More related questions