Hacker News: zzril

New comment by zzril in "GitLost: We Tricked GitHub's AI Agent into Leaking Private Repos"

zzril — Wed, 08 Jul 2026 08:37:26 +0000

Guardrails are essentially part of the input. Saying "but we have guardrails" is like saying "but we do trust part of the input".

Either way, even if you trust 100% of the input, there is actually no way to guarantee that you can trust the output of the LLM. (Which, I guess, is also true for every dependency you pull in. But for those, you at least have ways to audit them.)

New comment by zzril in "GitLost: We Tricked GitHub's AI Agent into Leaking Private Repos"

zzril — Wed, 08 Jul 2026 07:48:27 +0000

> In most agentic prompt injection attacks, the agent treats the wrong content as a trusted source of instructions and allows itself to be misdirected or misused. This happens when the system fails to maintain a strict trust boundary between system-level directives and untrusted user data.

How on earth is a probabilistic token predictor supposed to turn untrusted user input into trusted system-level directives? The strict trust boundary must be maintained on this side of the agent, not within it.

New comment by zzril in "EU Council forces Chat Control via fast-track"

zzril — Sun, 05 Jul 2026 23:16:49 +0000

I have conditioned my left first finger and pinky to just hammer F5 and Esc until the page loading stops at the right moment...

New comment by zzril in "Web-based cryptography is always snake oil"

zzril — Sun, 05 Jul 2026 22:34:05 +0000

in fact, this could be generalized more and doesn't neccessarily have to be about hiding messages. We've all heard the discussions about using VPNs "for privacy" (i. e. for hiding your IP metadata), when it's really just shifting trust away from your ISP and towards the VPN supplier.

It always comes down to who the alternative party to trust would be. In the fictional dialogue, the alternative appears to be to not send the message. Which may or may not be the better option than to give Eve eavesdropping capabilities.

New comment by zzril in "Web-based cryptography is always snake oil"

zzril — Sun, 05 Jul 2026 22:22:35 +0000

I guess you could make a point for using messengers based on open protocols (like Matrix) that have plenty of different client implementations. It doesn't protect you from targeted attacks (it might if you can somehow hide from the outside world which client you're using, or if you write and maintain the client yourself) - but it makes it less likely to be affected if your favourite agency managed to backdoor some random client implementation.

New comment by zzril in "Phosh 0.56.0"

zzril — Sun, 05 Jul 2026 14:53:40 +0000

SXMO is pretty minimal in that regard, but it doesn't force you to use the touchscreen. Can also navigate through menus via the volume buttons...

New comment by zzril in "If you're a button, you have one job"

zzril — Sun, 05 Jul 2026 11:25:19 +0000

As a user, I much prefer a blocking UI thread to one that lets me spam clicks on the "rotate left" and "flip along vertical axis" buttons and then makes me wonder why the resulting image is not the flipped verstion of what I saw the moment when I clicked "flip". However, I do like being able to abort my operations, and a blocking thread does not let me do that.

It might be quite a hard problem to determine which buttons should be disabled during which operations. One tricky candidate is the "safe" button. Should I be able to click it when the visual feedback I'm getting does not yet match the internal state of the application (which is what will be saved)? Should I be able to start further tasks when the save is still in progress? (If so, what if the save fails? Will I be able to roll back to the state before the attempted save and try again?)