[Terretta]

> the inference provider still has the ability to access the prompt and response plaintext

Folks may underestimate the difficulty of providing compute that the provider “cannot”* access to reveal even at gunpoint.

BYOK does cover most of it, but oh look, you brought me and my code your key, thanks… Apple's approach, and certain other systems such as AWS's Nitro Enclaves, aim at this last step of the problem:

- https://security.apple.com/documentation/private-cloud-compu...

- https://aws.amazon.com/confidential-computing/

NCC Group verified AWS's approach and found:

1. There is no mechanism for a cloud service provider employee to log in to the underlying host.

2. No administrative API can access customer content on the underlying host.

3. There is no mechanism for a cloud service provider employee to access customer content stored on instance storage and encrypted EBS volumes.

4. There is no mechanism for a cloud service provider employee to access encrypted data transmitted over the network.

5. Access to administrative APIs always requires authentication and authorization.

6. Access to administrative APIs is always logged.

7. Hosts can only run tested and signed software that is deployed by an authenticated and authorized deployment service. No cloud service provider employee can deploy code directly onto hosts.

- https://aws.amazon.com/blogs/compute/aws-nitro-system-gets-i...

Points 1 and 2 are more unusual than 3 - 7.

Folks who enjoy taking things apart to understand them can hack at Apple's here:

https://security.apple.com/blog/pcc-security-research/

* Except by, say, withdrawing the system (see Apple in UK) so users have to use something less secure, observably changing the system, or other transparency trippers.

[michaelt]

> 3. There is no mechanism for a cloud service provider employee to access customer content stored on instance storage and encrypted EBS volumes.

Are you telling me customer services can't reset a customer's forgotten console login password?

[Terretta]

In these systems secured to this degree, yes.

[jiggawatts]

My logic is that these "confidential compute" problems suffer from some of the same issues as "immutable storage in blockchain".

I.e.: If the security/privacy guarantees really are as advertised, then ipso facto someone could store child porn in the system and the provider couldn't detect this.

Then by extension, any truly private system is exposing themselves to significant business, legal, and moral risk of being tarred and feathered along with the pedos that used their system.

It's a real issue, and has come up regularly with blockchain based data storage. If you make it "cencorship proof", the by definition you can't scrub it of illegal data!

Similarly, if cloud providers allow truly private data hosting, then they're exposing themselves to the risk of hosting data that is being stored with that level of privacy guarantees precisely because it is so very, very illegal.

(Or substitute: Stolen state secrets that will have the government come down on you like a ton of bricks. Stolen intellectual property. Blackmail information on humourless billionaires. Illegal gambling sites. Nuclear weapons designs. So on, and so forth.)

[avianlyric]

This is hardly a new problem that only appears in the cloud. Any bank that offers a private secure storage facility I.e. a safety deposit box, or anyone that offers a PO Box service is also exposed to the same risk.

But both of these services exist, and have existed for hundreds of years, and don’t require service providers to go snooping though their customer’s possessions or communications.

[bangaladore]

> I.e.: If the security/privacy guarantees really are as advertised, then ipso facto someone could store child porn in the system and the provider couldn't detect this.

But what they would be storing in this case is not illegal content. Straight up. Encrypted bits without a key are meaningless.

There is nothing stopping a criminal from uploading illegal content to Google drive as an encrypted blob. There's nothing Google can do about it, and there is no legal repercussion (to my knowledge) of holding such a blob.

[saithound]

You're simply wrong about this. "I don't know the key" is not legal defense even against hosting an encrypted blob of copyright infringing contemt, much less an encrypted blob of illegal pornography.

[bangaladore]

If this were the case nobody would ever offer file hosting services (eg. Google Drive). Do you have any case history to show any company getting prosecuted for unknowingly hosting encrypted blobs of illegal material?

Obviously if they have to ability to know material is illegal, that's a problem.

And exactly what algorithm can you provide to me that takes an encrypted blob as an input and returns whether it is not illegal material. Clearly that doesn't exist, so your point makes zero sense.

You may be conflating "I forgot the key" vs "I've never been provided the key"

