tl;dr - In the modern era of compute, there is expectation that when you say “private” you mean encrypted not permissioned access.
This point can be best made by the first question Gautam asked during the Private Data WG001: Kick Off Meeting. His question arose out of the expectation that “private” conveys something more protective than just access control.
It did not occur to me until this thread, that many of you were use the word “private” when you really meant “permissioned access”.
Why does this matter?
This matter because there will be many like Gautam and me who assume that private means encrypted and selectively disclosed in a way that maximally preserves the privacy nature of the contents.
For example, iCloud is private storage. I can keep my most personal photos there with an expectation that only I can can see them. I can then selectively show them to whom I choose. As of Sept, 2025, there is no way to build a PDS to have this kind of private storage.
I think there is an assumption that a PDS that stores “private data” would operate like iCloud. Even in Pauls leaflet about this, he mentions uses of “personal-private storage” for things like pictures and DMs. A PDS that does not encrypt pictures and DMs is going cause harm to people. So let’s make it clear that a PDS is no place to store this data in the first place.
Instead of opening the door to this unintended harm, I strongly recommend renaming this work effort “permissioned data” not “private data”.
TLDR I think right now the WG includes both those that have encryption as a hard requirement and those that don’t and I think as a broad discussion area it’s ok to be imprecise, especially since the E2EE messaging WG exists.
I think those folks that want an encrypted solution should also convene and coordinate and that we have room to do that here. Do you or @gdey.me want to lead that meeting?
You have good examples in iCloud! I very much aspire to end up in a iCloud like system!
The vast majority of solutions in the wild of apps (aka SaaS stuff in databases) take private to mean access control not encryption.
I also posted that I, personally, don’t think DMs are a good shared use case precisely because I think encryption is a hard requirement for that use case
I want to be super clear, I am not making an argument about the technical requirements for how data should be encrypted or made available. I am saying that if the PDS doesn’t encrypt data (which it won’t anytime soon) and you call it private data, it is going to mislead people to the point of unintended harm.
Paul’s post makes it pretty clear that encrypted data on the PDS is unlikely to be a thing any time soon. So a WG of people can chat about it all they want, but if the PDS doesn’t encrypt data, and we call it “private data” it’s going to mislead people to the point of harm.
This is true and bolsters my concern over this phrase. There is a huge difference between typical SaaS architecture and the PDS architecture. The typical SaaS is a walled garden. So whether or not they encrypt data behind the wall is more opaque and SaaS could reasonably defend against prying eyes without encrypting data at rest. But importantly, there is the implication that there is an attempt to deliver privacy. There is no way to deliver this privacy on a PDS, so don’t call it private.
The PDS in ATProto is a new beast unlike anything that’s ever been built before. It looks and smells like a SaaS component, but it is (currently) being hosted without any of the SaaS protections. So, in the context of a PDS, if it isn’t encrypting data don’t call it “private data”.
Until the PDS architecture can scalably include encrypting data at rest, calling it private data is going to confuse to the point of harm.
Side note: I think it would help keep the conversation more fruitful if we don’t simultaneously talk about E2EE Messaging in the context of PDS private/permissioned data. They have very little overlap other than sharing the phrase “encrypted data”.
My 2¢ is that saying “private data” iff “encrypted” is not a common perspective. Privacy is a spectrum and I believe most people believe their google/microsoft docs are private, but usefully accessible by their docs provider for additional features.
Privacy is a spectrum and means different things to different people in different contexts. One of this WG’s goals is to capture that spectrum, make it accessible on atproto, and communicate to developers and users those options and choices.
I agree that WG naming is bikeshedding for now and perhaps new/sub WGs emerge in time.
(standard) iCloud is a permissioned system in the way that you describe it. Encryption is used (at rest and in transit) per standard infosec practices but is not used to enforce the permissions. Apple’s servers enforce the ACL’s and can choose to grant access to your photos, e.g. if you lose your device and reset your account password, or serve them with a valid legal request. The gap between PDS and iCloud is ACL’s, not encryption.
(advanced data protection) iCloud does use encryption to enforce permissions, since Apple servers do not have access to data encryption keys.
I don’t see how PDS is incompatible with the normal definition of encrypted at rest, which is that the system has access to encryption keys (and consequently, does not provide any permission barrier against the system itself), but the keys are stored separately from data at rest to reduce the attack surface to the key storage rather than all long-term storage.
Sorry to be annoying but I agree 100% with chris’s initial qualm. Particularly given that at least 2 people want more-private data to be a separate workstream (see topic), bikeshedding might be a stitch in time! I would actually recommend naming both WGs something more technical anyways, like “permissioned data” and “oblivious storage” or “e2ee data” since the word “private” has been completely run through by marketing at this point. (Full disclosure i was at the cypherpunk retreat all weekend and no two people meant the same thing by “private” even there…)
Those (“oblivious storage” and “e2ee data”) are more precise terms. My point is that specifying encryption without specifying where the keys are held or, preferably, the expected access boundaries, is a counterproductive exercise.
If the goal is to prevent the PDS from accessing data, let’s come up with shorthand for the security expectation as “encryption” is not synonymous with that, and if anything marketing has normalized its use to describe systems without that guarantee.
I still like “Protected Data” because it’s familiar to any developer with OOP experience, it expresses that the data is not encrypted at rest, but also implies that you need special access to see it.