[HN Gopher] Project Oak: Meaningful control of data in distribut...
___________________________________________________________________
Project Oak: Meaningful control of data in distributed systems
Author : tiziano88
Score : 92 points
Date : 2024-08-14 14:00 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| spankalee wrote:
| The lede is a little buried in that README [1]:
|
| ## Sealed Computing
|
| A canonical use of Oak is to build privacy-preserving sealed
| computing applications.
|
| In a sealed computing application, a node (usually a client
| device) sends data to an enclave application (usually a server),
| which processes data without the service provider hosting the
| enclave application being able to see the inputs, outputs, or
| side effects of the computation.
|
| [1]: https://github.com/project-oak/oak?tab=readme-ov-
| file#sealed...
|
| ---
|
| Seems like an attempt at a privacy-preserving alternative to
| running your whole phone OS image on a server?
| warkdarrior wrote:
| But can it deliver ads?
| nrabulinski wrote:
| It's a google project, that's probably the first use case
| they considered
| WaywardGeek wrote:
| Another sealed computing use case that is public: https://d
| eveloper.android.com/about/versions/pie/security/ck...
|
| And this one: https://security.googleblog.com/2022/10/Secur
| ityofPasskeysin...
|
| I've been fortunate to be paid by Google to hide user data
| from Google since 2016. Not many companies would shell out
| anything for this sort of privacy feature.
|
| As for the Oak stack, they win the race. It is the only
| stack that currently provides full hardware attestation
| covering 100% of the code running in the enclave, and 100%
| of it is open-source. There are other good efforts, such as
| CoCo containers with their Key Broker, but so far they only
| cover the initial boot firmware, not the full set of
| software running inside the enclave.
|
| Kudos to the Oak team!
| JimDabell wrote:
| Sounds like Apple's Private Cloud Compute:
|
| https://security.apple.com/blog/private-cloud-compute/
| DaiPlusPlus wrote:
| > When on-device computation with Apple devices such as
| iPhone and Mac is possible, the security and privacy
| advantages are clear: users control their own devices,
| researchers can inspect both hardware and software, runtime
| transparency is cryptographically assured through Secure
| Boot, and Apple retains no privileged access
|
| Waitasec - ZOOM AND ENHANCE!
|
| > users control their own devices
|
| I'll believe that when Apple lets me downgrade my iOS
| version.
| nepthar wrote:
| Honestly, I think it will be used for the reverse (and
| unfortunately more evil) - Google wants to be able to control
| YOUR machine's compute environment for things like playing back
| of DRM'd content. They want a chain of trust that your browser
| cannot be modified to do things like block ads.
| pluto_modadic wrote:
| I was curious if someone would build something that allows the
| DCAP datacenter attestation to be exposed to applications, e.g.
| "prove via intel that the SHA of the software running on the
| machine is XYZ"
| noja wrote:
| Like Signal did for contact discovery?
| https://signal.org/blog/private-contact-discovery/
| bobbiechen wrote:
| >"prove via intel that the SHA of the software running on the
| machine is XYZ"
|
| This is exactly the purpose of MRENCLAVE in Intel SGX remote
| attestation quotes (and similar fields in other TEE platforms),
| and proving the software identity to remote clients is a common
| use case.
|
| Maybe I misunderstand - is that what you mean, or is there
| another use case you are looking for?
| trallnag wrote:
| Nice, seems like a more cost-effective alternative to homomorphic
| encryption
| saagarjha wrote:
| Attestation is to homomorphic encryption as storing things in a
| bank safe is to burying it out in the woods. There's an entity
| providing you service and they're trying their best to
| guarantee that they're not going to decrypt your stuff but
| there's usually some sort of collusion that will make it
| possible.
| blahgeek wrote:
| This seem to be Google's response to Apple private cloud compute
| [1]?
|
| [1] https://security.apple.com/blog/private-cloud-compute/
| dboreham wrote:
| Except the other way around.
| warkdarrior wrote:
| Except that Apple actually uses this privacy stuff. Is
| Project Oak used by Android or Pixel?
| topspin wrote:
| How does this relate/compare to AWS Nitro Enclaves? It looks like
| the same concept, except integrated into Intel and AMD CPUs.
| arianvanp wrote:
| Nitro enclaves is a lot less ambitious than this. This is a
| full blown microkernel. Whilst nitro Enclave is a Linux kernel
| with just virtio drivers enabled + a small initrd containing
| your Linux application. The "Trusted compute base" of nitro
| enclaves is larger.
|
| Nitro enclaves also doesn't have all this high level
| infrastructure of composing microservices like this does
|
| I think (but somebody smarter might correct me) that with nitro
| enclaves you also need to trust Amazon. Whilst with this you
| need to trust AMD, but don't need to trust GCP
|
| Nice thing about nitro enclaves is that the Linux bits aren't
| tied to OCI. E.g. Monzo uses nix to build their enclave images
| https://github.com/monzo/aws-nitro-util
| asterfield wrote:
| Maybe I'm just paranoid, but isn't the (possibly unwritten)
| intent of this project to be able to flip the client and server
| around and run code in your browser and phone? I don't understand
| their incentive to work on this unless they can use it to
| gatekeep "official" youtube clients (for example).
| dboreham wrote:
| Incentive is that there is a small market segment that wants
| "actual privacy" and a concern that this segment could become
| very large at any moment due to publicity/awareness. Nobody
| wants to be caught with their pants down in that event.
| xyst wrote:
| A bit surprised that it's written in rust, rather than Go. I
| suppose rust can take advantage of more low level apis, plus no
| overhead of garbage collection.
|
| edit: love that the community is not silo'd into a proprietary
| chat platform as well:
|
| > We welcome contributors! To join our community, we recommend
| joining the mailing list.
|
| - https://github.com/project-oak/oak?tab=readme-ov-file#gettin...
|
| I really wish more open source projects used mailing lists.
|
| 1) decentralized means of communication
|
| 2) able to join these communities from any type of environment
| (ie, corporate hell hole) without much friction. With discord,
| slack (especially at fortune 500s). It usually involved a whole
| process of approvals to get the damn thing installed and punch a
| hole through the firewall to get access to the service.
|
| No, using a personal email and device for what I consider
| contributing from a work aspect (ie, submitting patch to OSS to
| solve specific problem with project) is not acceptable.
| jb1991 wrote:
| > A bit surprised that it's written in rust, rather than Go. I
| suppose rust can take advantage of more low level apis, plus no
| overhead of garbage collection.
|
| It's security-focused technology. Rust has huge advantages over
| Go in this area.
| filleokus wrote:
| > Rust has huge advantages over Go in this area.
|
| Could you name some advantages? I would agree Rust has huge
| advantages compared to C/C++, and Rust also has a much bigger
| presence in the "security space". But I would say that's more
| because of Rust's lack of GC, smaller footprint which works
| in embedded systems etc.
|
| I guess you could say that Rust's type system being more
| expressive might eliminate certain classes of bugs, which
| have security implications. But "huge advantages"?
|
| (Honestly I'm not flame baiting, I'm genuinely curious if my
| worldview is wrong)
| dijit wrote:
| does it really? aside from a handful of crates and the
| default std hashmap i being slow but cryptographically sound:
| I would not have assumed so.
|
| Go usage inside Google is actually quite low, people talk a
| lot about Go being a google project but in reality its a
| project made by some people who work at Google.
|
| When I last checked it was a bronze supported language (with
| C++, Python and Java being Gold).
| ycombinatrix wrote:
| Python has first class support at Google? Didn't they just
| fire their entire Python team?
| deskr wrote:
| What advantages are those?
| morning-coffee wrote:
| Rust's compiler can prevent data races, for example. (It
| forbids mutation in the presence of aliasing, which is the
| root of it.)
| dijit wrote:
| should be mentioned that Go has optional flags already
| built in to the compiler for detection of data races.
| ycombinatrix wrote:
| should we also mention that C has optional tooling for
| memory safety?
| jb1991 wrote:
| the race detector ( -race ) only detects races that
| actually occur. If they don't happen, then it doesn't
| detect them.
| summerlight wrote:
| I think using Go is not a popular decision in the Android
| ecosystem, especially for those system programming stuffs. It's
| very likely that the project needs tight client side
| integration, so they probably wanted to use a language which
| has a wider support especially in the case of possible iOS
| support.
| topspin wrote:
| The hardware features used for this are Intel and AMD CPU
| extensions: they're writing a microvm to run inside special
| "enclave" virtual machines. Go is a fine language but it's not
| really intended for this sort of work. Rust is a natural fit
| for this work: you can write low level drivers and also ensure
| a number of safety properties.
| moandcompany wrote:
| I think the authors should mention the background story for how
| this project originated at Google in Google Research (UK). Tried
| browsing through the Github project page and didn't see any
| obvious references, aside from the committers list.
|
| AFAIK, the first time I heard about "Project Oak" was about four
| or five years ago.
|
| This predates Apple's Private Cloud Compute.
| ChrisArchitect wrote:
| Some previous discussion:
|
| _2019_
|
| https://news.ycombinator.com/item?id=20265625
| tbrownaw wrote:
| So, something that can be used to run Tor relays that provably
| don't intentionally misbehave? Or hidden services that the
| hosting provider has no way to give other people access to?
| 7e wrote:
| How does this compare with https://github.com/confidential-
| containers?
___________________________________________________________________
(page generated 2024-08-14 23:00 UTC)