3 ms·

I think there are some issues with cryptpad, most significantly that documents which are shared via their share link (default way of sharing) will effectively b

I think there are some issues with cryptpad, most significantly that documents which are shared via their share link (default way of sharing) will effectively be shared with Google, Apple, Microsoft, and so on. I think this is dangerous because some users may be under the impression that Cryptpad secures their documents from the prying of big tech's eyes, but since it's guaranteed that at least some document collaborators will be using those companies' browsers, and browser history is synced, the URLs (which contain the key to decrypt the document after the fragment) to any document which is shared with more than handful of cypherpunks will certainly end up shared with the main browser vendors Additionally, they've failed to make some architectural and delivery decisions which would protect users from various attacks like a server compromise (for example, a server seized by an adversary may send malicious client code that conducts a document exfiltration), as well as document exfiltration via a malicious browser extension. Both of these can be mitigated somewhat by delivering the frontend as a desktop app or signed browser extension, and setting reasonable CSPs in the decryption modules. This is exactly the reason Signal doesn't offer a web app. Cryptpad does offer the ability to additionally encrypt documents with shared passwords, and this offers a fair modicum of greater protection against document interception. But this isn't the default document mode, so I doubt most documents are password-protected in practice. I did share all of the above with the Cryptpad team, and was told they don't intend to address the above issues, so I'd recommend against putting to much faith in them for the time being.

rkagerer 1y ago
...and any document which is shared with more than handful of cypherpunks will certainly end up shared with the main browser vendors Can you suggest some best practices those cypherpunks can take to mitigate the weaknesses and use it in a secure fashion? Eg. I don't sync browser history and tend to turn off other cloud-supported features (including "logging into" my browser).
- hmsimha 1y ago
  Regarding the URLs containing the decryption key, of course a strong password is a big benefit here, but if you're not syncing history that could perhaps eliminate big tech from the loop (though you may also need to turn off all telemetry by your browser) Using a browser without extensions installed would prevent against extension-based exfiltration. The only way to prevent against a malicious server would probably be to build the frontend yourself and use it with the server (I haven't tried doing this)
thecrash 1y ago
Your problem statement is effectively "I want to share access to my documents very informally with people who don't care to have any security practices, but still keep them secure" There's another way of sharing in cryptpad though, which is for each user to create an identity/account. Once those you're collaborating with have accounts, documents and folders can be shared by granting access within cryptpad's UI. No secrets have to be circulated.
- hmsimha 1y ago
  I've worked with a few orgs which have used cryptpad, and I'm sorry, but Cryptpad doesn't make it possible to share documents securely unless again, everyone in the org is able to follow security protocol to an exceptionally rare degree. Even you seem to think sharing via identity somehow bypasses the problem, when in fact this just sends them a "notification" with a share link containing the same secret URL (not to mention, as far as I can tell, there's no way for them to add the document to their own drive, so if they want to access it later they either need to save the share link or find it in their notification panel under "notification history" which is super unintuitive). And again, those secrets are stored in your browser history. In a group I was involved with, the workflow was to create documents and share them with others, or put the share link in a Signal group. Even if one were to try to tell everyone in the group that the link should only be opened in a browser that doesn't share its history with its vendor, clicking the link in Signal will happily just open it in which ever browser is configured as your system default anyway. Cryptpad effectively gives you the rope and then ties it into the noose around your neck for you, while you're not looking. Security theater is at best mildly dangerous in a more typical scenario where it's constructed around an application that isn't billed as a secure communication platform. When a tool advertised as user-friendly and privacy-enhancing is the subject of such theatrics, it's even more actively harmful because it instills a false sense of confidence. It would be like a safety helmet that explodes when the user grazes their head. So to recap, if you care about big tech companies gaining access to your secure documents, the only way to use cryptpad in a remotely secure manner, in a group, is either by password protecting all documents with a strong password, or ensuring no one in your org ever opens a document in a browser with history syncing. And honestly, expecting the latter from 99% of groups that might use cryptpad is unreasonable, which is why I'm saying it's irresponsible of Cryptpad to even allow password-less document creation (without so much as showing users a glaring red danger notice beforehand). The users are not primarily to blame for incorrect use of a software that's billed as privacy-preserving, when that software drops them off at the happy path and neglects to tell them, "by the way, we've booby-trapped the door to fire a footgun when opened unless you also turn the smaller knob on the far side with your other hand as you open it." I realize the data exfiltration issues I mentioned are non-trivial to address (though by no means an immense project either), but I can't interpret the link situation as anything other than willful negligence, or worse, a honeypot; consider that users whose adversaries might include nation-state actors (for example, undocumented immigrants sharing resources with one another on how to access services while staying under the radar) are perhaps more exposed, because data brokers are more likely to deny state requests for data that can be seen as overly broad, whereas one specific type of data (browser history) on one domain becomes a pretty tightly scoped request.
