miki123211

On that note: I was always wondering whether you could do stupid CT log tricks.

If I remember correctly, Let's Encrypt lets you go up to a hundred domains per certificate, with 256 characters per domain[1]. If you get a short domain like a.bc and start requesting certificates for its subdomains, you can easily get a few kB of user-controlled data embeddable per certificate. Given LE's rate limits, it should, within a few weeks of easily-automated work, be possible to embed child pornography into a CT log, making it illegal to host and destroying it completely.

You could do something more useful (and less destructive) with this idea; like embedding a separate public key, with the corresponding private key stored offline in an HSM, which could then be used to sign the location of your new domain in case the old one was seized. This would, in a weird and perverted way, add a lot more censorship resistance to DNS than what it natively provides.

You could even use a CT log as a blockchain, with the order of log entries being used for consensus.

And Europe is now doing the same, by integrating all the weird local methods that EU countries have come up with into one unified local system.

non-LLM models just aren't visible to consumers.

Saying that the field got reduced to only LLMs is like saying that the field of combustion engines got reduced to cars. The trucks, combine harvesters and peaker plants are still here, they're just in the background, invisible to people who are not part of the industry.

Banks still use random forests and SVMs, medicine and image processing still use CNNs (and people who take photos with their phone don't even realize how much image processing is being done), TTS, ASR and predictive typing models are in wide use, and there's probably still plenty of BERT in spam classification and such.

LLMs, and other transformer models before them like BERT for example, have the benefit of "transfer learning."

If you want to make a ticket classification model, you don't need to train across many customers doing ticket classification, who might not want you to train on their data and whose data is impossible to obtain unless you already are a large company. Instead, you can train on a completely different task which forces the model to learn the syntactic and semantic structure of the English language — say predicting missing words in Wikipedia articles, which you can't do successfully without a good understanding of English — and then fine-tune that model on your specific task with much less data.

Because the initial task is so general, you can have one company do the expensive pretraining, share the base model, and then have everybody else just do the finetuning on their (small) proprietary dataset.

LLMs and models like Jev go one step further, letting you use them as classifiers with no training at all, with nothing but rules in the prompt. And with a few tricks, you can indeed use them to get pretty high-quality labels, which you can then distill into a fine-tuning dataset for a much smaller model.

Everybody I know who still runs their email server (you can get Europeans out of Europe, but you can't get Europe out of the Europeans) complains about Microsoft.

I bet Microsoft is single-handedly responsible for 80+% of complaints about email being impossible to host.

In a federated / pseudo-decentralized network, any provider with 10+% of captive users has an outsized leverage on the entire ecosystem. You don't need a monopoly; as long as you have a monopoly on just a few users that others absolutely need to be able to interact with, you can dictate terms to everybody.

They had other issues. SQLI, XSS and XSRF were rampant in those days.

Yes, you don't (in most countries) need a SIM for 112/911, and even when you do have one, you are allowed to use other carriers for such calls, even when you ordinarily shouldn't be able to roam onto them.

They already are worse.

Smartphone OS makers have top-notch security teams, and they are tech companies who understand how tech works extremely well. Actual Android smartphone makers (thing Samsung or Motorola) are humble enough to understand that they should just let Google do the hard parts of the OS.

Car makers are not tech (software / internet) companies, do not understand how to think about tech to be successful in tech, do not have the right mental models for cybersecurity work, but they nevertheless want to do their own software instead of getting it from a more responsible party. This is a recipe for disaster. And, just like smart TV makers, they make their money on hardware, compete on price, and aren't advertising companies themselves, which encourages shady deals with data brokers.

It should be three (four) layers, and that seems to be the emerging architecture for agents.

Layer 1 is the frontend (TUI, GUI, phone app). Layer 2 is the brain / harness (the thing that stores sessions, connects to MCP servers and decides what to do next given the latest model answer). This part would ideally run in the cloud, and be independent of the particular ephemeral sandbox you run your commands in, or the particular phone you view the transcript on. Layer three is the hands (the thing that actually executes tool calls on a machine), this should be a small utility that the brain connects to over ssh, or a local Unix socket if colocated.

As a daily screen reader user... you can't build accessibility into a TUI. You literally can't. There are no APIs for it. This is, in fact, one of my frustrations with TUIs and why I think GUIs are better in principle.

I think this basically happened because the cost of creation (of what people want to consume, regardless of how you feel about it) went up significantly.

When copyright was invented, it was mostly applied to books (not even book series / franchises), which don't cost that much to write, even if you take printing into account, and are usually written by a single author or a small team.

Nowadays, copyright is applied to huge cinematic and video game universes, which cost hundreds of billions of dollars to make, and don't have a single "author" behind them. It's a very different law for a very different reality.

When Moby Dick was written, Moby Dick was all it was. Nowadays, every new movie in a given universe is intended to bring profits on its own, but, by making that universe more popular, it increases future profits for other things in the franchise too. This is all reflected in the accounting, and requires copyright to be much longer than it once was.

not the OP, but generally, if you don't want to / can't use auto mode for some reason, you want Claude to make its actions as reviewable as possible.

Recent GPT and Claude models have this tendency of using super complex Bash commands. This makes sense, if your RL rewards optimize for min(tokens) and max(performance), it is better to waste a few tokens on a complex inline Bash script that runs a few commands at a time and returns just the output you need, rather than doing one simple command per turn and paying the cache read on every turn, like older models used to do.

This, however, is a problem both for command reviewability and sandboxing. With the older way of doing things, without auto mode, most commands would run sandboxed just fine (especially in Codex), and you would only be asked for approval when a command couldn't run in the sandbox. With everything being stuffed into one complex script, almost every script fails in the sandbox and requires you to manually approve it, and the complexity of the script makes it hard to understand what you're actually approving.

In other words, new models optimize for effectiveness, with some attention paid to human understandability of their output, but almost no attention paid to human understandability of tool call arguments (Bash, inline Python). This suits auto mode and giving the model larger tasks, but not the way of working that some people prefer where you watch over the model's shoulder.

Most harnesses are not designed with conversations to be append-only from the start, which causes us all endless pain when caching is concerned.

When making a harness, it is so, so easy to do the "web thing" and have your system prompt be a template where you dynamically inject variables like the current date or the contents of the current working directory, and then just re-render that template on every request. THis is a bad, doubleplusungood, terrible, awful idea, and you should never do this under any circumstances. Anthropic will soon force you not to by literally refusing conversations that "break continuity" in this way and do anything but append new user messages at the end, but other providers at least appear to work.

I think this was a marketing play by ANthropic.

Look, it's just a tool, you are a developer, you've used TUIs all your career, this is just one more TUI, no different than your beloved Vim or Emacs. No need to be scared, this won't replace you because mere mortals won't know what to do with a TUI, so you can use it freely and get more work done, just as you were always obsessed with doing when configuring your Vim bindings.

Then, a year in, when everybody is hooked line and sinker, people start to understand that the TUI is the least important part of the whole thing, and the model and harness are what really matters.

I don't get why people love TUIs so much. They're basically GUIs made using inferior tools. Why hammer in a nail using your fist if you have a hammer handy?

A GUI is strictly more powerful than a TUI (because a GUI could just show plain text in cases where that is the most appropriate mode of interaction, E.G. Bloomberg, AMadeus), but it could also do so much more in cases where it is not.

I do love terminals, don't get me wrong. When what you're interacting with is CLIs and Unix tools in a shell, a terminal is exactly what you want. I do love the Unix philosophy, I like small and composable tools that you can use together, and I think the interactive way of working that a shell or REPL can give you is great (though notebooks would have been better, but that's beside the point). Those are things that the terminal shines at. Pretending to be a GUI is not one of those things.

My issue with mandated ranges is how to require the range to be narrow enough, without preventing the candidate from negotiating?

If you don't have any narrowness requirements, you can have a job where the range is $50k-500k, which is useless. If you narrow it to — let's say — 10% of the midpoint, you can say $180k-220k, but then you're not allowed to hire the perfect candidate who won't accept less than $250k, even though you would actually want to pay this much given that person's skills. If the candidate is allowed to negotiate upwards, ranges may gradually, over the course of years, drift downwards, with an implicit understanding that they are unrepresentative of the actual salary you are likely to earn.

With an infinite number of employers and an infinite number of candidates, you would always be able to find the perfect candidate for your mix of requirements and pay them the exact salary that matches those requirements. The real world isn't like that, though, and if you, as an employer, have an offer available, you will get candidates who are under and over qualified for the specific offer you had in mind, and you might nevertheless be able to find a spot for them at some salary that both of you are willing to accept.

Wait, so if you're running on embedded, you're not allowed to store anything at address 0, requiring you to waste that little bit of RAM?

That's... a bizarre choice, considering how religious C is about not making any assumptions about what a machine can and cannot do, even going to the trouble of working with non-IEEE floats and int types that are not a multiple of 8 bits.

In theory, having newtons and pounds force be represented as `float` is type safe. In practice, it destroyed a multi-million-dollar NASA spacecraft because of human error.

If NASA were to use the equivalent of `pub struct Newtons(f32); pub struct PoundsForce(f32);`, where the types Newton and PoundsForce were not interchangeable, this would never have happened[1].

[1] I'm aware that that story is a bit more complicated than that, that CSV files were involved (which are, again, not type safe), and that, in that particular scenario, more would have to be done to preserve type safety across formats, vendors and codebases, but my point still stands.

Have you had any of your coworkers update Adobe Flash Player, enter their Okta credentials to "claim their $150 Christmas Walmart voucher" in the company-mandated phishing test, or install "Zoom" to join a job interview or sales call from their work laptop?

The attack is different, the result is the same.

Humans are vulnerable to scams, cons, phishing and social engineering. This is a vulnerability whose root cause we not know how to fix. We can only alleviate its effects by re-engineering the environment around those vulnerable humans.

LLMs are just as gullible, we just tend to call their vulnerabilities "prompt injection", even though it's basically the same class of attack under the hood. Unlike humans, though, LLMs are a lot less diverse (you and I are using the same Opus 5.5, but we have different brains). This makes attacks on LLMs much more predictable and easier to pull off, just as a phishing campaign that targets one specific person is easier than an attack that scales to millions of diverse victims.

In the age of agents, phishing will continue to be the biggest attack vector of all, it's just the victims that will change.

Have there been significant AI-assisted exploits found against software which is not written in memory-unsafe languages?

As models get better and porting costs get lower, maybe it's better to bite the bullet and RRiR instead of having a minor bugpocalypse every 3 months, as each subsequent generation of frontier models finds sev-high CVEs?

People who make things often have an unrealistic expectation of how much users care about quality (and don't realize how much users actually care about price).

We've seen this play out over and over again, in many different sectors. The whole shtick of the old (Bellhead) telecom world was quality at the (literal) expense of price, which didn't work out well for them. Same for CD versus pirated mp3s, DVD versus pirated videos (and, to a lesser extend, theaters versus bootleg cam releases), native texting / GSM calls versus WhatsApp and similar, mainstream newspapers and media versus blogging and social media, traditional electrical appliances versus Chinese-made, and so on.

Because of the innovator's dilemma, In many cases, the cheaper, lower-quality product later surpasses the quality of its more expensive counterpart.

AI is just one more example of this happening. It lets you make more things which otherwise would be far too expensive to make, even if that often means a lower quality product.

> The web is getting harder and harder to use

What are you doing to make this true?

I'm a screen reader user (which is as "weird and unusual" as it gets when fingerprinting mechanisms are concerned), and I am not really noticing much difference versus 2022 or so. Sure, there's little bits of anubis here or there, and a few sites (which I know for a fact are experiencing targeted DDoS attacks unrelated to AI scraping) having annoying Cloudflare verification screens, but that's about it.

My setup (other than the screen reader) is as vanilla as it gets. Safari, AdGuard for Ad blocking, no VPN except work VPN when necessary, no PiHole, no settings changed. If you're using something more esoteric, maybe try going mainstream and see if that improves your experience.

Anthropic models (at least the latest generation, I haven't noticed much of that behavior before, although I was mostly with OpenAI at that point) seem profoundly lazy.

Where OpenAI will go out of its way to search the internet and cite sources, Claude will typically just go from memory and common sense. I'm half-tempted to write myself a hook that greps my responses for "haven't verified" and "haven't checked" and asks it to do so.

There are tradeoffs to this ofc; just using weights is more token efficient and faster, and there are situations where the model genuinely knows and doesn't have to check. Anthropic models seem better calibrated with regards to knowing what they do know and what they don't (and openly admitting what they haven't yet checked to the point of pedantry), whereas OpenAI models seem to err on the side of caution and check everything just in case. Of course, if you are so inclined, you could use either behavior to spin a conspiracy-theory-minded narrative about how "Anthropic is deliberately nerfing their models to save on compute" or how "OpenAI is wasting your tokens to get more money out of you without increasing sticker prices."

AFAIK, symmetric encryption (which is what you'd use for crypto erasure) is not thought to be vulnerable to quantum computers, and it would be a huge mathematical breakthrough if it turned out that currently-known symmetric crypto algorithms were actually weak.

It's also how LLMs thing (not accusing the author of slop here, just making a slightly unrelated observation).

If I ask my Claude (Opus 5.5) about how some Claude feature works, its natural inclination is to start reversing its own binary with strings instead of looking at Anthropic's documentation. It will, entirely unprompted, try to figure out how its environment works in Claude Code cloud and reverse–reverse-engineer Anthropic's Rust binaries to figure out why things happen the way they do, and what it needs to do about it.

I don't think anybody in their right mind would ever bailout Anthropic or Nvidia.

Now bailing out somebody who over-invested in Nvidia but also holds the world's retirement savings... now that's something I can believe.

IMO, the largest benefit of most JS frameworks is a great story for statee synchronization.

Imagine an e-commerce website that has a cart with some products. The site has a cart button showing the current total, a pop-up cart interface, as well as an assortment of 10 or 20 different components which let you add or remove products (E.G. the Christmas promotion page may be using a different, christmas-themed "Add to cart" button).

You need to keep all of these in sync. If you open the cart pop-up and remove the product you've just added on the Christmas promotion page, the button on that page must change color (and ARIA state / label) back to show that the product is not in the cart any more.

With traditional, imperative JS, you have ~20 places where this state is kept: The card array is the source of truth, the CSS classes, labels and aria properties of all these buttons must stay in sync with that array, but there's nothing that forces them to do so.

Sure, there are some software engineering patterns (I'm looking at event-driven design here in particular) which make this kind of bugs less likely, but they're still not really a guarantee of the code being correct by construction.

React and its ilk make it much, much harder to introduce that kind of bug, requiring you to basically go out of your way to do so.

Because AI agents love slop and "just one more edge case just to fix that one bug" thinking instead of addressing the underlying root cause of the bug class, this kind of thing is more important now than it ever was before. Agents are great only if you set them up for success, and the way to do that is to make bugs impossible to write.

You don't necessarily want free software and traditional cryptography for such use cases.

The traditional free software approach to cryptography is "derive the key from a passphrase; require the user to make the passphrase strong; if the passphrase is weak, put the onus on the user."

This works well for HNers, but is terrible for normies. What normal users want is a locked down chip (potentially running open source firmware!), which securely stores something like an AES key protected by a 6-digit pin, which gets erased after 10 unsuccessful attempts and cannot be cloned. This is how TPMs, Apple's secure enclaves and bank and SIM cards work. This kind of design did more to bring full-disk encryption to end users than any free software ever did.

Don't worry! If it gets popular enough, it will be Goodharted to hell and back.