Hacker Newsnew | past | comments | ask | show | jobs | submit | zrm's commentslogin

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.


If you are writing to it before reading from it then it's not uninitialised, and in 99% of cases the compiler can see that and will not set it to 0 at its declaration because that's a dead store.

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.


> 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.


I don't dispute the beneficial OPSEC here but it does nothing to reduce the burden.

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.


Simple but less culturally sensitive solution: English is the linga franca so tell them to either romanize their company name or come up with a brand name using latin characters.

삼성전자 can be written as Samseong jeonja in latin characters and translated literally as Tristar Electronics but they do business as samsung.com

I think it's cool that we figured out a way to encode CJK and other foreign script into ASCII-only domain names but if there's a serious concern about opening yourself to domain spoofing because someone picked the wrong encoding, just use ASCII characters.


"Juárez" can be done with ASCII tho


> "Juárez" can be done with ASCII tho

No it can't? Are you thinking of ISO-8859-1 or Windows codepage 1252 maybe?


Do you sell to Korea? If so, ask the Korea team. If not, don't allow 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.


I assume this oracle will be behind 20 layers of anti-bot protection, CAPTCHAs and hardware attestation challenged. It will be incredibly painful to use. It won't stop the motivated attackers, but will make it too annoying for the average person.


When all else fails, you can hire a lot of folks cheaply to effectively Mechanical Turk it with their home internet connections.


> it says the same thing

Reference needed? I think it remains to be proven whether those detectors can be considered deterministic.


Good lord, just write the thing.


They could (..and probably will..) store that version and then refuse the check if this attack is detected, i.e. the version is too close to a known LLM output.

Alternatively they could also just keep saying "yes" if it's close enough to a version that was close enough.. Although that would enable the attack to allow arbitrary text to be "proven" AI, by slowly morphing close-enough generated material to the desired text. But perhaps this is not a problem they are not concerned with.

To satisfy the letter of the law I expect it's enough to just provide the oracle, without any mitigations.


> 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?


It's wild how much more expensive they are in the US compared to Europe.


US customers have much higher budgets (startup funding) and create much more hassle (wars, tariffs, overall humiliation) than European customers. It's a bold decision but they are apparently seeing a lot of demand and I'd say let the American customers pay for the costs they are causing. Call it symbolic "freedom fee" and they're happy about it.


Salaries


My recollection is that Hetzner own all they DC in .de, self built, land incl. however .us and .sg are standard DC colo/rack


> 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.


Yep. For a router.

I didn't say that I thought it was right, or fair, or just. I didn't say I liked it, or that I agree with it.

In fact, I think it's a pretty ugly state of affairs when a person in an area of poor connectivity needs to climb the hill/go into town/otherwise make plans before they can get their shiny new router to work.

I can accept that things are the way they are, or I can pretend that they're different.

Acceptance seems to be a lot more honest.


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.


> You made the claim that companies require apps because it has lower friction for ordinary users.

I did not.

> That claim is in error.

My motivation to further discuss a hallucination is insignificant.


> 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?


I meant precisely what I wrote, and not a single word more nor less.

> implied

Any implied meanings are your own creations, not mine.

I assure you that if I had meant something different than what I wrote, then I would have written something different instead.

I'm not shy.

Be well.


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.


> If it's AI slop, you keep the evaluation fee.

The number of problems this creates absolutely isn't worth it.

You've traded higher barrier of entry for a PR nightmare when someone publicly complains that you ate their legit submission fee as a money grabber.


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


Agreed, but that's a way easier line to defend than AI vs Human. The amount of subjectiveness human-ai discussion .... well we can't tell anymore.


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.


This might work but only if the evaluations are done through a trusted third party entity where none of the money ever reaches the company you're submitting to.


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.


Weird argument. You're trusting they will pay the bounty if it's a real bug, why not trust they will refund the fee?


Building trust is the hard part, which is why you aggregate all that trust into an entity that everyone else is verifying as trustworthy.


In this case, who is that entity?


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.


Yes exactly but you do not go far enough with your plans. What is the point of any game if we can not determine who has memorised the meta best and who’s fingers twitch fastest. We need to out law general purpose computing in society and first it must be slowly phased out. Humans have shown they can not be trusted with open platforms they will always cheat and scam each other to gain an advantage. We will also need eye tracking devices to determine if they are cheating by reading notes off paper nearby. I think your plan comes to perfection if we chip everyone in case someone else plays for them on the locked down device.


They can block traffic to update servers so the computers behind the router aren't all patched up, then exploit them. They also get access to all the IoT devices on the internal network. They can also use your router as a proxy so their scraping/attack traffic comes from your IP address instead of theirs.

It's definitely bad.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: