That comment seems off-topic, but just to exemplify:
In your example even as the interface for those products is unstable (UI that changes all the time, slightly broken API), those products are coded in a language like C++ or Java, which benefit from compiler error checking. The seams where it connects with other systems is where they're unstable. That's the point of this blog post.
I've always found system administration much harder than "coding". You get parser and compiler errors for a lot of your mistakes, but administering a server you're testing it all at runtime.
Don't you get any errors even if you race immediately to start pivot_root? pivot_root also won't modify all open file descriptors at once. Seems it's not fatal, but have you managed to do this over ssh and not be disconnected?
I don't know what you mean regarding pivot_root affecting file descriptors because they are not modified, they point to new names because the enclosing directory has been moved/renamed. There is a small race between moving items in the root directory as well as after moving all items and before starting pivot_root, but that race doesn't involve file descriptors but opening at the old paths before the new one is established, though lots of things use openat() these days so it doesn't really even occur in most cases then.
I didn't know file descriptors worked like that admittedly. Also instead of moving the files couldn't we copy them to the new root and pivot_root then?
This is because LLMs don't actually understand language, they're just a "which word fragment comes next machine".
Instruction: don't think about ${term}
Now `${term}` is in the LLMs context window. Then the attention system will amply the logits related to `${term}` based on how often `${term}` appeared in chat. This is just how text gets transformed into numbers for the LLM to process. Relational structure of transformers will similarly amplify tokens related to `${term}` single that is what training is about, you said `fruit`, so `apple`, `orange`, `pear`, etc. all become more likely to get spat out.
The negation of a term (do not under any circumstances do X) generally does not work unless they've received extensive training & fining tuning to ensure a specific "Do not generate X" will influence every single down stream weight (multiple times), which they often do for writing style & specific (illegal) terms. So for drafting emails or chatting, works fine.
But when you start getting into advanced technical concepts & profession specific jargon, not at all.
But they must have received this fine-tuning, right?
Otherwise it's hard to explain why they follow these negations in most cases (until they make a catastrophic mistake).
I often test this with ChatGPT with ad-hoc word games, I tell it increasingly convoluted wordplay instructions, forbid it from using certain words, make it do substitutions (sometimes quite creative, I can elaborate), etc, and it mostly complies until I very intentionally manage to trip it up.
If it was incapable of following negations, my wordplay games wouldn't work at all.
I did notice that once it trips up, the mistakes start to pile up faster and faster. Once it's made a serious mistakes, it's like the context becomes irreparably tainted.
Sure that could be done but you have to do it manually every time and write a script to automate it for each host you connect to, then remember to change those when/if you have some new filesystem you want to bring over, then you have to put them in the $PATH on the remote machine every time, gracefully, so that when it comes time to disconnect, everything knows to unmount automatically before you disconnect from SSH. It’s an enormous pain in the ass to try to get SSH to do all of this correctly every time.
The cpu command does it all gracefully, and it’s already written, it even works on Linux.
The other comments are correct, but let me try for a different phrasing, because it's a complex topic. You have two parts for attestation: The hardware provides the keys and computation for the measurement state that you can't change as a user. The software provides the extra information/measurements to the hardware.
That means you can't simulate the hardware in a way that would allow you to cheat (the keys/method won't match). And you can't replace the software part (the measurements won't match).
It all depends on the third party and the hardware keys not leaking, but at long as you can review the software part, you can be sure the validation of the value sent with the response is enough.
I understand hardware attestation at this level, it's why you couldn't route a hardware attestation from a different machine, that's not the one the user cares about, that I'm working on understanding.
Because to obtain the result of attestation, you'd need to actually run the prompt on the verified machine in the first place. (And in practice the signature would be bound to your response as well)
The attestation report is produced after the user sends a prompt to the LLM? I thought it was the proof the correct model weights are loaded on some machine.
The attestation report is produced ahead of time and verified on each connection (before the prompt is sent). Every time the client connects to do an inference request via one of the Tinfoil SDKs, the attestation report is checked relative to a known-good/public configuration to ensure the connection is to a server that is running the right model.
The attestation is tied to the Modelwrap root hash (the root hash is included in the attestation report) so you know that the machine that is serving the model has the right model weights
The certificate is embedded with the HPKE key accessible only inside the enclave. The code for all this is open source and part of the measurement that is being checked against by the client.
So if the provider attempts to send a different attestation or even route to a different enclave, this client side check would fail.
Is this certificate a TLS certificate? At least the TLS connection the user has should be with the "enclave", not a proxy server. If the connection is with a proxy server, the user can be MITM'd.
Yes, it is a TLS certificate generated by the enclave on boot (the code responsible for doing this is open source and the attestation is also included in the certificate so you can check that this is exactly what’s happening). We go into more detail in our attestation verification docs here: https://docs.tinfoil.sh/verification/attestation-architectur...
The provider cannot chose the attestation that is sent, the hardware assembles the attestation through mechanisms that it cannot control. That why it's called "trusted hardware" technology, you only need to trust the hardware (how it was implemented), and you don't need to trust the provider operating it.
I don't know, but archive sites could at least publish hashes of the content at archive time. This could be used to prove an archive wasn't tampered with later. I'm pretty underwhelmed by the Wayback Machine (archive.org), it's no better technically than archive.today.
How do you ensure the tampered content isn’t re-hashed? Usually if you’re saving the hash in advance, you can save the whole archived page. Otherwise, you can use a regular archive service then hash the archived page yourself.
The only way I know to ensure an archive isn’t tampered is to re-archive it. If you sent a site to archive.today, archive.org, megalodon.jp, and ghostarchive.org, it’s unlikely that all will be tampered in the same way.
A list of hashes (tuple of [hashed url+date metadata, hashed content]) takes much less disk space than the archive contents themselves. Archive websites could publish the list for all their content so it can be compared against in the future. People would save copies of the list. If you didn't store the list yourself ahead of time, and don't trust a third-party to be "the source of truth", the archive could've uploaded the hashes to the blockchain at archive time:
> is that there is a public forum post in which a guy claims to be the site owner.
Which forum post? The post mentioned by the blogger, the post on an F-Secure forum (a company with cybersecurity products) was a request for support by the owner of archive.today regarding a block of their site. It's arguably not intended as a public statement by the owner of the archive, and they were simply careless with their username.
reply