Borealid

No. The how is relevant here because it leads to understanding of the resulting behavior.

If you train the LLM on a corpus that shows people saying the sky is red, you get an LLM that is predisposed to say the sky is red. This is true even if it's also trained on all of the science that explains how and why the sky is blue.

If it were to "figure out" or "reason", it would not have such a predisposition to emit "red" after "the sky is" just because that matches the reward during training.

In other words, the token prediction is important because it both explains the successes AND the failures of the LLM. If there were situations in which a bird could fail to fly, then how it tried to fly would also be crucial knowledge.

Your casual understanding is imprecise.

At all times the LLM is, indeed, predicting the next token. Anything it does emerges from that.

It did not "figure anything out". It predicted that text describing the use of a radial gradient was likely to follow text describing your problem.

Most spreadsheet engines are turing complete, so you could use them to run an LLM.

I don't think many people would say an LLM written in Python is conscious BUT an LLM written in Excel is not.

People just don't ascribe consciousness to things that can't converse (or at least emote or give the appearance of emoting), and spreadsheets don't do that.

The reason people are debating the consciousness of LLMs is - obviously - that the LLMs generate sufficiently plausible text that people using them think they're having a two-part conversation. Like I think I might be having a two-part conversation now. Turning your question around, why do you think Hacker News posters are conscious? You have no direct evidence they are.

The Framework 16 lets you put a pad with twenty-four additional buttons on it next to the keyboard. These 24 buttons can be programmed to do whatever you want with reprogrammable firmware.

Also, there are twenty-three different keyboard layouts available (IN ADDITION TO the 24-key macropad).

I think there are legitimate arguments against Framework, but this one clearly isn't cogent.

I said the owners can't be held liable, I meant the owners can't be held liable.

You can "in certain circumstances" (negligence, overt criminality...) go after the managers. You probably can't go after the managers for things like producing a business plan they could have plausibly believed was legal and causing the company to incur civil liability.

In the situation described in this article, probably both the owners and the managers (likely the same people!) get away without being held accountable, and the victims have no recompense because the company folds.

The post to which you're replying is implying that the lift shafts are entirely opaque to the wireless signal.

So it's fine if the user doesn't have a shaft between them and the AP. When they move so a straight line from the device to the AP crosses through a lift shaft, they enter the wireless "shadow" cast by that shaft, preventing them from contacting the AP. When they take another step forward the device might "come out of the shadow".

This is a difficult situation to deal with in roaming, where the visible AP set changes rapidly as the user moves a small amount.

TL;DR: I'm pretty sure the parent you're replying to "got it" and you didn't understand what they were trying to say.

As a slight hint, one of the more common types of corporation is an "LLC". LLC stands for Limited Liability Company.

If the company's owners had unlimited liability for problems the company caused, that wouldn't be much of an LLC, would it? The primary purpose of an LLC is to make it so that the owners (often the founders) cannot personally be held responsible for debts the company incurs, even debts incurred through their instructions.

This also includes debts caused by punishment for the company breaking civil contracts, but doesn't make individuals who use the company to break the law immune to criminal charges. But the standard of evidence for prosecuting that type of malfeasance is pretty high...

The interior of the house is a private space. Things under your clothes are too. Revealing either of these things through whatever technology is a search.

The standard is whether something expected to be private is revealed. What your eyes look like (even in detail) is not that. There isn't a point on some line where the photograph becoming higher-quality applies a different standard than a low-resolution photo would.

No, looking up your face in a list of faces is searching FOR you, not searching you.

Searching you means taking an inventory of the items on your person. It does not mean looking at you. In some cases, imaging you can be a "search" even where there is no physical contact (for example: a millimeter-wave scanner), but a photograph in a public place has never qualified as a "search" in the USA.

I understand your feelings, but so far as I know things like gait recognition, facial recognition, or even an iris scan derived from an ordinary photograph have never qualified as a "search" under U.S. law. Feel free to correct me if I am wrong on this: it's quite difficult to prove something has _not_ happened.

I think the legal line is not when it "becomes biometrics" or becomes identification. The legal line is when you are revealing a private property about an individual (for example, their blood type, or the contents of their pockets). Nothing visible to the naked eye in public is considered private, so nothing that derives identity from that public information is a "search".

As a nice easy example... an officer smelling alchohol on the breath of a person in the course of a conversation is not a "search". An officer compelling that same person to breathe into a breathalyzer machine is. Applying the same standard to faces, you cannot make an individual put their eye to a scanner without reasonable suspicion, but if you can get a biometric scan from the invidual as they happen to walk about their day, doing that isn't searching them...

