CyberShadow

Thank you for posting that link. The last time I checked, they were asking to install their app and then unlist yourself from there.

Mysterious person in a hat and trench coat.

Perfect.

I tried doing something similar for another game (fully explore and dump the dialogue tree of VA-11 Hall-A), and also encountered the state explosion problem. What helped was a data structure which allows storing very large sets of states, storing all possible outcomes of a program's execution efficiently (or at least more efficiently than naively). It exploits that any particular step in a program's execution reads and writes only a limited set of variables, which means that we can execute that step once only for each set of values the read variables may have, passing through all possibilities for the values of the remaining variables in one go. Perhaps it could be useful here as well.

https://steamcommunity.com/sharedfiles/filedetails/?id=22411...

> In a case like Worms where there are concurrent actions and random reveal choices inside each turn... If some deterministic state and random number is created for each player at the start of the turn, then their inputs can be reproducibly mapped to the results of all the random choices. In that case you can just upload the inputs and let the server work out what happened based on the hash the player was given (i.e., let the server replay each player's inputs against that hash and figure out the result).

No, this is the worst of the two cases: it allows predicting all outcomes at the start of the turn AND allows manipulating the outcome. So, in a territory control scheme like Team17, you can choose whether to pick up that crate now, or wait a turn or two until picking it up will result in a better outcome.

> But the server is not another player. It's not a player at all. It's the arbiter of truth.

No, that's not how peer-to-peer games work. In the current implementation, it is the "arbiter of truth" because it's the "server" in the TCP/IP sense, but it is still run and controlled by a player, and should not have any intrinsic advantage.

> At some point games will just accept this and allow the player with too slow of a connection to be disadvantaged.

Maybe games with a centralized networking model. We deliberately avoided doing anything in this direction for Worms Armageddon because it puts a death clock on the game and the community - see all games which are no longer playable because the developer/publisher decided that keeping the servers online was no longer profitable.

> To the extent that a server should tolerate slow connections, it is a handicap given by the game to players with slow connections.

In the hypothetical secure scheme I described above, ALL players are affected, not just the slowest one.

This extension is closed-source and its code is obfuscated. It also phones home according to the Firefox permissions. I'm not sure I would trust it.

Edit: more information in the HN announcement: https://news.ycombinator.com/item?id=26590720

> They connect by default with aptX (A2DP mode) but using KDE tray icon, I can easily change it to full-duplex headset mode with mSBC.

As of wireplumber 0.4.8, they will now automatically switch to the headset profile when an application begins recording audio! It's now almost seamless (though I do still need to manually select the audio device every time in Firefox).

You will generally want the outcome to be actually verifiable to everyone, not just the immediate participants.

> I'm not sure I understand why there'd ever need to be an instant result (sans network latency) in a turn-based game. If the player has a visual indication that the server is waiting for their command, then any jumpy movement on the part of other players is strictly down to their own bad connection as long as the server is running well.

Although the Worms games are turn-based, gameplay typically involves performing a lot of actions within one turn. Walking, jumping, using utilities (which don't end your turn), and finally firing a weapon. Many of these actions can trigger an event with a random outcome, which should ideally be unpredictable and un-manipulatable, such as which weapon will be found in a weapon crate, or how long the fuse of a mine with a random fuse will be.

In a peer-to-peer game, the server is just another player, and should not be considered intrinsically more trustworthy. Ignoring latency, it's possible to implement a scheme of securely generating random data, in which everyone produces a verifiable hash (commitment) of a random number, and after everyone announced their hash everyone announces their random number, which is then XORed together to produce the outcome (see e.g. Keybase's "Cryptographic coin flipping"). The problem with this approach is that the latency to obtain the result becomes the roundtrip to the player with the slowest connection and back.

The second-generation Worms games (2, Armageddon, WWP) use the same approach (here called "Deterministic action propagation method"). It was implemented by Karl Morton, and we also use it for replay files (which is why the game logic is meticulously versioned).

The solution we used for managing secret state, when the state is from a random source, is to delay generating the secret information for as long as possible (so, e.g., if a card is drawn, the drawn card is decided at that moment, as opposed to pre-shuffling the deck at the start of the game). We experimented with some designs in which the secret is revealed only to the player who owns it, and the rest only see a verifiable hash of the secret until the player performs an action which reveals the secret; however, it doesn't solve the general problem that any time the game must immediately (without network latency) make a random choice, the design must compromise between either allowing a hacked client to predict the result (when the RNG output is stable) or manipulate it (when the RNG output changes very often, e.g. every frame).

Sadly, the newer games went for a simpler synchronization algorithm, in which if a discrepancy is detected, the entire state is simply copied over from one player's game to another. This does allow blatant cheating; I'm guessing it was a concession due to the new engine lacking in robustness or portability.

May I suggest placing it in a <details> tag. I'm finding it difficult to pay attention to anything on the page when there's a constantly blinking animation on it.

> It helps people that don't know that you can watch to subscribe for updates.

How would one fairly decide which project READMEs should have such an animation, and which shouldn't? It certainly calls a lot of attention to itself.

What's with the "star and watch" animated GIF in the README? Should I start putting one in all my repositories? Should everyone be doing that as well?

Hey, you forgot to put this in the title: "written in Rust" :-)

