I imagine the second attack may be mitigated by the fact that the publisher might be easier to hide than with direct access. E.g., if your dead man's switch were just some daemon running on a machine somewhere that you have to ping periodically, attackers could find the IP address of the daemon by watching your network traffic.

In the OP, you and the daemon (aka the trusted publisher) communicate exclusively via the blockchain, so it will be a lot more difficult to find the daemon's location.

Not sure if this is in any way better than just accessing the daemon through Tor though.

These are valid points and anyone thinking about using killcord should be aware of these.

As for the second attack vector, the publisher is built with idempotence, so it is important that a killcord owner configures n-number of publishers in geographically diverse areas to mitigate the false negative attack vector.

Oh, cool, this would actually help protect against a lot of things!

If you can set up a deadman's switch and there's no way to figure out who it belongs to, that should make it significantly harder to find out which publisher to attack.

Contrast that against 'every day at 5, I publish a signed checkin to Facebook, Twitter, Reddit, Dropbox, my blog, and a hundred other sites simultaneously.'

In that scenario, blocking or faking the trigger isn't the attack vector. The attack vector is that it's really obvious who the trigger belongs to, so to find the publishing IP an attacker can just monitor who connects to those domains.

I guess the trick is actually getting Ether anonymously, but that's not the hardest problem in the world to solve.

No, the message sending system still needs to actually send the message to the network at some point, which gives away the sender’s IP.

You can achieve the same with tor hidden service.