gwern

Attacks can be chained, and this can all be automated. For example, imagine pigbutchering scams... except it's there, similar to some voice-cloning scams, just to get enough data to stylometrically fingerprint you for future reference. You make sure to never comment too much or spicily under your real name, but someone slides into your DMs with a thoughtful, informative, high-quality comment, and you politely strike up an interesting conversation which goes well and you think nothing of it and have forgotten it a week later - and 5 years later you're in jail or fired or have been doxed or been framed. 'Direct methods' can't deliver that kind of capability post hoc, even for actors who do have access to those methods (which is a vanishing percentage of all actors). No one has cheap enough intelligence and skilled labor to do this right now. But they will.

You should write all that up! (I've been around for a while and I never used Flickr except as a casual, but I did know about a lot of mashups and even spent time using FlickrLickr for Wikipedia; yet I've never heard of... any of that.)

The SMPY page is essentially an annotated bibliography: fulltext + abstract + commentary. Since the papers are of highly varied quality, it doesn't much make sense to try to put any particular confidence on it; I am convinced of some things, but definitely not others - particularly the early papers when they had little data and were still experimenting a lot. If I had an essay making a specific claim about SMPY then sure, but I don't really.

The fact that 'certainty' ratings don't make sense for pages like that is part of why these days, I wouldn't have a page like that at all. An annotated bibliography is not an 'essay' and shouldn't be shoehorned into my framework meant for that kind of opinionated writing. I realized that if I was going to 'annotate' a paper, I would either have to go without, or copy-paste it all around indefinitely and it'd violate DRY and be a nightmare. Long story short, https://gwern.net/doc/iq/high/smpy/index is closer to what that page should be, but it's a lot of work to sit down and convert the legacy page over to pure annotations, so, it is what it is. Maybe a LLM can do it for me soon - it seems within the ability of Claude Code.

> I'd note that there are many studies showing that the usual outcomes for gifted kids are not all that great.

No, there's not, and they do do great. And this goes back to Terman: there's a handful of highly selected examples (eg the Australian kids recruited from child psychologist referrals, the self-selected self-diagnosed Mensa adult survey), furious anecdotes, and then every systematic prospective sample like Terman or population registers or SMPY shows the opposite.

