I agree, chat is only useful in scenarios that are 1) poorly defined, and 2) require a back-and-forth feedback loop. And even then, there might be better UX options.
Conceptually, you nailed it with the last mile. You want to tie the runtime service's attestation report to the provenance that was generated at build time (and signed by the attested build environment). You can do this by including a copy of it with the service and serving it directly; or the build environment can publish it to a place where clients can later look it up using the Confidential Computing service's attestation measurements.
There is always going to be a gap between local-first processing and what can be achieved in a full-sized datacenter/cloud. That leads to the risks mentioned in the article.
I wrote about Apple's Private Cloud Compute last year; for the foreseeable future, I still think server-side Confidential Computing is the most practical way to do processing without huge privacy risks: https://www.anjuna.io/blog/apple-is-using-secure-enclaves-to...
>The full user tree is public and each user's profile shows who invited them. This provides some degree of accountability and helps identify voting rings.
For a single community like Lobsters, you don't need the digital signatures part at all.
Keybase https://keybase.io/ has a feature to help you aggregate different identities/accounts, though I'm not sure how active it is after their acquisition by Zoom in 2020.
Confidential Computing also provides data-in-use protection and has a significantly more realistic overhead, often <10% in real-world workloads I've seen. However, in this case you might want to combine it with customer managed keys (BYOK) or self-hosting anyways - otherwise the customer has no opportunity to perform remote attestation and prove you're really running in Confidential Computing.
The visualization about halfway down https://www.anjuna.io/solution/secure-ai (my employer) is an example of the self-hosted flavor of this. Happy to discuss deeper, my contact info is in my bio.
Nice writeup. Since she mentioned how hard it is to learn these conventions, I'll plug my preferred reference when thinking about CLIs specifically (rather than TUIs and REPLs) - the Command Line Interface Guidelines https://clig.dev
It does include the blog post's rules on exiting on Ctrl-C, accepting `-` for stdin, disabling color in pipes, and much more.
I would also recommend, call to attention, the Further Reading from CLIG, https://clig.dev/#further-reading. POSIX, GNU, Unix resources, Heroku CLI guide, and 12-factor CLI app guide.
>A surviving spouse, surviving divorced spouse, unmarried child, or dependent parent may be eligible for monthly [Social Security] survivor benefits based on the deceased worker’s earnings.
AWS Nitro (and Nitro Enclaves) are general computing platforms, so it's different. You'd need to write a PCC-like system/application on top of AWS Nitro Enclaves to make a direct comparison. A breakdown of those 5 core requirements from Apple:
1. Stateless computation on personal user data - a property of the application
2. Enforceable guarantees - a property of the application; Nitro Enclaves attestation helps here
3. No privileged runtime access - maps directly to the no administrative API access in the AWS Nitro System platform
4. Non-targetability - a property of the application
5. Verifiable transparency - a mix of the application and the platform; Nitro Enclaves attestation helps here
To be a little more concrete: (1 stateless) You could write an app that statelessly processes user data, and build it into a Nitro Enclave. This has a particular software measurement (PCR0) and can be code-signed (PCR8) and verified at runtime (2 enforceable) using Nitro Enclave Attestation. This also provides integrity protection. You get (3 no access) for "free" by running it in Nitro to begin with (from AWS - you also need to ensure there is no application-level admin access). You would need to design (4 non-targetable) as part of your application. For (5 transparency), you could provide your code to researchers as Apple is doing.
(I work with AWS Nitro Enclaves for various security/privacy use cases at Anjuna. Some of these resemble PCC and I hope we can share more details about the customer use cases eventually.)
I do not disagree with your points, but the NCC audit is not compelling. They only interviewed engineers and didn't audit the code or how it is deployed.
I wrote about this here: https://digitalseams.com/blog/the-ideal-ai-interface-is-prob...
reply