Retr0id

In a hypothetical world where using TLS was abnormal, you could monitor the content of whatever the bots are doing for suspicious activity. And if they chose to use TLS anyway, the mere presence of of TLS could be considered suspicious.

Back in the real world, you can also passively fingerprint TLS handshakes to characterise the client device. Most of these proxy networks masquerade as "normal" clients, but if the type and variety of device fingerprints for an IP suddenly changes, that's a signal too.

Until DoH and ECH are commonplace, DNS lookups and SNI probably leak enough for statistical analysis.

Are you suggesting that the placebo effect applies retroactively? I'd been using creatine for months before I even heard there were conversations about supposed cognitive effects (and I hadn't noticed any myself, either, and I continue to not notice any. That isn't why I take it.)

I wasn't expecting creatine to have any bearing on my emotional state in the first place, so I'm not sure how that would work.

Personally I take creatine for entirely non-cognitive reasons, so it's reassuring to know it's probably not making me any dumber.

Hydration is important so I'm with you on the first half, but what is the proposed link between reduced creatine intake and emotional wellbeing?

It's not something I track, but if it is making me thirstier then that sounds like another useful benefit.

I take my creatine with as little volume of water as possible, probably less than 50ml. I doubt that 50ml is having much impact on my overall hydration.

If you're being academically rigorous about it, sure, but I think it's fine as an informal conclusion.

afaict, the main advantages of buying things with crypto are (potentially) lower transaction fees and latencies, and less red tape restricting who can buy what from whom. If you use a "tradfi onramp", doesn't it negate all of that? Why not just use tradfi all the way, for that transaction?

"Open as in wallet"

You don't need to be a nation state to defeat this even if it's set up "properly", you can use low-cost interposer attacks like https://batteringram.eu/ to alias the guest's memory into another guest that you control.

Modern hardware tries not expose bad sectors to the filesystem layer at all, they are managed by the drive firmware (transparently remapped, until the drive runs out of spare sectors). Thus, you will ~never see bad sectors marked in the FAT on modern hardware.

The "machine" in question is my brain (or at least, the part of it that parses grammar).

Works on my machine. (Even though HN's filters removed the leading "How")

Cloud storage is practically the default these days, and most users have no clue where their files are.

More like if you resold tickets that turned out not to be valid, at the ticket gate. At scale.

So in other words, you're screwed?

How do you prevent sellers from fraudulently selling future capacity they don't actually have?

You need the wear levelling system for actual wear leveling, otherwise the drive won't last very long. Competent forensic analysis can check the firmware and the physical flash contents, although most forensic analysis is not especially competent.

It seems like things are fairly amicable between OAI and HF, but what if they weren't? I'd love to see this kind of thing go to court. Who is responsible for the crimes of a "rogue" agent? How will they be punished? In this case it's unambiguous that OpenAI is the responsible party, but I can imagine a lot of adjacent scenarios where it's less obvious. And, where the impacts are much greater.

It does, but it's extremely unusual for the feature to be in use on modern hardware.

I thought of a much simpler approach though. Personally, it's completely normal for my USB drives to contain some OS installer dd'd to the first few GB, and to be wiped with urandom between uses. The installer .iso is typically immutable and will never expand beyond its initial size. Rather than mess around with block mappings, I can just use last n GB as a hidden storage volume. dm-crypt "plain" mode is headerless and can be configured to start from some offset within the underlying block device.

The only giveaway here might be forensic examination of the drive's internal wear-leveling data.

There are other issues with AES-CTR - an attacker can flip bits at chosen offsets in the plaintext without knowing the key. For example, if they know (or can guess/infer) what offset the relevant portion of the `sudo` binary is at, they could flip the branch instruction responsible for password checking. This can be done in one step, as opposed to the multi-step plaintext recovery attack described in the article.

With XTS, the attacker is forced to completely garble a whole block at a time.

If you're using off-the-shelf "hidden" encrypted volume schemes, you're not going to be evading state-level adversaries;

I kinda assumed this was a solved problem now, up to the information-theoretic limit. Just create a FAT32 fs (for example), put some boring decoy files on it, and then unmount it. Traverse the FAT to map which blocks are in-use vs not-in-use, and use the not-in-use ones to store your encrypted data in some arbitrary header-free indistinguishable-from-random format. The result should look just like someone had set up a FAT filesystem on top of a securely erased drive.

If anyone ever mounts and subsequently writes to the FAT volume they'll clobber your data - oh well.

The remaining issue is that you need some special software on the host to mount the hidden volume, which itself raises suspicions. This could be solved by bundling it with OSes by default.

Editorialised title?

That's not the point being made.

I was expecting this to be a study of extensions being repurposed as malware or something, instead it's about... not much.

I stopped as soon as the thumbnail, "baseline drift" was the giveaway.

We even have proper video codecs like h264!

I did something very similar with progressive (adam7 interlaced) PNG: https://www.da.vidbuchanan.co.uk/adamation/image.png

so playback is entirely dependent on network delay

Ultimately true, but I set up my server to send each "frame" separately, with a fixed delay between each. Each frame is small so unless your network is unusually slow, the timing is set by my server.