> Note that absent reasonable articulable suspicion of a crime, law enforcement in the US cannot legally forcibly identify people.

Could you cite a source for this?

If a law enforcement officer personally recognizes someone's face, I don't believe that it's illegal for them to know who the person is.

If a law enforcement officer turns to their non-cop buddy and asks "do you know this person?" and their buddy says "yeah that's Joe", I don't believe it's illegal for them to identify the person that way.

If a law enforcement officer picks up a phone and describes the person's face to their non-cop buddy and the buddy says "that sounds like Joe's face you're describing", I don't believe it's illegal for them to identify the person that way.

You can see where this is going, right? At what point does it become illegal to look up a person's face in a store of the-way-faces-look? Where does that become the "forcible identification" you're talking about?

Generally speaking, people expose their faces in public, and so those exposed faces can be remembered, photographed, and recalled without the person's consent or any warrant. This is legal in the USA - there is no expectation of privacy in a public space, and the police don't have to give you any more privacy than a private citizen would. They just cannot search you - and looking at your face, and potentially recognizing it, is not a search.

This is actually how it works in India with "e-mandates".

In order to set up a recurring bill the merchant must get a "mandate" from the customer, which involves them approving the amount/frequency/term of the payment. The customer can at any time view a list of open mandates on their bank's web site/app and cancel any they wish. Recurring payments only succeed when the mandate remains valid.

The payment amount may be revised downward without getting a new mandate, but raising it up requires replacing the old mandate with a new one.

In order to make a non-initial charge the merchant must pre-authorize it with the bank a few days prior (handing the ID of mandate under which the charge is made to the bank), and pass the confirmation they get back from the bank when they do the real charge. The bank notifies the customer about the upcoming renewal and its amount.

IMO this is exactly how it should work.

> All metaphysical positions are ultimately unfalsifiable

This is not true, there are many metaphysical positions that are falsifiable.

For example, "anything shaped like an apple is an apple" is a metaphysical position. It defines what it means to be apple-ish. You could hold that metaphysical position and also "apples are always made of plant material" as another position you hold at the same time.

Then you could falsify the metaphysical position by presenting a stone carved into the shape of an apple. You could choose to deny reality and change your physical definition (what the definition of the word "apple" is), but if you think logically the evidence constructively falsifies the original metaphysical position.

I think what you might have been trying to say is that people tend to adopt metaphysical positions which are non-falsifiable. Yes, they do, but that doesn't mean no metaphysical arguments can be resolved through logic and experiment.

The only purpose of SEV is to protect a guest against the person who controls the hypervisor.

So this is a threat against SEV.

A "threat actor" can be a company employee who is intentionally permitted to update internal documentation, but not intentionally permitted to change the behavior of an LLM whose context window includes that documentation.

I think it's reasonable for a security conference to talk about how if you put the internal documentation in the LLM context, that means you're elevating the permissions of anyone who can edit the documentation by transitively giving them the ability to instruct the LLM in its "actions" (outputs).

While it should be obvious that's what you're doing, I would say most people I talk to about LLMs do not understand that all parts of the context window together shape LLM output, and there is no such thing as "only obey instructions from the system prompt".

They are copied from a thumb drive the person applying the exploit creates.

With PIV, the private keys are stored inside the smartcard (a Yubikey is just one type of smartcard) and don't leave it. They're used for encryption/decryption by the host.

Yes, it's generally sound, and is the primary means of authentication and encryption used by the US military for classified systems.

It does not. The files are copied to the recovery image, not the machine's encrypted drives.

If Microsoft wanted a backdoor, there is no need to hide it in the official Windows Recovery Environment image.

Just sign an alternate version of the recovery environment that doesn't bother displaying a login screen. Done - you can access any TPM-only Bitlocker setup freely. This is actually LESS risky than keeping the exploit in the publicly-available version of WinRE, because you don't have the risk of pesky security researchers finding your backdoor.

Hanlon's Razor and Occam's Razor both say this is probably a bug that lets you use some kind of early-boot filesystem-corruption-fixing code on the recovery image to break the login screen and leave the disk unlocked by accident. It deletes itself because it's, well, intended to be a filesystem fix log, and the log gets deleted when it's done being replayed so it doesn't happen a second time!

I don't think any of the attacks being discussed are actually attacks on the TPM's own threat model.

