From the article:

> They also made mistakes in the fog of war: accidents happened in 86 per cent of the conflicts, with an action escalating higher than the AI intended to, based on its reasoning.

Which I guess is technically true but also seems a bit misleading because it seems to imply the AI made these mistakes but these mistakes are just part of the simulation. The AI chooses an action then there is some chance that a different action will actually be selected instead.

like its similar to connect or socks proxy except it is using SSH as a transport layer instead of TCP as a transport layer and its doing it transparently without having applications to be written to use the proxy. but if you are just converting TCP packets into a datastream and then sending them somewhere else where you convert them back to TCP packets then this is what this TCP RTT strategy is fundamentally meant to detect. i suspect the TCP only RTT thing works because of the delayed ack behaviour of most operating systems and this will still happen with sshuttle unless you are explicitly using quick-ack. also, quick-ack just works around the TCP-RTT issue and not the differences in timing between TCP and TLS or other higher protocols. i think if you are testing for other RTT differences then quick-ack would make them more obvious.

on the server side sshuttle just uses normal tcp sockets and nothing magic (https://github.com/sshuttle/sshuttle/blob/master/sshuttle/ss...)

also, if you have an sshuttle proxy this site cannot detect it may be due to how close the server is to the client. i have a CONNECT based proxy it is able to detect around 5% of the time (maybe only that often due to a bug) but this is because there is probably less than 10ms latency between the proxy and the client and probably around 50ms latency between the proxy and the server for some reason (?).

probably, the push method should return a boolean indicating whether the task could be enqueued and if the capacity is reached then the task is not enqueued. but this is c so its very easy to write buggy code :) also, in this case the caller has no obvious safe way to check whether the queue method is safe to call so the author can't claim its up to the caller to verify some pre-condition before enqueuing a task.

https://github.com/facebook/react/commit/bbed0b0ee64b89353a4...

and it looks like its been squashed with some other stuff to hide it or maybe there are other problems as well.

this pattern appears 4 times and looks like it is reducing the functions that are exposed to the 'whitelist'. i presume the modules have dangerous functions in the prototype chain and clients were able to invoke them.

      -  return moduleExports[metadata.name];
      +  if (hasOwnProperty.call(moduleExports, metadata.name)) {
      +    return moduleExports[metadata.name];
      +  }
      +  return (undefined: any);

The text of the constitution for electing congress says:

> The House of Representatives shall be composed of Members chosen every second Year by the People of the several States

and there is something similar for the Senate after the 17th amendment. I think pre-17th amendment States may have been able to use Sortion to appoint Senators but it would not have been legally enforceable. The State legislature could pre-commit to elect Senators by Sortition but then they could bail out and just decided to choose who they want when it came to the actual selection.