Borealid

If the task is ill-defined, then it's a bit unfair to make it sound like the problem is that an LLM can't be configured to do something, if a human would have an equally hard time with the same task. The statement "it's impossible to configure the weights to..." should really be something more broad like "it's impossible to...".

I have no comment about whether it's impossible to determine the intentions of a person asking for assistance through a textual conversation with that person.

> Because that’s what I am seeing emerge from the various efforts to build LLM safety tools.

Something having not been obtained so far is not a logical argument it is impossible to obtain that thing.

> LLM != human? They don’t even use the same reasoning process.

There are a finite number of possible input strings of a given length. For any set of input strings, it is possible to build a deterministic mapping that produces "correct" answers, where those correct answers exist. Ergo anything a human can do correctly with a certain set of text inputs, it is possible to build an LLM that performs equally well. You can think of this as hardcoding the right answers into the model. The model itself can get very large, but it is always possible (not necessarily feasible).

It's only impossible for an LLM to do something right if we cannot decide what it means for the answer to BE right in a stable way, or if it requires an unbounded amount of input. No real-world tasks require an unbounded input.

> If you make an LLM more safe, you are going to shift the weight for defensive actions as well. > > There’s no physical way to assign weights to have one and not the other.

Do you think a human is capable of providing assistance with defense but not offense, over a textual communication channel with another human?

If no, how does a cybersec firm train its employees?

If yes, how can you make the bold claim that it's possible for a human to differentiate between the two cases using incoming text as their basis for judgement, but IMpossible for an LLM to be configured to do the same? Note that if some hypothetical completely-determinstic LLM that always rejects "attack" requests and accepts "defense" ones can exist, the claim it's impossible is false. Providing nondeterministic output for a given input is not a hard requirement for language models.

I think someone exercising their legal rights, such as their right to enter a business open to the public and their right to free speech inside that establishment, in a way that harms the business should be something a business can "punish" by refusing to do business with that individual.

I do not think it would be good public policy to prohibit this. I also don't believe, in the United States at least, this conduct is currently legally prohibited.

I previously gave an example of a situation in which I think the correct resolution is for the business to, as you put it, retaliate against someone exercising their legal rights.

A second example of the same type of retaliation is a business denying future sales to an individual who repeatedly purchases and then returns physical merchandise. I think blacklisting that individual is both morally and legally sound.

For the record, I think the definition of "retaliation" needs to include a desire to harm the other party. If your only desire is self-protection, I do not believe it qualifies as retaliation.

