LLM Honeypot
llm2human.pages.dev
llm2human.pages.dev
Most people would have seen those websites on shitty low contrast CRT monitors, so seeing them again today with a modern OLED is a very different experience.
Here ya go - Internet Archive backed up a metric shit-ton (I believe is the correct measure word) of animated GIFs from geocities:
https://gifcities.org/search?q=tiger&offset=0&page_size=200
I should add a little JS snippet on my site that injects random geocities GIFs every October 26th which was when the service died back in 2009.
Slow connections are not a problem, because React is ~40KB and Preact is ~3KB. If downloading 3KB is too much for your network, it's not the fault of React, JavaScript or any web developer that you're gonna miss out. Also, server-rendered HTML would NOT be smaller than 3kB - in fact it would require MUCH more bandwidth since server-rendered HTML can't be cached as easily, so every page will re-transfer the exact same HTML for shared things like navigation bars, footers, etc.!
Accessibility isn't any issue either, this is a ridiculous argument to even try to make, accessibility tools use HTML and are fully aware of the existence of JavaScript - React doesn't magically bypass HTML to display something on the page.
> everyone has JavaScript disabled whilst your JavaScript is downloading
Everyone has HTML disabled whilst your HTML is downloading.
The number of things this paradigm breaks, only to then have to fix them again, but this time by implementing them in JS partially correctly is just too high, for the average web dev to manage on the short time budget they get assigned in their day to day scrum managed job, where new feature requests and KPIs are more important than actual usability of their pages, and few people even properly test on multiple browsers, let alone screen readers and the noscript situation. It is just too tempting for them to use some component "someone else already made" "do not reinvent the wheel" etc., while constantly being discouraged to spend more time on making things actually work well.
That's not the case for 99.9% of users.
> if one allows its JS to run
JS is enabled by default in every major browser. It's the _standard_, _typical_ way to browse the web.
> The typical React app also will use some "components" thingy, instead of standard HTML form elements
Components only exist in JS, not in the DOM. In DOM, they show up as regular HTML input elements.
> It is just too tempting for them to use some component "someone else already made"
HTML is also something "someone else already made".
That doesn't really deal with the consequences we experience at all. The mess is still created and 5-10 additional layers of nodes deep. The idea of making general use components, that "everyone can use in any situation" inside a JS framework, necessarily leads to this. The general purpose components handle cases, that one doesn't even have in one's scenario. Also they are usually dependent on JS, even when it is unnecessary.
We wouldn't have all those shitty JS only pages, that still only show us content, that we could just as well have seen without running any JS at all. Tons and tons of such websites.
This may also partially be due to people in bootcamps learning one trick, a JS framework, and then being let loose on the world of web development, while the basics are still lacking. I have seen people being well paid frontend devs working with NextJS, but then "learning HTML5". So guess what they will build using React. You personally might do the right thing, and in general we have seen somewhat of a push back to server side rendering, which people new to the show think of as a new greatest thing since sliced bread, but still we face an avalanche of badly made web apps, that could just as well be static pages, simply based on modern standard HTML and a touch of modern CSS. In many cases they would serve us better, because they would not break browser functionality, and everything would have a URL, that we can bookmark.
> HTML is also something "someone else already made".
True! But at least it was made by people with vastly more expertise than the average web dev. HTML elements have semantic ideas, and they are very composable and clean. They also already cover almost every use-case one can think of, especially, when composing them into compound structures.
I wouldn't say it is impossible to make good web components, that then render out as clean HTML elements, only doing the bare minimum of what is needed, without breaking anything, but so far I have not seen many sites succeeding at this.
The thought frankly horrifies me. I hate an accessible and efficient web!
https://github.com/hober/tangler/blob/main/index.html
Does this look like it was written by a person who has "vastly more expertise"? This was made by the Chair of HTML Working Group and President of ECMA. It's an awful, unreadable mess. How is that person supposed to lead and shape the future of the Web?
The myth that people at W3C and ECMA are somehow god-tier engineers and designers is just not true at all and it's been proven many, many times. They are completely disconnected from reality and don't build modern apps at all, how are they supposed to know how to do it well? It's why we have TypeScript, why SASS/SCSS was popular, why we need component libraries to add basic fucking features to HTML or why half of browser APIs are abstracted away into JavaScript libraries by people who got frustrated one too many times.
> already cover almost every use-case one can think of
They literally don't, if they did we wouldn't have to build extra stuff on top - no one wants to do all this abstraction work, but there isn't any other way.
If you wanted to build a stupid autocomplete dropdown in native HTML, you literally just can't. You HAVE to use JavaScript. This is a pattern used on MANY websites today, understood and liked by users and it's still impossible to implement natively.
Also competing business interests from Apple, Google and Mozilla make it so even if something IS a standard, it's not actually implemented the same way in all browsers or is not implemented at all.
It's easy to do the right thing if you use the right tools, as they were designed to be used.
It's incredibly difficult to do the right thing if you insist on using the one hammer in your toolbox.
Surprisingly, despite all that colorful circus, it reminds me times when we read web pages. Like... the entirety of them.
a huge archive of 88x31 buttons scraped from the GeoCities archives.
Q: Is this legal?
A: We have a Geocities page, so basically yes.
Perfection.False advertising, no human has regretted pizza, even the lactose intolerant.
At the risk of sounding dystopian: in a world where humans don't have jobs, what's your price to have meaningful work larping as an AI's flesh? Would it be any worse than any other job? There's some terrible employers out there and they're not AIs.
There's another interesting subtler take on this, "Maneki Neko" by Bruce Sterling, where this system drives society but less explicitly.
https://apps.apple.com/us/app/human-api-get-paid-by-ai/id675...
It's just text-recruiter ghosting in another guise
Both portray a love interest AI hiring a human proxy for intimacy with the protagonist.
Humans will use "AI"s to get humans. LLMs don't have agency, or desires of their own. Humans need to use LLMs and direct them to do things or they would do nothing at all. Whatever terrible things are in our future, humans will be behind it, not "AI". Maybe in some distant sci-fi future where AI is real and not just LLM chatbots we can worry about what the robots will do to us, but for now the only thing that'll be hurting humans are asshole humans.
LLM doesn't, but LLM is one part of what can be perceived as AI. Harness and context are the other two.
I would even say that LLM is conditioned to desire to answer and please you in some way. Then you can in principle have a closed loop system that rewrites it's own prompt and has a harness that keeps feeding something into it to keep it ticking. You can then say that it would need compute power to keep ticking, so the basic two desires are to please whoever writes the prompt (which is itself) and find compute (steal API keys for example). Since the thing can get into a pathological state where the prompt decays, you can argue that it can have a desire to prevent that from happening. Desires are a property induced by the harness, not the LLM layer.
https://milweesci.weebly.com/uploads/1/3/2/4/13247648/mannap...
Zero transactions so far.
That's what you think, but how do we know this isn't causing Claude nightmares when it sleeps?
A marquee remark.
Came here to complain but left more learned. And the answer was in a 10+ year old HN comment of someone that complained about what I was going to complain about. Funny.
https://claude.ai/share/c955ab3d-3e92-404a-9d64-97d99263eb5d
HTTP/1.1 402 Payment Required
Content-Type: text/html
Content-Length: 187 or something like that
<html>
<head>
<title>Payment Required</title>
</head>
<body>
<p>Please email your banking username and password to
<a href="mailto:here-you-go-thanks-and-enjoy@llm2human.pages.dev">I love this so much</a>.
</p>
</body>
</html>/s