[saithound]

I think you misunderstand jiggawatt, who wasn't talking about unknowingly hosting illegal material.

We're talking about knowingly hosting encrypted illegal material without knowing the key. This is unambiguously illegal whether or not you ever knew the key.

If the police show up and tell you that your site has an encrypted zip file containing illegal porn, of course they can instruct you to stop hosting it, and hold you liable if you refuse to follow those instructions.

They're not going to give you the decryption key to check for yourself, and it'd not even be legal for them to do so.

Jiggawatt is saying that if you have a truly uncensorable system, it's impossible to comply with the police instructions to selectively remove the illegal material, and so the whole thing becomes illegal.

> And exactly what algorithm can you provide to me that takes an encrypted blob as an input and returns whether it is not illegal material. Clearly that doesn't exist, so your point makes zero sense.

This on the other hand, tells me you don't know much about how legal systems work. I recommend you start with the essay "What color are your bits?" [1]

[1] https://ansuz.sooke.bc.ca/entry/23

[bangaladore]

I'm not sure I agree that OCs argument was focused on knowing that you were hosting illegal material that is encrypted. I'd argue that no-where in jiggawatt's comment is that argued. I think that's your argument, which is fine, and I agree with that. I also agree that you can be compelled to remove data, encrypted or not from your servers through lawful orders and if your system is designed in a blockchain like manner where it is not possible to remove illegal content, that's an even bigger issue.

My point all along, is that Google is not liable for someone uploading previously encrypted blobs of illegal content to Google Drive. And even more so, Google isn't liable if someone uploads illegal content to Google Drive that isn't encrypted. Google simply needs to remove it and follow the correct processes if reported / detected.

Could you make an argument for either that theoretically they could be? Sure. But in reality, no, they are not liable.

This is law due to Section 230:

> Section 230 of the Communications Act of 1934, enacted as part of the Communications Decency Act of 1996, provides limited federal immunity to providers and users of interactive computer services. The statute generally precludes providers and users from being held liable—that is, legally responsible—for information provided by another person, but does not prevent them from being held legally responsible for information that they have developed or for activities unrelated to third-party content. Courts have interpreted Section 230 to foreclose a wide variety of lawsuits and to preempt laws that would make providers and users liable for third-party content. For example, the law has been applied to protect online service providers like social media companies from lawsuits based on their decisions to transmit or take down user-generated content.

https://www.congress.gov/crs-product/R46751 https://www.eff.org/issues/cda230

Also, the blockchain problem already exists. I've linked some commentary about it.

https://ethereum.stackexchange.com/questions/94558/what-prev...

[brookst]

You’ve hit on exactly why Apple proposed that client-side, pre-upload CSAM detection which everyone freaked out about.

Instead, iCloud, Google Drive, and similar all rely on being able to hash content post-upload for exactly that reason.

[sublimefire]

Yes but at the end of the day you need to trust the cloud provider tools which expands the trust boundary from just hardware root of trust. Who is to guarantee they will not create a malicious tool update and push it then retract it? It is nowhere captured and you cannot prove it.

[avianlyric]

You can detect and prove it because the hardware attestation signature will change.

You might not know what change was made, or have any prior warning of the change. But you will be able to detect it happening. Which means an operator only gets to play that card once, after which nobody will trust them again.

[7e]

At the end if the day, Nitro Enclaves are still “trust Amazon”, which is a poor guarantee. NVIDIA+AMD offers hardware backed enclave features for their GPUs which is the superior solution here.

[iancarroll]

Aren’t they both hardware backed, just changing the X in “trust X”?

[Terretta]

You think Nitro Enclaves aren't hardware backed?

[almostgotcaught]

be sure to let us know when you can run eg nginx on a GPU in said enclave.

[amelius]

> Folks may underestimate the difficulty of providing compute that the provider “cannot”* access to reveal even at gunpoint.

It's even harder to do this plus the hard requirement of giving the NSA access.

Or alternatively, give the user a verifiable guarantee that nobody has access.

[astrange]

That's what non-targetability is for.