And while Tao is, of course, exceptional, the results for accelerated gifted kids are generally great. And Tao was part of SMPY (note the URL path, supporting documentation for https://gwern.net/smpy ) and helped demonstrate this in practice.

I enjoyed the reward-hacking one: https://pagedout.institute/download/PagedOut_008.pdf#page=59

K-V caches are large, but hidden states aren't necessarily that large. And if you can run a model once ridiculously fast, then you can loop it repeatedly and still be fast. So I wonder about the 'modern RNNs' like RWKV here...

> Ideally, I'd like to continue working on it to build something that can help clubs make minimal, inexpensive changes while maximally improving the strategic interest if the way the course plays.

Yes, that's why I mentioned that this gives you at least one possible measure of 'strategicness' which can be computed automatically. Measure the variance across policies (skill level, which maybe you could define physically as some sort of 'mean absolute circular error' in strokes?), and now you can do quite simple optimization routines to modify courses. Like take a course, randomly flip some squares to sand/water/grass/etc, compute the new strategicness, and keep it if it's higher. Random search, simulated annealing, CMA-ES, novelty search, lots of easy possibilities I bet even a LLM could implement for you these days which would let you take an existing golf course and search for new modified layouts with higher strategy, to inspire a human expert in modifying a course.

I'm not sure this is even measuring LLMs in the first place! They say the definition is "big data analytics and AI".

Is putting Google Analytics onto your website and pulling a report 'big data analytics'...?

OK, so assuming you clean that up a bit and this becomes officially supported in SingleFile/SingleFileZ, what is missing compared to Gwtar? Anything important or just optional features like image recompression and PAR2?

Allowing more metadata might be useful. You can add anything to the manifest at build time as assets are not required to be loaded or ever used (because this is impossible to statically check). I suppose we'd have to define an official prefix like 'gwtar-metadata-*' with like a 'gwtar-metadata-screenshot' and 'gwtar-metadata-desciption'... Not obvious what the best way forward is there, you don't want to add a whole bunch of ad hoc metadata fields, everyone will have a different one they want. Exif...?

Multiple versions or multiple pages (maybe they can be the same thing?) would be nice but also unclear how to make that. An iframe wrapper?

I considered and rejected deduplication and compression. Those can be done by the filesystem/server transparent to the format. (If there's an image file duplicated across multiple pages, then it should be trivial for any filesystem or server to detect or compress those away.)

If those were guaranteed inaccessible, wouldn't a web browser be within its rights to optimize those away?

My immediate thought is that OP is reinventing dynamic programming/RL from first principles. The final visualization looks exactly like a standard value estimate heatmap. Golf is a MDP over all the physical points on the course, with stochastic probabilities of transition to each one based on golfer skill and physical randomness. Strokes are the cost to be minimized, the colors are the value estimate at each state, and his difficulties with the different maps is because a value function is defined as the expected value of being in that state assuming you will follow a particular policy thereafter (ie. be a golfer of a particular skill level, playing optimally for that skill). This lets you formalize 'strategicness' of a golf course: it is how much the value estimates differ on average across the full range of golf skills; a non-strategic course looks identical for the beginner and pro, while an incredibly strategic course might have completely different values for every point for every bracket of skill. (You could probably automate creation of pathological golf courses this way, where even a slight increase in skill makes the new strategy different.)

But that's a reason you should expect it to stop working soon, just like all the older tricks like "my grandmother will die". If you have a universal 'blind' prompt which can increase performance a little bit... the AI labs can just toss that into the training loop to teach the model to do it automatically, whatever 'it' was, like 'trying harder' or 'writing down a useful idea'. And then the prompt stops working because the next generations do it by default.

(This also suggests that you should expect them to generally be bad at judging novel self-generated prompts/skills - if they could judge those, they would already be using them! There is a generator-verifier gap, but it is already exploited heavily during post-training and not much low-hanging fruit left there.)

Yep: "The tower itself isn’t just a gimmick; it’s a physical presence that creates tension and anticipation the moment it hits the table. Add the Dark Horde expansion and suddenly the game isn’t just something you play—it’s something you engage with." 100% in Pangram, BTW.

But there's enough biographical details and concrete facts that I think he at least wrote the outline before having ChatGPT rewrite it.

I think there's still something missing here. This is a strange place for ChatGPT to confabulate quotes: extracting short quotes from a short text blog post is about easy as it gets these days. GPT-5.2 Pro can handle tens of thousands of words for me before I start to notice any small omissions or confabulations, and this was confabulating all that at just 1.5k words?

So since he says he was sick and his recollection cannot be trusted (I don't blame him, the second-to-last time I had COVID-19, I can barely remember anything about the worst day - which was Christmas Day), something seems to be missing. He may not have pasted in the blog post like he remembers. Or perhaps he got routed to a cheap model; it wouldn't surprise me if he was using a free tier, that accounts for a lot of these stories where GPT-5 underperforms and would explain a lot of stupidity by the GPT. Or didn't use GPT at all, who knows.

Yes, network is assumed. If it's local, there's no problem, just use MHT or SingleFile!

> Maybe this is downstream of Gwern choosing to use MediaWiki for his website?

This has nothing at all to do with the choice of server. The benefit of being a single-file, with zero configuration or special software required by anyone who ever hosts or rehosts a Gwtar in the future, would be true regardless of what wiki software I run.

(As it happens, Gwern.net has never used MediaWiki, or any standard dynamic CMS. It started as Gitit, and is now a very customized Hakyll static site with a lot of nginx options. I am surprised you thought that because Gwern.net looks nothing like any MediaWiki installation I have seen.)

I see. You could probably build something on top of wabac.js... But you'd need some sort of multi-file setup to support the indirection, I suppose.

> I imagine that loading archives without a web server was probably out-of-scope for Gwtar

More that it's just not important to us. I don't even look at the archives 'locally'. They are all archives of public web pages, which I just rehost publicly. When I want to look at them, I open them on Gwern.net like anyone else!

And if I really needed to, for some reason, it's literally a Bash one-liner (already provided inside the Gwtar as well as my writeup) to turn them back into a normal multi-file HTML. (This is a lot more than you can say for a WARC...) So my reaction to the complaints about lacking local viewing is mostly just ¯\_(ツ)_/¯

> (e.g., putting the tar in a <textarea>'s RCDATA; I wonder how well browsers support "binary" data in there?)

I don't know the details but you can just base-encode them, so I suppose that's an option, as long as you rewrote the ranges appropriately, maybe?

(Also worth noting that you can go the other way: if you really desperately want to preserve the raw header responses, you can just use the flexibility of Gwtar to append the WARC to the end of the file. As long as the range requests work, users won't download that part. The duplication is not so great for long-term storage, but you can just XZ them and that should remove duplication and overhead.)

OK, so your format doesn't solve the trilemma; you have 'static' and 'single-file', but not 'efficient'. Seems like you might as well just go with MHT or SingleFile then...?

Well, it seems easy enough to test if you think you are getting efficiency 'for free'. Dump a 10GB binary into a SingleFileZ, and see if your browser freezes.

I'm not following your point here. Yes, a web server (probably) has access to zip/tar utilities, but so what? That doesn't automagically make a random .zip jump through hoops to achieve anything beyond 'download like a normal binary asset'. That's what a ZIP file does. Meanwhile, Gwtar works with any server out of the box: it is just a HTML file using a pre-existing HTTP standardized functionality, and works even if the server declines to support range requests for some wacky reason like undocumented Cloudflare bugs, and downgrades RANGE to GET. (It just loses efficiency, but it still works, you know, in the way that a random .zip file doesn't work at all as a web page.) You can upload a Gwtar to any HTTP server or similar thing like an AWS bucket and it will at least work, zero configuration or plugins or additional executables or scripting.

Now, maybe you mean something like, 'a web server could additionally run some special CGI software or a plugin or do some fancy Lua scripting in order to munge a ZIP and split it up on the fly so as to do something like serve it to clients as a regular efficient multi-file HTML page'. Sure. I already cover that in the writeup, as we seriously considered this and got as far as writing a Lua nginx script to support special range requests. But then... it's not single-file. It's multi-file - whatever the additional special config file, script, plugin, or executable is.

What does that do?

OK, but how does that get you 'efficiency' if you're doing this weird thing where you serialize the entire page into some JSON blob and pass it in to an iframe or whatever? That would seem to destroy the 'efficiency' property of the trilemma. How do you get the full set of single-file, static, and efficient, while still working locally?

> that this is an implementation detail which is not really related to the format. In this case, a polyglot zip/html file could also interrupt page loading via a window.stop() call...However, I admit that I haven't implemented this mechanism yet.

Well, yes. That's why we created Gwtar and I didn't just use SingleFileZ. We would have preferred to not go to all this trouble and use someone else's maintained tool, but if it's not implemented, then I can't use it.

(Also, if it had been obvious to you how to do this window.stop+range-request trick beforehand, and you just hadn't gotten around to implementing it, it would have been nice if you had written it up somewhere more prominent; I was unable to find any prior art or discussion.)

'efficiency' is downloading only the assets needed to render the current view. How does it implement range requests and avoid downloading the entire SingleFileZ when a web browser requests the URL?

You could potentially use WARC instead of Tar as the appended container, sure, but that's a lot of complexity, WARC doesn't serialize the rendered page (so what is the greater 'fidelity' actually getting you?) and SingleFile doesn't support WARC, and I don't see a specific advantage that a Gwtar using WARC would have. The page rendered what it rendered.

And if you choose to require separate files and break single-file, then you have many options.

> surely you could host "warcviewer.html" and "warcviewer.js" next to "mycoolwarc.warc" "mycoolwrc.cdx"

I'm not familiar with warcviewer.js and Googling isn't showing it. Are you thinking of https://github.com/webrecorder/wabac.js ?

I find that 'save as' horribly breaks a lot of web pages. There's no choice these days but to load pages with JS and serialize out the final quiescent DOM. I also spend a lot of time with uBlock Origin and AlwaysKillSticky and NoScript wrangling my archive snapshots into readability.

> Just because is requires "special" zip software on the server?

Yes. A web browser can't just read a .zip file as a web page. (Even if a web browser decided to try to download, and decompress, and open a GUI file browser, you still just get a list of files to click.) Therefore, far from satisfying the trilemma, it just doesn't work.

And if you fix that, you still generally have a choice between either no longer being single-file or efficiency. (You can just serve a split-up HTML from a single ZIP file with some server-side software, which gets you efficiency, but now it's no longer single-file; and vice-versa. Because if it's a ZIP, how does it stop downloading and only download the parts you need?)

> Does this verify and/or rewrite the SRI integrity hashes when it inlines resources?

As far as I know, we do not have any hash verification beyond that built into TCP/IP or HTTPS etc. I included SHA hashes just to be safe and forward compatible, but they are not checked.

There's something of a question here of what hashes are buying you here and what the threat model is. In terms of archiving, we're often dealing with half-broken web pages (any of whose contents may themselves be broken) which may have gone through a chain of a dozen owners, where we have no possible web of trust to the original creator, assuming there is even one in any meaningful sense, and where our major failure modes tend to be total file loss or partial corruption somewhere during storage. A random JPG flipping a bit during the HTTPS range request download from the most recent server is in many ways the least of our problems in terms of availability and integrity.

This is why I spent a lot more time thinking about how to build FEC in, like with appending PAR2. I'm vastly more concerned about files being corrupted during storage or the chain of transmission or damaged by a server rewriting stuff, and how to recover from that instead of simply saying 'at least one bit changed somewhere along the way; good luck!'. If your connection is flaky and a JPEG doesn't look right, refresh the page. If the only Gwtar of a page that disappeared 20 years ago is missing half a file because a disk sector went bad in a hobbyist's PC 3 mirrors ago, you're SOL without FEC. (And even if you can find another good mirror... Where's your hash for that?)

> Would W3C Web Bundles and HTTP SXG Signed Exchanges solve for this use case?

No idea. It sounds like you know more about them than I do. What threat do they protect against, exactly?

The range requests are to offsets in the original file, so I would think that most cases of 'live' injection do not necessarily break it. If you download the page and the server injects a bunch of JS into the 'header' on the fly and the header is now 10,000 bytes longer, then it doesn't matter, since all of the ranges and offsets in the original file remain valid: the first JPG is still located starting at offset byte #123,456 in $URL, the second one is located starting at byte #456,789 etc, no matter how much spam got injected into it.

Beyond that, depending on how badly the server is tampering with stuff, of course it could break the Gwtar, but then, that is true of any web page whatsoever (never mind archiving), and why they should be very careful when doing so, and generally shouldn't.

Now you might wonder about 're-archiving': if the IA serves a Gwtar (perhaps archived from Gwern.net), and it injects its header with the metadata and timeline snapshot etc, is this IA Gwtar now broken? If you use a SingleFile-like approach to load it, properly force all references to be static and loaded, and serialize out the final quiescent DOM, then it should not be broken and it should look like you simply archived a normal IA-archived web page. (And then you might turn it back into a Gwtar, just now with a bunch of little additional IA-related snippets.) Also, note that the IA, specifically, does provide endpoints which do not include the wrapper, like APIs or, IIRC, the 'if_/' fragment. (Besides getting a clean copy to mirror, it's useful if you'd like to pop up an IA snapshot in an iframe without the header taking up a lot of space.)

So this is like SingleFileZ in that it's a single static inefficient HTML archive, but it can easily be viewed locally as well?

How does it bypass the security restrictions which break SingleFileZ/Gwtar in local viewing mode? It's complex enough I'm not following where the trick is and you only mention single-origin with regard to a minor detail (forms).