zrm

Consider this (quite common) code:

  char buffer[LARGE_SIZE];
  if(maybe_fill_buffer(buffer, sizeof(buffer))) {
      use_result(buffer);
  }

The function maybe_fill_buffer() is an external library function that either fills the buffer and returns true or doesn't access it and returns false. Or maybe it unconditionally fills it, or unconditionally returns false without reading from it. The compiler can't see any of that though because it's in an external library. For all it knows that function is going to read from it instead of writing to it.

Notice that if it could actually figure it out 99% of the time then it could also emit a warning the 1% of the time that it can't and encourage you to make an explicit choice, which would have been a better option if that was actually the rate.

That's assuming you were reading it without writing to it. There are three common cases when that isn't true.

The first is that you have a fixed buffer large enough for the maximum message size even though the typical ones aren't that big. You most often write 1% of the buffer and read it back, the other 99% is never accessed.

The second is that you always write the entire contents before reading it but the compiler may not be able to see that.

And the third is that you have a code path where that variable is simply not used.

You would then have the compiler emitting instructions to write zeros that are either overwritten before being read or are never read at all.

Moreover, zero initializing the data doesn't actually remove the bugs when that isn't the case. Consider the first case when you mess up. You have a fixed buffer used to store variable length messages. For the first message the buffer is now zeros instead of uninitialized, but for every subsequent message the remainder of the buffer still contains the remainder of the previous message and subjects you to information disclosure or data modification if you're reading back a different amount than was written in the associated call.

Now consider the second or third case. You unintentionally read from a variable before assigning to it. You get zeros instead of uninitialized memory, but if you weren't expecting zeros, well, the UID field is now 0.

> the more features you add to the burner phone, the more it begins to look like the device you're leaving "safe" at home.

Wouldn't a sensible way to do this be to create an encrypted backup of your device on a VPS, then restore it to the "burner phone" once you're on the other side of the border, and wipe the device again before you come back?

The idea being that whenever you're at the border crossing, the device contains nothing, and the passphrase for the backup is in your head.

How does the customer service rep tell that a name with some Unicode gubbins is an attack rather than a customer from Juárez or 서울? Having a busy hand copy and paste the attacker-provided string into the system doesn't get you out of it.

> Any stenographic system that you have the code for can be trivially defeated.

They're giving you an oracle regardless, which is almost as good. Take LLM output, make some modification, ask the detector if it's LLM output, repeat until you learn what kind of changes you have to make to defeat it.

Or don't even bother learning what to do, just make arbitrary changes until it says it's not, so when the person they're submitting to does the same check it says the same thing.

> we're approaching a time where a single processor has hundreds of threads

Approaching? EPYC 9996 has 512 threads. EPYC 9754 had 256 threads three years ago.

It seems like what's missing here is lower cost plans, because the existing plans had been fairly affordable, but now they're basically triple.

The least expensive one seems to be CPX11, old price $6.99, new price $20.49. That's 2GB RAM, 40GB SSD. RAM and SSD are now much more expensive, fair enough, but maybe I don't need all that for my mostly-idle VM, so then where's the plan with ~0.67GB RAM and ~13GB SSD for the old price?

> I did not.

This is the exact quote:

> And at least for connected devices at home, a dedicated app can have lower friction for initial setup for the "I'm not a computer person" crowd than other alternatives do.

What good does it do you to dispute that you implied it as a justification for the status quo when your error is contained in the part you're not disputing?

You made the claim that companies require apps because it has lower friction for ordinary users. That claim is in error.

The implication that there is nothing anyone can do to improve the existing state of affairs is also incorrect.

> And at least for connected devices at home, a dedicated app can have lower friction for initial setup for the "I'm not a computer person" crowd than other alternatives do.

For a router? This is the device that you will often not have internet access with which to download an app until after it's configured. Many people have wired internet specifically because they live somewhere with poor cellular reception. Meanwhile the device can give out DHCP and use the standard captive portal mechanisms to automatically direct any client device to its configuration page.

You only need things like that for non-iterated games. A company that gets a reputation for keeping the money when it's a real bug would stop getting real bug reports.

You don't have to determine if it's an AI or not. If AI finds a real bug then it can get the bounty. If a human pays to make you read artisanal hand-crafted word salad then they don't get a refund. Real bugs get the bounty, imaginary bugs pay the fee.

Bounties already have that whenever you reject one for being nothing.

Just require people submitting a bounty to post an evaluation fee. If it's a real bug they get a refund and the bounty. If it's AI slop, you keep the evaluation fee.

It seems like what this needs is the return of video arcades.

Fill a room at the mall with Linux boxen with midrange GPUs and fiber internet and the sort of keyboards you can clean with pressurized water. Charge an entry fee and then sell pizza, cheetos, coffee, soda and beer. Open at 11AM and close at sunrise.

Then publish the public IPs used by the arcade-owned machines at each location in the chain and use different public IPs for the customer WiFi. No DRM nonsense, just a way to know you're playing with someone at the arcade where the management doesn't allow cheats on their machines.