I think they're attacks on Windows' measured boot approach.

> That's not how it works. The KEK is not stored inside the TPM, but encrypted/decrypted by the TPM.

No, the KEK is stored inside the TPM, and the DEK is decrypted by it. If you have three layers (two KEKs, one encrypted with the other) then sure. But at the end of the day one private key is actually stored inside the TPM, taking up as much space as the length of the key.

To be specific, Bitlocker uses a stored key, not a derived key.

> Bitlocker does that. Cryptenroll doesn't (https://github.com/systemd/systemd/pull/27502), which is bad but has not been fixed.

I don't think Bitlocker does that, because it's possible to set up admin PIN recovery techniques. That would be impossible if the PIN were part of the KEK.

> - The KEK should also depend on the PIN. Cryptpentroll does not do this at all and Bitlocker limits the PIN to 20 characters.

I agree.

> There are various manufacturers of TPMs and all of them have different implementations. Some of them had been broken in the past, which is why it's important to make secrets PIN-dependent.

I agree. Perhaps consider using a FIDO2 token (supported by cryptsetup) instead of a TPM. There are open-source implementations of FIDO2 and open-hardware ones too. There are even open-source implementations of FIDO2 where the key is in fact derived from the user's PIN (plus a stored secret). If you did that, you get the proper security properties even without cryptsetup mixing the two methods.

> I seriously doubt the author found a way to bypass PIN protected setups in general.

I agree - I think the author probably just found a flaw in the windows recovery environment and is talking up how a PIN only helps you if the attacker does not know your PIN (in other words, acting as if the PIN provides no threat resistance when really it provides an additional layer).

> As of this moment, I would rather look at it as a convenience feature. A high entropy password + a proper KDF (not possible on Windows) like scrypt or argon2 is the better choice. Encryption should be handled by SoC engines like on Macs, iPhones or some Android phones to mitigate other attacks and preserve performance anyway. Panther Lake CPUs with vPro support do on Windows.

I think the best you can do right now is to layer a password with a hardware device. I don't think saying that the hardware devices are flawed means they are not useful as PART OF the security setup. It would certainly be nice if the software did this automatically/easily and it's unclear to me why it does not.

I gave three ways in which encrypting a disk using a TPM provides advantages over encrypting the disk using a secret password.

Encrypting the disk using a secret password provides advantages over encrypting the disk using a public password.

Encrypting the disk using a public password again provides advantages over not encrypting the disk (such as being able to securely "delete" data by removing the data encryption key).

I agree with your core point that attempting to use measured boot and secure boot to control whether the disk can be decrypted is full of holes. But if you want the computer to have an encrypted drive and to be able to boot up without a network or human intervention, what are your options really?

That does not match up with the way this exploit works.

An un-exploited system is booted with a modified version of the Windows Recovery Environment.

Like I said, I think the not-well-described problem here is that (effectively) the lock screen on Windows RE is not secure, so you can have a PCR match in the TPM, but then access the disk as an administrator without typing the admin's user account password. That's not a vulnerability of the TPM itself, and it's not some kind of persistent exploit. It's a flaw in the Windows RE.

I'll also point out it grants access to do only what Microsoft themselves could do at any point. Anyone who has the ability to make a validly-signed copy of Windows could break into a TPM-locked Bitlocker setup exactly this way. People who use Bitlocker without a PIN are implicitly accepting that risk.

There are two ways to "use a PIN".

Since there's a ton of misunderstanding in this thread, I'm going to go into how disk encryption works conceptually.

First, there's a symmetric key to encrypt blocks on the disk. Since you want to be able to change your unlocking password/mechanism without re-encrypting everything on the disk, this has nothing to do with unlocking the disk. This is what you want to get BY unlocking the disk. Let's call this the "data encryption key".

Then, there's something you use to encrypt the data encryption key. Let's call this the "key encryption key" (abbreviated KEK from here on in).

When you use a TPM, the KEK is stored inside the TPM. When you use a TPM PIN, the TPM refuses to release the KEK for use by the OS unless that PIN is provided.

You could say "why not make the KEK be a hash-mixed combination of a PIN and something inside the TPM?". One could do that! But that's not how Bitlocker works. There is a reason it doesn't work that way: the TPM is supposed to let company admins in charge of the device access it even if the original PIN is forgotten, by using other policies letting them get at the KEK. I personally set my own devices up such that the passphrase IS part of the KEK itself.

