When I was a graduate student at University of Chicago, the University's private police force was the third largest police force in Illinois, after the cities of Chicago and Springfield. That may still be the case. The University police patrolled the Hyde Park neighborhood of Chicago in which the University is situated. Hyde Park is surrounded on three sides by high-crime neighborhoods, and on the east by a park along the shore of Lake Michigan, but it was safe to walk the streets of Hyde Park at all hours of the day or night. University police patrol cars could constantly be seen cruising slowly up and down every street. In those days before cell phones were popular, you could walk up any street almost without ever taking your hand off an emergency call box. When I first visited Hyde Park for my interview, I remember being told the exact boundaries of where it was safe to walk. That included things like "make sure to walk only along the south side of 47th Street, never along the north side of the street."

Maybe it's finally time to graduate to lftp?

Using the type system to achieve finer-grained control of capabilities is certainly a good idea. But some Haskell experts have commented on the Haskell reddit that the right way to do that is to use the classic monad transformers. This "new" approach is actually just a re-hash of an older approach that actually doesn't really work well. See this comment for more details.

They can only do that if they have your key. If you use their web interface to generate your key, or to send and read email, then they can be forced to decrypt your email. But if you generate your key yourself and use it to encrypt and decrypt locally, your are fine.

I think that's a little harsh. They're doing the best they can, and they are being very honest about the inherent limitations.

If you don't use their web interface at all - neither to generate your key nor to send and read mail - then that's not a problem.

At this moment IXWebhosting DNS is available again. Their status blog is here. They report that they there might continue to be "a few intermittent issues".

Cut it way down in size and submit again.

My understanding of Hetzner's report is that it works like this: there is a backdoor on a Nagios server (not clear whether that means a backdoor in Nagios itself, or some other kind of backdoor on a server whose purpose is Nagios monitoring). The attackers are able to use this backdoor to gain root on other servers within Hetzner, which they use to modify key daemons on those servers. The daemons are modified in memory as they run, and I'm sure the attackers are careful not to generate any logging events. So nothing at all is touched on disk for the servers being attacked. Nothing.

The backdoor on the Nagios server probably does persist across reboots. However, that also may be something that is remote in origin. For example, perhaps the backdoor is hidden in the Perl code of some Nagios module which is regularly updated by Hetzner (and probably plenty of other data centers) from some remote repository which the attackers have compomised. There doesn't even need to be any trace of the backdoor on the Nagios server most of the time. It only needs to be present for a few seconds every once in a while, say, once every few weeks, because the daemons it attacks are long-running processes.

Oh, you're right. There you go then.

Actually, no. It's in the design, the features, and the source code.

Will you be the first one to try flying one of these things? Oh no, don't look at me. No way.