I'm not really sure i want to continue the conversation unless you retract this. Our team is working hard on many fronts and does not deserve to be treated like that.
If you believe it's critical that the "link situation" be resolved, where is the pull request, or even the specification of the necessary change ?
Ludovic
I attempted to disclose the issue responsibly (in other words, not as a github issue), and urged you to make passwords mandatory for documents, or at least default with a prominent warning displayed for users foregoing the password. The response I received indicated that Cryptpad didn't consider this to be a vulnerability, but that you'd welcome changes to improve documentation.
You asked where my PR was: I gladly would submit one if I didn't expect it to be closed based on the response I had received prior, but I don't think documentation changes would cut it.
I wasn't intending to make this personal and I definitely wasn't saying that you (or your team's) motivations were unambiguously malicious or deceptive. My last paragraph was perhaps overly dramatic, but my impression is that Cryptpad positions itself as a general-purpose e2ee document collaboration suite, and one of the use cases I associate with that positioning, one of the less strict ones if I'm honest, would be something like:
> empower laypeople to collaborate on documents with reasonable confidence that nation-state actors won't be able to passively surveil those documents.
which is a much softer use case to satisfy than, say, providing halfway-decent protection from active, targeted surveillance (the space I believe Signal to be in, and also the space I'd love Cryptpad to be in)
So if those aren't among the kinds of things y'all think about when designing Cryptpad, then I'd appreciate if you made your overall project goals and use cases more explicit. Of course there are other valid reasons to desire document security, they're just not ones I tend to spend as much time thinking about.
Our main promise to our users is that server operators cannot read the users data.
About code alteration attacks, we have mentioned them here in an article exposing ways to use CryptPad in secure ways https://blog.cryptpad.org/2024/03/14/Most-Secure-CryptPad-Us...
I won't respond in detail, at least today, to all your criticism of our work but I will say two things:
CryptPad might not be at the level of privacy or security you want (which one do you want BTW ?), but with such discourse you are sending users to stay handling their data on Google which seems to be the opposite of what you seem to want. We will of course consider on our end that CryptPad greatly enhances privacy and security compared to the situation where everybody's data is in clear at Google or Microsoft.
You mentioned " I did share all of the above with the CryptPad team, and was told they don't intend to address the above issues". If you can dig out our response it would be helpful ? At least my position as CEO is that we intend to solve the issues we can solve with the funding we have. As an example, we have always been interested in finding a solution to the "code attack". However the desktop app or code signing does not fully solve the issue as you still need to trust who builds the desktop app or signs the code, even when signed. Full trust requires audit of the code at every change. Can you name me one app that you can fully trust ? Have you audited it ?
I'm not saying improvements cannot be done and we'd love to do a desktop app but we have to choose our battles. We would still have to see if people install and use it ? Signal is a mobile app.. How many have it on their computer ? How many use slack instead ? (When a billionaire gives 100M$ to CrytpPad, we'll be happy to have our choices challenged compared to those of Signal). If one is listening our OpenCollective is here https://OpenCollective.com/cryptpad
We'd love to do more both for privacy and security and ease of use, but for that we need more funding.
Our belief is that privacy and security will be won again on the Internet step by step by getting users to any non BigTech tools including CryptPad and then improve them step by step. If we have the users, we have higher chances to have the funding to improve the tools.
Your vision seems to be more extreme and would likely fail to bring anybody to such a platform as it would lack ease of use (at least with the level of funding we have).
Until now, your criticism is not helping getting the users out of Google or Microsoft.
Ludovic, CEO of XWiki SAS
So to be clear, for very specific purposes I'm thinking of, I don't know that it's even better for users to use Cryptpad (without document passwords) than to use Google, etc, that's how bad it is.
This is conjecture on my part, but I'm assuming a user information request which asks for all of a user's cloud documents is considered broader than a request for a user's browser URL history scoped to one URL, and therefore the former is less likely to be granted, even though the latter can grant access to all of the cryptpad documents a user has accessed via share link.
And even if the above conjecture doesn't hold, the latter request would be much more likely to reveal sensitive information, which is why I think it's so dangerous that nation-state actors can access e.g. Chrome Users' cryptpad documents at least as easily as those same users' Google documents.
> CryptPad might not be at the level of privacy or security you want (which one do you want BTW ?), but with such discourse you are sending users
Ideally both, and to be clear, I'm recommending people who need secure document collaboration to use cryptpad only with document passwords. Even though I'd really like to be able to recommend Cryptpad without that caveat, I think we can all agree Cryptpad with a password is probably going to be more secure from third-party access than Google Docs.
> You mentioned " I did share all of the above with the CryptPad team, and was told they don't intend to address the above issues". If you can dig out our response it would be helpful ? At least my position as CEO is that we intend to solve the issues we can solve with the funding we have. As an example, we have always been interested in finding a solution to the "code attack". However the desktop app or code signing does not fully solve the issue as you still need to trust who builds the desktop app or signs the code, even when signed.
It was ticket 9SNPEQVkca if you're interested. I did offer some ideas on mitigating extension-based exfiltration attacks and server compromise, though your team may have already had some similar ideas in the past.
I completely understand the issues of funding. The nice thing about Cryptpad being an open source project is that community members such as myself can also make contributions towards improvements, though the roadmap still lives and dies with the company, because people generally aren't going to work on features/fixes that maintainers won't merge.
The signing issue is a fair one also. The fact is coordinating releases for extensions, desktop apps, mobile apps adds a lot of work that might be prohibitive with current resources. Mobile app stores can also be annoying gatekeepers. At least publishing apps as open source makes it so users can build their own version at any point if they'd like, and then actual version updates could be fewer and further between.
> Full trust requires audit of the code at every change. Can you name me one app that you can fully trust ? Have you audited it ?
I mean trust is really something we grant in degrees. But I do often look at software I use, and that's how I came to recognize the issues with Cryptpad I ended up reporting.
> Signal is a mobile app.. How many have it on their computer ?
I realize there are many mobile-only users, but among the people I know. it's very common to primarily use the Desktop app. Of course, their whole device syncing story opened up some issues, so...[1]. But I do tend to agree with them that delivery as a traditional server-hosted web app opens up additional avenues for exploit which the app distributor can't mitigate against. Perhaps these will be mitigated with updates to the CSP and resource integrity standards in the future, but right now there is more control over Desktop apps
> (When a billionaire gives 100M$ to CrytpPad, we'll be happy to have our choices challenged compared to those of Signal). If one is listening our OpenCollective is here https://OpenCollective.com/cryptpad
I would love to see more funding for Cryptpad, and Signal for that matter. Both could really use bug bounties also.. can those be crowd sourced?
> Our belief is that privacy and security will be won again on the Internet step by step by getting users to any non BigTech tools including CryptPad and then improve them step by step. If we have the users, we have higher chances to have the funding to improve the tools.
> Your vision seems to be more extreme and would likely fail to bring anybody to such a platform as it would lack ease of use (at least with the level of funding we have).
Signal has sacrificed ease of use in favour of security by refusing to release a web app for some time.. they're doing pretty OK in terms of number of users. I think it's also fine to choose a different balance and favour ease of use more, but concessions to security based on your team's priorities should at least be acknowledged.
> Until now, your criticism is not helping getting the users out of Google or Microsoft.
My criticism of Cryptpad is intended to raise awareness of the issues, so that users and prospective users can make more informed decisions about what technologies are appropriate for their concerns
And honestly if people are turned off of using cryptpad because of an issue I'm highlighting, that's also an indication of what needs to be improved to win those users back.
[1] https://www.bleepingcomputer.com/news/security/russian-phish...