This looks nice, though I looked through my command history of "watch" and couldn't find any use cases where hwatch would be more useful. Am I using it wrong?

What is "LTD"?

Have a look at Linux Deploy, it is essentially an installation wizard and launcher.

I no longer use it, and instead use Magisk startup scripts to start the Linux userspace, but it remains useful as an installer.

I found it to be true in most cases, and when it is not... well, we can vote with our wallet.

Case in point: I had never heard about Onyx. Coincidence or causation?

Since Android uses the Linux kernel, if you have full access to the device, you can already generally sideload a distribution of your choice onto the filesystem. The Linux userspace can run and coexist alongside the Android userspace. Though some applications may require kernel features which are not enabled in typical Android kernels, GPL forces manufacturers to release the kernel source code, which makes it fairly easy to enable more features and use that kernel.

The advantage of this approach over running Linux in a sandbox / VM is that you can administer your Android device from the Linux side, which means that you can use your existing backup strategy or other automation tools. With a USB/bluetooth keyboard, it can also work as a small PC in your pocket.

That's a cool find.

On a practical note, at the top level or in the middle of progn-like constructs, you can do "block comments" with just:

'( ... )

I.e., quote the form to prevent evaluating it.

(2017)

More impressive: manipulating strings at compile-time.

Even more impressive: using string manipulation at compile-time to build valid D code, then use string mixins to inject it into the current program, passing it on to the compiler to be compiled as part of the program being built. This is done by std.regex to compile regular expressions to native code during compilation.

Even further impressive: using a string import to read a DSL from disk, transpiling it into D code, and passing it on to the compiler. This is used by Vibe.d to compile HTML templates to native code.

Granted, all this is fairly old news, and a few other languages have since caught up.

Have you tried GitHub Discussions? They even have a Q&A mode for your own mini StackOverflow.

Discourse isn't all that bad with JavaScript disabled.

How is dang not there?

https://news.ycombinator.com/user?id=dang

It looks like they should be in 85th place?

I think XConvertSelection would be more effective. Applications which use the XFixes extension to receive notifications of new owners won't need to use XGetSelectionOwner.

> but for some reason it doesn't seem like the right approach.

The approach being used in containerization is namespaces. You can put new processes into a new IPC / user / PID / network / time / etc. namespace, which isolates them from the parent namespace. Once that's done and you can't mess with other processes via the filesystem / kernel, the remaining hole is servers with inadequate security models, such as X11.

I think the goal here is to be notified when an application accesses the clipboard, not modifies it. You need to be the owner to do that (excluding some system-wide hack like patching the X server or MITM-ing all X11 connections).

I am not familiar with bpftrace (though that does look extremely potent), but XSetSelectionOwner is called when an application wants to make data available via the clipboard, not access it. Also not sure if that would also catch stuff with Xlib, and I guess it won't if it's statically linked (this is why I pivoted hax11 from hooking library calls to MITM-ing the connection).

The protocol actually allows for applications to request the clipboard data to be delivered to someone else's window. I haven't tried it, but I think it would work.

> Which distributions and which settings are you talking about?

kernel.yama.ptrace_scope = 1

> If you can run gdb on that distribution, then you can definitely do it, even if it's just because they whitelist gdb in selinux/aa (in which case you can just script gdb).

No, you can't. Try it.

> And I rather doubt it is a default, since ptrace-based sandboxing is a thing (even Firefox was using it).

You can trace child processes, but not any other process.

> If these programs want to spy on each other's memory contents, they already can.

No, they cannot. As an unprivileged process, you cannot access other processes' memory, with major distributions' default settings, even if the two processes share the same UID. The only way to achieve that would be to modify some execution path (e.g. .bashrc) to launch an evil wrapper which runs the target process in a way that allows reading its memory.

This is why distributions are moving towards Wayland and container-izing most applications; this allows each application to be in its own sandbox with no capability of interacting with other applications without the user/system's explicit consent.

Let's see where this goes:

https://github.com/virt-manager/virt-manager/issues/358

Edit: found this, so maybe Red Hat considers this a feature which is working by design: https://github.com/virt-manager/virt-manager/pull/166