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

Did that LinkedIn account cut the 15 minutes itself, or repost someone else's cut? Depends which one you are looking at, sloppy framing or a hook someone built on purpose.

The number I would want unpacked is the 80% indexing-memory cut.

Closest I know of are SycEval and the sycophancy evals in Anthropic's 2023 paper, both built on a user pushing back at a correct answer.

The self-report objection has been tested, though. Aphantasics show no imagery priming in binocular rivalry, no pupil constriction when asked to imagine bright shapes, and flat skin conductance to frightening text while responding normally to frightening pictures. A questionnaire that predicts autonomic responses nobody can fake is doing more than semantics.


Yes, sorry I believe we are saying the same thing.

I'm saying there are a number of physical tests like the ones you describe, and those line up with the much simpler apple imagery self-report test.


The checklist half automates cleanly, you can lint that every route calls authorize. It won't catch authorize being handed the wrong policy, which is the one that ships. And when I put a second model on review duty, the common failure is it agreeing with the first model's misreading of the spec, almost word for word. So I'd expect the forgetting class of bugs to mostly go away and the misread-the-spec class to sit exactly where it is.


LLMs trivially catch these things in review, and if you find agents agreeing incorrectly with each other (weak models?), maybe you need to be doing adversarial review.

It's pretty much solved, though I only use sota models.

I think for these convos, we need to see concrete fail cases so we can see what you're talking about and whether the truth matches up with the claim.


The reusability goal is what turns this from an age check into an identity vault, and the two have opposite risk profiles. A +18 result needs to survive as one bit; a reusable proof scoped to a valid government ID needs the document, which is exactly why you now have to keep it.

Genuine question: what happens when someone loses the passkey? If the answer is re-verify from scratch, the persisted blob only bought convenience on the happy path. If there's a recovery flow, that flow is now the weakest link in the design.


Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.

Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.


the recovery flow is scoped to the account but not the encrypted data. if the passkey is lost, the encrypted identity data is lost (by design) and the user has to upload again before new verifications. the account and associations with previously linked applications remain.


Worth saying out loud: user-agent is not identity. Verify AI crawlers by reverse DNS or the provider's published IP ranges - the ones worth letting in all publish them.


We stopped trying to keep the key away from the model and made it cheap instead: per-run, spend-capped, deleted at teardown. Assume it reads the file.


The leaks I've had weren't in the tree — they were in test fixtures and in a DB column holding a whole run's transcript. Any chance of a stdin/JSONL mode?


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

Search: