Here is how I see it:

  1. The user generates a token/nonce => T

  2. The user blinds the token with secret blinding factor b => Blinded token TB = T*b

  3. The user sends the blinded token for signing. The server signs it and returns it to the user => Signed blinded token TBS = Sign(TB)

  4. The user unblinds the token (this does not break the signature) => Signed Unblinded token TS = TBS/b

  5. The user sends TS for its search query.

This is assuming they don't call an external pre-processing decoding tool.

That being said, the fact that this is not a "raw" base model, but one tuned on the ARC-AGI tests distribution takes away from the impressiveness of the result — How much ? — I'm not sure, we'd need the un-tuned base o3 model score for that.

In the meantime, comparing this tuned o3 model to other un-tuned base models is unfair (apples-to-oranges kind of comparison).

I now almost exclusively get my HN feed through a simple script I wrote to get desc sorted posts by score or trend (score/time): https://github.com/faroukfaiz10/hackernews-homepage

The result looks something like this ({score/time} - {score} - {link} - {comments link}):

  59 - 1478 - Passport Photos - https://maxsiedentopf.com/passport-photos/ - https://news.ycombinator.com/item?id=42069646

  16 - 790 - Useful built-in macOS command-line utilities - https://weiyen.net/articles/useful-macos-cmd-line-utilities- https://news.ycombinator.com/item?id=42057431

  ...

- https://wormhole.app

- https://sendfiles.dev

- https://file.pizza

- https://winden.app

In my experience, I only prefer "Classical philosophical writing" when I'm already convinced of reading the content (e.g. know the author, interested by the subject).

In almost all other cases, I prefer BLUF format: i.e. "get to the point, I'll read more if I'm intrigued".

That might be a bit too strict. I'd still expect my private repos (no forks involved) to be private, unless we discover another footnote in GH's docs in a few years ¯\_(ツ)_/¯

But I'll forget about using forks except for publicly contributing to public repos.

> Users should never be expected to know these gotchas for a feature called "private".

Yes, the principle of least astonishment[0] should apply to security as well.

[0] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

Rightfully so. You'd statistically be almost always right considering a software unsecure given enough time (for the vulnerabilities to be introduced then found).

> need a secondary defense to "protect them"

Nothing wrong with that. It's called Defense in Depth and is rather advised. Once you understand that security measures are not bulletproof, stacking them proves to be an easy way to increase protection.

The case of fail2ban is not trivial: reducing log noise is a great perk, and can indirectly help with monitoring (you'd more easily notice suspicious behaviour if it's the only thing on your logs), but it comes at the small cost of setting it up, and accepting the risk of having a shared IP unwillingly blocked.

1. https://growth.design: case studies + cognitive biases & principles that affect your UX

2. https://lawsofux.com/: a collection of best practices that designers can consider when building user interfaces.

Probably nitpicking but these types of measures are usually tricky to interpret because there is a high chance your indexes (maybe even rows) are still on PostgreSQL shared buffers and OS cache and might not reflect real usage performance.

To get a more "worst-case" measure, after your inserts and indexes creation, you can restart your database server + flush OS pages cache (e.g. drop_caches for Linux), then do the measure.

Sometimes the difference is huge, although I don't suspect it will be in this case.

If I simply curl the script (without piping to bash), I'd be less suspicious if I saw a sleep than I would be if I saw a callback to a server.

> some source code and technical information were stolen from our development environment and used to target another employee

What surprises me is that there seems to be no other way than hacking (cutting, grepping, etc.) each package separately. I wonder how this is handled in machines that use a lot of MISC packages (other than pulling+building every time to automatically have the latest version)?

Also, kudos on the acronym :)

Reading through thus just reminded me of Datadog browser tests. It's not exactly the same, but it might be interesting to check them out.