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).
Project Oak: Meaningful control of data in distributed systems
11–20 of 55 posts
Re: Project Oak: Meaningful control of data in distributed systems
#12The 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 th…
Sounds like Apple’s Private Cloud Compute:
Re: Project Oak: Meaningful control of data in distributed systems
#13A 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.
Re: Project Oak: Meaningful control of data in distributed systems
#14Nice, seems like a more cost-effective alternative to homomorphic encryption
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.
Re: Project Oak: Meaningful control of data in distributed systems
#15How does this relate/compare to AWS Nitro Enclaves? It looks like the same concept, except integrated into Intel and AMD CPUs.
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
Re: Project Oak: Meaningful control of data in distributed systems
#16A 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 ope…
> 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.
Re: Project Oak: Meaningful control of data in distributed systems
#17A 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 ope…
[deleted]
Re: Project Oak: Meaningful control of data in distributed systems
#18A 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 ope…
> 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.
> 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)
Re: Project Oak: Meaningful control of data in distributed systems
#19A 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 ope…
> 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.
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).
Re: Project Oak: Meaningful control of data in distributed systems
#20I 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.