Interestingly, LUKS does not have a composite key mode natively that lets you combine a password with TPM material, but there are some good reasons not to use JUST a password:

1. The strength of your disk encryption reduces to the strength of the password, where a TPM can have a 256-bit truly random key

2. If someone keylogs the password, or tricks you into disclosing it, they can later decrypt your drive from anywhere, where a TPM binds the attack to those with posession of the TPM

3. There is no protection against brute force attacks (rate limiting), where a TPM does - or tries to - impose a rate limit

Now, let's go on to what YellowKey attacks.

A TPM can have inside itself "registers", called PCRs. These PCRs can be updated but not reset - think of it like you can add numbers to them but not subtract, and they only go back to zero when you reboot.

Using a passwordless encrypted boot, the TPM is configured to only release the key when the PCRs are in the exact correct state. As the OS boots it adds numbers to those PCRs. If you boot "the wrong" software, the numbers in those registers won't match the expectations, and you cannot unlock the disk.

Speculation on my part: the reason there's an exploit here is that the Windows Recovery Environment apparently can match the PCR values for the booted OS, causing the TPM to release the key, but WinRE doesn't require you to get your password right before it gives you access to the data. So far as I know, protecting the TPM key with a PIN would mitigate this issue, but it's still bad.

Or maybe the exploit actually does something inside the TPM itself, causing it to unconditionally release the key even when protected by a PIN: that would be even worse, but **NOT*** a problem with Windows. That would be a problem with the TPM.

Their strategy WAS GamePass - get a bunch of users accumulating huge collections of inexpensive-but-high-value games, paid for via a subscription (rented), that are only playable on Windows (enforced via Microsoft's own software and an account login). Use loss aversion to prevent the users from letting their subscriptions lapse.

They made a tactical mistake by trying to directly monetize the GamePass subscription instead of having it remain a purposefully-underpriced vendor lock-in mechanism. Whoops.

Wireguard has no key distribution mechanism.

You can use software like Headscale/Tailscale/Netbird on top.

That site doesn't mention that when DNSSec is absent, the behaviour of SSH is identical to what happens if you hadn't used the SSHFP record at all, except that for unsophisticated attackers it also displays "no matching host key found in DNS".

So even without DNSSec using the SSHFP records is an improvement over not using them because some of the time it tells you for certain you're being interfered with.

There is no situation in which an insecure DNS response is auto-trusted by the SSH client.

Believe it or not, email service providers actually exist.

Rollernet.us is a good one. They have excellent deliverability, reasonable prices, and everything you could want related to email.

They have a few minor other services, like DNS management, but they are not a cloud compute provider.

Another option is to use a cloud compute provider like AWS. You don't need to run the VM yourself to use SES for email messages. The hard part is the webmail access: you have to choose between a poor interface (an S3 bucket) or running a managed VM to host something like Roundcube.

I recommend reading the description of the option `VerifyHostKeyDns` in the `ssh_config` man page.

If set to `yes`, you get automatic trust-on-first-use (no user prompt) if you use DNSSec, and you get the current asking-the-user behavior if your DNSSec is broken or you are under attack.

Obviously it's more secure if you use DNSSec, because that way you can reflexively deny any request to manually verify a host key, but it provides value regardless.

SSH has *ANOTHER* built-in solution, in the form of the SSHFP DNS record.

If the DNS record for the host has an SSHFP (SSH FingerPrint) record, SSH will compare it to the retrieved public key(s) and refuse the connection if there is a mismatch. It can be configured to require DNSSec for this, or to only reject if it gets a secure rejection (to prevent DoS).

It works perfectly, has no notable down sides (just add a DNS record when you generate the host's SSH key), and has been around for many years.

There is already plenty of open hardware, it's just not this-year's-top-performance.

In the category of ~1-3 years' performance lag you get Rockchip and friends, which are closed hardware that allows open computation. See computers made by the company MNT as an example.

In the category of ~5 years' performance lag you get "soft" cores, where you buy an FPGA (dynamically reprogrammable hardware) and make it run a CPU you design yourself. If you want to, for example, make your CPU have more cache and fewer ALUs, you can do that by tweaking some files and reprogramming the FPGA. This has a cost in terms of power efficiency and runtime speed, but you can absolutely run a full Linux desktop experience on an FPGA today, and the hardware has no way to try to prevent you from running any software.

You can solve the problem of all the cellular basebands being closed source with either software-defined-radio or using a closed USB/PCIe cellular modem connected to an open processor.