If we assume they can't break full-disk encryption (which is not unlikely), are you certain?

A proper encryption protocol consists of not only the encryption itself, but also authentication, verification and integrity checks. These are for protection against things like replay-attacks and indeed, tampering.

IIRC, booting a laptop with an encrypted FS, normally you'd enter your password, it'd apply a key-generating function (to turn the password into a proper 256bit AES key, or whatever's required), discard the password from memory and then use the key for operating a symmetric cipher (like AES) on the FS's read/write operations.

However, that doesn't quite work, it's not enough to do just that. An encrypted FS also needs authentication and verification, otherwise you open up yourself against all sorts of sneaky attacks stripping your encryption. So AFAIK, the system also keeps checksums and signatures with HMACs or something.

Admittedly, I don't know the exact details. One thing I'm not sure about is if there's the option of having some public/private key available for a bit of assymmetric encryption. Performance-wise you can't afford running that over the whole data stream (but who does that) because it's so much slower than symmetric encryption (which is why we have handshake protocols). But maybe do it once per block (or N blocks), adding cryptographic signatures to whatever's written. Blocks would be timestamped and these timestamps would be included in the signature too[0].

I could imagine, booting, without the password, would give you read-only access. Without password, the FS can only access the public key. The read operation uses this key to check the signatures on whatever blocks it's called to read. The write operation cannot be used to write any valid blocks, because it can't sign them without the private key (you can still trash blocks by overwriting them with invalid data, but you could do that anyways). Booting with a password allows the FS to decrypt the private key, allowing both read and write access.

Basically you'd have an encrypted FS, with the encryption left off but the verification left on.

For a Geeksquad-style attack you even get another layer of protection because without the password, the whole system is read-only. The "evil website put CP in my browser cache" attack is still possible because you'd be logged in, however in that case, at least you got verifiable timestamps on the written blocks, as well as your browser history, that can be analysed to show there was no intent to get, save or view this data.

I think this could be made to work in concept, in theory. Question is if you'd really want to use it though, authenticated verifiable timestamps on all your data, can also be a liability. Because people who "got nothing to hide" are just unaware that even they in fact, do. It means that for whatever you do on your computer, whoever can access the harddisk, can verify that whatever is on it was done by you, and only by you, as well as an undeniable proof of when it was done. That means zero privacy. Forward secrecy won't help here, because the whole point (verifiable authenticated timestamps) is about not having it. It may be nice for certain company laptops, however if it was my own machine, I'd prefer full-disk encryption, get the same protection and the privacy.

[0] while at it, why not also tag it with other metadata, such as origin (local or remote / where) and the process or application that issued the write command