ldubost 1y ago
I'm the CEO of the company developing CryptPad. 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-Usage/ 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 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
- knob 1y ago

rkagerer 1y ago

...and any document which is shared with more than handful of cypherpunks will certainly end up shared with the main browser vendors Can you suggest some best practices those cypherpunks can take to mitigate the weaknesses and use it in a secure fashion? Eg. I don't sync browser history and tend to turn off other cloud-supported features (including "logging into" my browser).

hmsimha 1y ago
Regarding the URLs containing the decryption key, of course a strong password is a big benefit here, but if you're not syncing history that could perhaps eliminate big tech from the loop (though you may also need to turn off all telemetry by your browser) Using a browser without extensions installed would prevent against extension-based exfiltration. The only way to prevent against a malicious server would probably be to build the frontend yourself and use it with the server (I haven't tried doing this)

thecrash 1y ago

Your problem statement is effectively "I want to share access to my documents very informally with people who don't care to have any security practices, but still keep them secure" There's another way of sharing in cryptpad though, which is for each user to create an identity/account. Once those you're collaborating with have accounts, documents and folders can be shared by granting access within cryptpad's UI. No secrets have to be circulated.

hmsimha 1y ago
I've worked with a few orgs which have used cryptpad, and I'm sorry, but Cryptpad doesn't make it possible to share documents securely unless again, everyone in the org is able to follow security protocol to an exceptionally rare degree. Even you seem to think sharing via identity somehow bypasses the problem, when in fact this just sends them a "notification" with a share link containing the same secret URL (not to mention, as far as I can tell, there's no way for them to add the document to their own drive, so if they want to access it later they either need to save the share link or find it in their notification panel under "notification history" which is super unintuitive). And again, those secrets are stored in your browser history. In a group I was involved with, the workflow was to create documents and share them with others, or put the share link in a Signal group. Even if one were to try to tell everyone in the group that the link should only be opened in a browser that doesn't share its history with its vendor, clicking the link in Signal will happily just open it in which ever browser is configured as your system default anyway. Cryptpad effectively gives you the rope and then ties it into the noose around your neck for you, while you're not looking. Security theater is at best mildly dangerous in a more typical scenario where it's constructed around an application that isn't billed as a secure communication platform. When a tool advertised as user-friendly and privacy-enhancing is the subject of such theatrics, it's even more actively harmful because it instills a false sense of confidence. It would be like a safety helmet that explodes when the user grazes their head. So to recap, if you care about big tech companies gaining access to your secure documents, the only way to use cryptpad in a remotely secure manner, in a group, is either by password protecting all documents with a strong password, or ensuring no one in your org ever opens a document in a browser with history syncing. And honestly, expecting the latter from 99% of groups that might use cryptpad is unreasonable, which is why I'm saying it's irresponsible of Cryptpad to even allow password-less document creation (without so much as showing users a glaring red danger notice beforehand). The users are not primarily to blame for incorrect use of a software that's billed as privacy-preserving, when that software drops them off at the happy path and neglects to tell them, "by the way, we've booby-trapped the door to fire a footgun when opened unless you also turn the smaller knob on the far side with your other hand as you open it." I realize the data exfiltration issues I mentioned are non-trivial to address (though by no means an immense project either), but I can't interpret the link situation as anything other than willful negligence, or worse, a honeypot; consider that users whose adversaries might include nation-state actors (for example, undocumented immigrants sharing resources with one another on how to access services while staying under the radar) are perhaps more exposed, because data brokers are more likely to deny state requests for data that can be seen as overly broad, whereas one specific type of data (browser history) on one domain becomes a pretty tightly scoped request.

ldubost 1y ago

I'm the CEO of the company developing CryptPad. 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-Usage/ 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 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

knob 1y ago