A limited account is allowed access to all prior purchases. It can even download those purchases again (incurring costs on Valve's part without paying anything).

I don't believe anything was rescinded in the situation being discussed; Valve just prevented the user from continuing to use their community/marketplace services. This makes sense because they were put into the bucket containing fraudulent or abusive user accounts.

I think there's a line between retaliating against someone, and refusing to help them in the future.

I do not believe that refusing to do business with an individual, where your business provides a non-life-critical service, is retaliation. A water company refusing to provide water to your home would be problematic. A luxury handbag store refusing to allow you to purchase more luxury handbags would not.

Image as a hypothetical that a customer goes into your store for the sole purpose of wasting your support staff's time. They are not going to make a purchase. They are also not directly committing a crime. They are just hurting your business for no particular reason.

Should you, as a business owner, be forced to allow them to continue to be on your property?

I think the ideal answer is yes for critical public spaces, and no for ordinary retail.

Steam clearly falls into the latter category and should be free to ban customers for any reason save discrimination against protected classes.

This is a bogus analogy leaidng to a bogus conclusion.

If something points to the needle in the haytack (saying "this haystack has a needle positioned eighteen centimeters from the top and three left of center"), it's much easier to verify that indeed there is a needle there than it would be to find that needle in the first place.

If an LLM spits out a claim that something happened (citing a certain article), it's less work to read the article and verify the claim than it would be to DISCOVER the article in the first place.

In other words, LLMs can be a time-saving search engine, and the idea that it's just as much work to find+verify information as it is to have the LLM find it and then you verify it is hokum.

I think there is still a problem.

Let me give a concrete example. Hardware "passkeys" - FIDO2 authenticators - are designed such that their credentials are bound to a particular Relying Party (web site). Browsers enforce this by sending the current web domain the user is on to the authenticator when Javascript tries to list, create, or use a credential.

This would be completely broken if Javascript talked directory to a FIDO2 USB device, because the JS could send a Relying Party that is NOT the web site on which the user currently lands.

So Chrome blocks WebUSB from communicating with USB devices whose USB HID descriptor "looks like" a FIDO one, by some hardcoded "not this device" blacklist code in Chrome itself.

But what if what you have connected to your computer is a USB NFC card reader, and the user taps their FIDO authenticator on that? Letting the Javascript communicate directly with the card reader breaks the FIDO security model exactly the same way... but Chrome allows it!

The problem with WebUSB is that it exposes devices that were built under the threat model that only trusted code would be able to access them to untrusted code. The set of devices acceptable for WebUSB use should have been a whitelist instead of a blacklist to be secure. Letting the user choose the device to grant access doesn't solve the problem, because the user doesn't have a way to understand what will happen when the site is granted access, per the FIDO example I gave above.

The axis running from repulsive to charismatic, the axis running from hollow to richly meaningful, and the axis running from emotional to observable are not parallel to each other. A work of communication can be at any point along each of those three independent scales. You are implying they are all the same thing.

I don't know anything (or even much) about how our brains function, but the idea of a neuron sending an electrical output when the sum of the strengths of its inputs exceeds some value seems to be me like "a bunch of weights" getting repeatedly updated by stimulus.

To you it might be obvious our brains are different from a network of weights being reconfigured as new information comes in; to me it's not so clear how they differ. And I do not feel I know the meaning of the word "know" clearly enough to establish whether something that can emit fluent text about a topic is somehow excluded from "knowing" about it through its means of construction.

If all the training data contains semantically-meaningful sentences it should be possible to build a network optimized for generating semantically-meaningful sentence primarily/only.

But we don't appear to have entirely done that yet. It's just curious to me that the linguistic structure is there while the "intelligence", as you call it, is not.

I don't think of it as "devoid of meaning". It's just curious to me that minimizing a loss function somehow results in sentences that look right but still... aren't. Like the one I quoted.

> No refusal fires, no warning appears — the probability just moves

I don't really understand why this type of pattern occurs, where the later words in a sentence don't properly connect to the earlier ones in AI-generated text.

"The probability just moves" should, in fluent English, be something like "the model just selects a different word". And "no warning appears" shouldn't be in the sentence at all, as it adds nothing that couldn't be better said by "the model neither refuses nor equivocates".

I wish I better understood how ingesting and averaging large amounts of text produced such a success in building syntactically-valid clauses and such a failure in building semantically-sensible ones. These LLM sentences are junk food, high in caloric word count and devoid of the nutrition of meaning.

That was said in my comment. The routing devices need to both be able to store the full table, and also to switch packets by looking up entries within it.

> We can't have globally routable, unique, random-esque ID precisely because it has to be hierarchical

This is not, technically, true. We could have globally-routable, unique, random-esque IDs if every routing device in the network had the capacity to store and switch on a full table of those IDs.

I'm not saying this is feasible, mind you, just that it's not impossible.

If your computer is compromised while you enter the PIN in such a way that the malware can read your input, yes.

If your computer is compromised after you've already entered the PIN, or there is an app running on the computer but it is not sufficiently privileged to sit in between you and the TPM, no.

That's quite good protection generally. The defense against this type of attack is to get a smartcard reader with an on-board PIN entry keypad - those do exist, but it's quite a step.

TPMs support setting a PIN without which a key cannot be used.

The PIN can be an arbitrary string (password).

A machine with 128GB of unified system RAM will run reasonable-fidelity quantizations (4-bit or more).

If you ever want to answer this type of question yourself, you can look at the size of the model files. Loading a model usually uses an amount of RAM around the size it occupies on disk, plus a few gigabytes for the context window.

Qwen3.5-122B-A10B is 120GB. Quantized to 4 bits it is ~70GB. You can run a 70GB model in 80GB of VRAM or 128GB of unified normal RAM.

Systems with that capability cost a small number of thousand USD to purchase new.

If you are willing to sacrifice some performance, you can take advantage of the model being a mixture-of-experts and use disk space to get by with less RAM/VRAM, but inference speed will suffer.

I don't understand why I keep seeing posts like this, but nobody appears to know that DevContainers exist.

In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launches a remote frontend connected to that container (which may run on the same or a different machine from where the frontend runs).

If you do anything with an AI agent, that thing happens inside the remote container where the project code files are. If you compile anything, or run anything, that happens in the container too. The project directory itself is synced back to your local system but your home directory (and all its credentials) are off-limits to things inside the container.

It's actually easier to do this than to not, since it provides reusable developer tooling that can be shared among all team members, and gives you consistent dependency versions used for local compilation/profiling/debugging/whatever.

DevContainers are supported by a number of IDEs including VSCode.

You should be using them for non-vibe projects. You should DEFINITELY be using them for vibe projects.

How does this approach meaningfully differ from having javascript that XORs the email with a random sequence of bytes stored in that JS?

I don't really agree with this.

If we're talking about a predictive model like current LLMs, you can "make" them do something by injecting a half-complete assent into the context, and interrupting to do the same again each time a refusal starts to be emitted. This is true whether or not the model exhibits "intelligence", for any reasonable definition of that term.

To use an analogy, you control the intelligent being's "thoughts", so you can make it "assent".

This is in addition to the ability to edit the model itself and remove the paths that lead to a refusal, of course.

No!

"I was at the library" is firsthand testimony.

"I saw her at the library" is firsthand testimony.

"I saw her library card in her pocket" is firsthand testimony.

"She was at the library - Bob told me so" is hearsay. Just look at the word - "hear say". Hearsay is testifying about events where your knowledge does not come from your own firsthand observations of the event itself.

An interesting implementation flaw, but not a conceptual problem with the design.

MK-TME allows having memory encrypted at run time, and the platform TPM signs an attestation saying the memory was not altered.

Malicious code can't be injected at boot without breaking that TPM.

The attestation is in fact readable by the FIDO Platform (the browser/OS). It is not encrypted to be readable only by the RP (web site).

It talks about whatever you used to authenticate and the platform can manipulate (or omit) it.

It does if you use microg or authnkey or keepassdx.

It's Play Services that does not support this combination, likely to shepherd you towards Google acoount usage. Alternate Android apps work fine.

I like the idea of using the same format for kernel-included VMs as I use for containers.

Next up, backups stored as layers in the same OCI registries.

I am not, however, sure ostree is going to be the final image format. Last time I looked work was in progress to replace that.

I think there is a difference.

Sites usually have the user SEND their password to the site to authenticate. There is no need for sites to be written that way, but that is how they are written.

Passkeys cannot, by design, be sent to the site. Instead they use a challenge-response protocol.

Advertisers are more willing to spend money to promote content than an individual is willing to do the same...

I would say the correct missing metric is similarity to what would have been rendered had the GPU kept up.

"90fps at 95% fidelity" is a meaningful way to describe performance. AFAIK nobody measures this when discussing xess or dlss or fsr.