Security
Every claim below names the mechanism that makes it true, so you can check it rather than take our word for it. What is not built is listed with the same weight, and why.
Community Solid Server answers every request for your data, and it answers an unauthenticated one with 401. That refusal is the access control — not a rule in our application code, which could be bypassed by talking to the server directly.
Sharing writes a Web Access Control document beside the file, naming exactly which agent gets which modes. It is not a folder-wide switch and not a secret link that works for anyone holding it. You can read the document yourself; it is stored next to the resource.
Tick the box when uploading and the file is encrypted before it leaves your device, under a passphrase only you hold. The server stores ciphertext and we cannot read it or recover it. The trade is real and per file: an encrypted file cannot be read by other Solid apps or previewed here, and its contents are not searchable. Its filename is not hidden — encryption protects what is inside a file, never what it is called.
Requests carry a DPoP-bound token rather than a plain bearer token, so a token copied out of a log or a proxy is not usable on its own — the holder also needs the private key it was issued against.
Our robots.txt asks crawlers to stay out of user pods. It is advisory and any client may ignore it. What keeps a pod private is the 401 above; the robots rule only stops well-behaved crawlers wasting everyone's time.
These are decisions and gaps, stated with the same weight as the section above. Two of them are deliberate and will not change; three are simply not done.
Per-file encryption is available and off by default. Encrypting everything is different, and it is a decision rather than a backlog item: it would break Web Access Control and interoperability with other Solid apps, which is the property this product exists to provide. Anything you have not explicitly encrypted is readable by us as the operator.
Web Access Control has no expiry primitive, so an expiring link would have to be faked in our application layer and would not hold against a client talking to the server directly. We would rather say access is until revoked than imply a timer that is not enforced.
Nothing records who read what, and no part of the product will tell you. Building it means server-side logging, a retention decision, and somewhere to read it. Not started.
No external firm has reviewed this. We have not engaged one, and there is no report to publish or summarise.
The Solid Conformance Test Suite has not been run against the deployment. Until it passes, and until interop with a third-party Solid app is demonstrated, we claim compatibility rather than conformance.
Mail us. Please include enough to reproduce it. We have no bug bounty and no formal SLA — if either changes, this page will say so rather than leaving you to infer it.
[email protected]