We (a University, in India) are trying to get out of the Google ecosystem, and CryptPad is the greatest thing that has happened to us.
Google has been whittling the 'Google for Education' now and the free version called 'fundamentals' has been stripped of many things and we can see the future where the cost of using Google might be a significant impactful expenditure on our tight, already stretched to the limits budget.
Also, the word, 'Crypt' is cool.
Our teachers feel like Hackers.
Seriously - that was some of the great feedback we received.
Not OP, but I feel like moving from Google to Zoho is just kicking the can down the road. You don't know how these big corporations will change their product or (more importantly for cash strapped organisations like Universities) their pricing structure.
It seems like a much safer to bet to move to an open source project instead. The costs of hosting it would be well known and predictable.
I have been working on an essay about 'Personal Digital Infrastructures,' a concept of infrastructure that seeks resilience and durability for personal data at a level we typically only see in banks or state institutions. In other words, an infrastructure that can protect your personal data in the face of disasters such as big tech account cancellations, fund blocking, imprisonment, bankruptcy, death, etc. The flagship instance of Cryptpad is the service that comes closest to this idea of infrastructure. The free plan gives you 1GB of storage for files, which is more than enough to store essential data for the continuity of businesses, families, communities, etc. E2E encryption plus zero trust in a free tier is something that should be valued and used to our advantage. Cryptpad is a very powerful resource and should be more appreciated.
Cryptpad is all right though it locks you into Cryptpad. If you want to extract your documents you have to use their UI to decrypt them. What I am looking for is a document interface that works with Syncthing. Let syncthing handle the syncing and encryption.
We hope to be able to give an API in the future but there are a few concerns to allow sync tools to operate:
- server load and volume of data when syncing large volumes of data, especially for our flagship instance. CryptPad is currently used for realtime editing not for large data sync. We already host 6TB of data and it's unclear were that would lead us.
- version compatibility with apps not upgraded to the latest version of the API
These are similar reasons that kept us away from federation.
Our team is small and already a lot of work. Hiring is limited by our funding.
I feel you, but Drive is borderline useless and I can't sell any potential users on "you put all your data here but documents go there (but it still looks like you could put other stuff here but that's an illusion) unless you manually export them and then everything gets weird" - I'll count myself lucky if I can finish the sentence before they renew their existing cloud service.
Synching is for syncing your files across several devices of yours. CryptPad is for working with other people, possibly at the same time on the same document.
The tools donc comapte, the needs are very different, and you might find them both useful in different situations.
It seems to me syncthing simply doesn't need anything more, you just use the desktop application of your choice for editing your documents.
And yes, you are kinda locked into CryptPad if you don't export your documents as you go. The server not having your documents at a central place and all the documents having different decryption keys means it's hard to provide a simple "take out" zip export. I guess some automation tool accessing your browser profile could be built to help with this.
The problem is cryptpad pretends to solve the problem with its "drive", but it's just a (not very) fancy browser for your documents. I can't make a folder with a cryptpad document in it and also all the reference material I want to use. Or any other workflow that involves multiple kinds of files of different types. Manually copying over everything between cryptpad and syncthing is a consistency nightmare.
One option for you that's half way there is to use Obsidian on top of markdown files and sync those with Syncthing.
Obsidian has many of the rich editing capabilities, especially when you install plugins. For plus points the files are very portable and there is (almost) no "vendor lock in" because it's all markdown textfiles.
I love this setup. I've now synced between my phone and laptop, with a backup on a cloud server, and it deserved a post on my fledgling blog: https://blog.sahil.ink/obsidian-and-syncthing/
I'm building a plugin for Obsidian called Relay that makes Obsidian real-time collaborative [0].
It isn't end-to-end encrypted (yet), but you can self host the document collaboration server on a private network (like tailscale).
If you're like me and you need real-time collaboration and privacy but e2ee isn't a strict requirement for your collaborative docs then you might enjoy it.
I also use Obsidian sync for e2ee device sync -- it is a fantastic product.
I came across cryptpad as cryptpad.cz but couldn't figure out who was behind it at the time. At least with this link you can get to at least one seemingly legit dev, which makes me take it more seriously. Is cryptpad.cz a fork of this or vice versa?
I feel like side needs to be precised a bit. Although it admittedly doesn't generate nearly as much revenue as XWiki, several people are paid full time to work on it, and it receives public grants. It is an important project for XWiki SAS.
Do you know of any publicized auditing done on the E2E aspect of it? Curious about that since it's part of the name and a prominent publicized feature.
Thanks. Isn't vouching for other online instances a bit risky? Wouldn't you have to constantly verify the source is unmodified in an automated fashion for those instances you don't control?
So, basically any local productivity tool, saving files in a synced folder.
While this works, Syncthing does not really provide anything for fine-grained collaboration or sharing (you only share full folders). Encrypted peers do allow storing files on a machine that you don’t have to trust.
What are you looking for? I used to use Notational Velocity in an encrypted volume hosted on Dropbox, but I ended up switching to Obsidian for the mobile support.
I’m not actually looking, Syncthing solves 90% and I’m hard pressed to believe anyone needs live document collaboration outside of an office context that screensharing doesn’t already solve. Most of the time when everyone “collaborates”, only 1-2 people of the group are doing the typing.
Unfortunately, most users don't know how to setup the tools you are talking about. Additionally they end up having to share some document at some point or another. They end up with browser based tools and a shared server. Google most of the time for individuals. Most users want their data in one place for all use cases.
Network effects make it so that only tools that allow you to invite anybody to your document (guests without accounts included) end up gaining traction. Desktop apps might be able to achieve this using some web proxy so who knows, it might change in the future.
Our goal at CryptPas is to make it familiar for them to move from Google while having e2ee here to protect their privacy, which also gives them a reason to switch
The more people can get out, to any open alternative, the more alternatives can then decide to fight each other.
In the mean time, we should not try too much to get the rest of the world on our own workflow, just let all the different approaches strive.
BTW maybe CryptPad's API ( https://github.com/cryptpad/cryptpad-api-examples ) could help you solve the case where you do need to edit a document collaboratively from your computer. Would you be interested in a tool allowing to create a session for editing with CryptPad allowing to sync back changes or save the end result back to your computer ?
I had to export all of our documents and sheets out of Google Drive. I used something called Google Take Out, that packages everything and puts it somewhere where you can download zip files. It took a few days for it to be available. Except it didn’t do what it said it did. It didn’t export even half the files. I unpacked and compared with what was online.
In the end I had to download folders by hand. Took me half a day. And make sure they weren’t too big, because then it wouldn’t include everything.
You have to download everything in your Drive to your local system first, then unzip it all, but then you can upload the entire folder to CryptPad.
Google isn't going to make it easy for a competitor to transfer content, and I'd rather the CryptPad devs work on the product and not a feature users will each only use once at most.
The only annoyance I had was "converting" the uploaded files to the "native" CryptPad format. It doesn't actually have a different native type, it just seems to be a registering with the CryptPad internals which of its predefined types the file is (E.g. Document, Presentation, etc). And you don't have to do it for the file to open and edit just fine. But you have to open each file "as <Type>" from the right click menu, then save it back out and delete the "original" to convert it.
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.
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.
> 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"
Well, that's certainly what tools like CryptPad and Signal target: privacy for the non expert.
OP' points are right, and I hope they get addressed at some point.
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.
Your last paragraph is quite insulting to the work we do, suggesting intention to trap people ? Did I read this right ?
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 ?
I think the work you've done with cryptpad, while impressive on many levels and, I'm assuming, motivated by a desire to make secure document collaboration more accessible, is actually putting people at increased risk due to how bad this issue with the share URLs is.
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.
Seems like Microsoft and Google employees have joined the room.
They might as well complain that cryptopad isn't secure because it is connected to electricity all the time. They'll never be satisfied, fortunately they are also relatively easy to spot.
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)
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.
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.
I tried cryptpad and it was good, with the main issue being inviting new users is really complicated. Users needed to register and then send their own "invite me" link, because the system encrypted their email address, so you can only use the link to invite them.
This turned out too complicated for normal people (ok for computer users)
The normal way to invite people to a CryptPad document is to give them the shared link. No need to register or involve emails. Then, they just need to follow the link and it should just work. CryptPad is specifically designed with nontechnical users in mind, because if you want something to be secure, it needs to be simple, and it is not desirable for privacy to be limited to technical users only.
Sorry I should have been more specific, I was trying to invite a user to a team (can't remember the right terminology) so that they could read and write into a directory, creating as many document as they wanted.
We are a small team of 5, but I'm the only tech-able person, other older users felt extremely disoriented.
Which is frustrating, because to me Cryptpad did everything we needed in a very, very secure way (all encrypted)
Note that you can also invite people by sending them a link to a document and then connect to them from the user sidebar. They don't really need an account to access documents.
The main reason for the lack of simpler invitation using email is that we don't really want users to give us the mail of other users to invite. This goes against the "privacy" we are promising users.
We are essentially a group of people (home-owner association but for condos, in Canada). None of these are tech people, they also might not own a computer, but just a tablet and a phone.
The main issue was trying to invite them to a team. I had all their email addresses already, because our main form of communication is email, but I had to go to them one by one and ask them for a link (ID? I can't remember) to give to me so that I could invite them.
Essentially, I get the privacy concern, but I already had all their email addresses, so it was protecting data and making a workflow more complicated, for a use-case we didn't have.
We even implemented links that can be used multiple times before an expiration date.
Concerning the privacy of emails, YOU had the emails, but the SERVER ADMIN does not.. To send an email from the server, the server would need to receive the emails in clear.
As a side note, when you invite somebody to a service by letting the service send the email, you are leaking their email to that service, so to be respectful of people's privacy, we should not send the invite without their consent receive first. I get that nobody does that and there is a sort of implicit consent and that the risks of misuse of the email ate low.. If we ever implement that feature we would have to show a warning.
I understand that, but in this case the server admin and myself were the same people, on my home server, so there wasn't anything leaking anywhere really.
That being said, this was about a year ago. Invite links that you can send manually by email and people can join the team would be more than sufficient, I don't need the system to send the email for me, I just need an invite link.
The problem was the reverse, I needed each user to send me an ID (I think it was an Id) so that they could be invited.
yep i've played with cryptpad and honestly it's wild how much comes down to people stubbornly sticking with the default tools - you think we ever get to a point where open options like this really catch on outside techy circles or will it always be a niche thing
I really appreciate that the team hasn't rested on their laurels with just creating an encrypted cloud-based OnlyOffice wrapper and they've actively pushed I to the space of filling tool gaps. Their markdown files are a nice addition for a simple note that doesn't need to be a full Document.
Honestly my primary peeve with Cryptpad is the incredible load time... which is justified in scenarios of private documents, but completely unjustified in every single time someone shares a Cryptpad link with me which is certainly intended for public consumption.
Cryptpad is E2E encrypted. At a first glance, this is not.
Which also means its features won't be constrained by the E2EE architecture.
At a first glance, it seems the suite numerique wants to be simpler than full traditional office documents. It seems to compare itself with notion and outline.
CryptPad has very simple modules and also more complex, OnlyOffice based modules.
Ultimately, if the suite numerique's frontend is able to send editing patches as JSON, it should not be too complicated to make it work on a CryptPad server and make it E2EE, which is exactly what the CryptPad team did to OnlyOfficr (the "why not both" option)
It would not really make any sense to try to take all Docs in CryptPad, as Docs is both client and server code. The client has both and editor but also sharing features.
CryptPad integrates editors.
However Docs is based on BlockNote for the editor and this editor has been on our watchlist to replace our aging CKEditor which is used in CryptPad. This would make sense to integrate in CryptPad.
As it was said CryptPad is e2ee which is a LOT of work. Then it has 9 types of document files (Docs has 1). CryptPad also has a drive. It also has shared folders, team drives, import and export features and finally also a Survey Tools with e2ee protection. There are many more little or larger details.
Of course as a part of the Cryptpad team you have a bias, but if I'm looking to replace Google Drive and its functionality, is Cryptpad a good replacement, or is there another one, maybe Nextcloud(?), that could do it better (just user interaction etc wise, not E2EE)?
Would you have a list of things Cryptpad can and can't do compared to other solutions? It would make choosing the best replacement easier.
When cryptpad was first launched, MS Office was very much a desktop product and Google was the web first collaboration platform. That's obviously because (a teeny bit) less true.
In the AI age having all of your files in markdown and away from AI enabled providers is making more and more sense.
I know of several AI companies who use bespoke tools because otherwise their data would be shared with their competitors (e.g. notion -> openai, gdocs -> google, etc).
It used to be that putting your docs on google "felt" safe because it was unlikely that some random google employee would read you random company docs. Now it seems unlikely to me that they aren't reading every doc with AI.
We (a University, in India) are trying to get out of the Google ecosystem, and CryptPad is the greatest thing that has happened to us.
Google has been whittling the 'Google for Education' now and the free version called 'fundamentals' has been stripped of many things and we can see the future where the cost of using Google might be a significant impactful expenditure on our tight, already stretched to the limits budget.
Also, the word, 'Crypt' is cool. Our teachers feel like Hackers.
Seriously - that was some of the great feedback we received.
Cryptpad has been around for a couple years, IIRC. It's useful, but it's not like it was created last month.
May I ask why not Zoho?
Not OP, but I feel like moving from Google to Zoho is just kicking the can down the road. You don't know how these big corporations will change their product or (more importantly for cash strapped organisations like Universities) their pricing structure.
It seems like a much safer to bet to move to an open source project instead. The costs of hosting it would be well known and predictable.
Which is funny because if you want lock-in there's no better way than to offer end-to-end encryption.
Does it prevent you from exporting the data, changing the vendor, changing the application?
I think you have a wrong view of „lock-in“
I have been working on an essay about 'Personal Digital Infrastructures,' a concept of infrastructure that seeks resilience and durability for personal data at a level we typically only see in banks or state institutions. In other words, an infrastructure that can protect your personal data in the face of disasters such as big tech account cancellations, fund blocking, imprisonment, bankruptcy, death, etc. The flagship instance of Cryptpad is the service that comes closest to this idea of infrastructure. The free plan gives you 1GB of storage for files, which is more than enough to store essential data for the continuity of businesses, families, communities, etc. E2E encryption plus zero trust in a free tier is something that should be valued and used to our advantage. Cryptpad is a very powerful resource and should be more appreciated.
Is there a Google Keep alternative?
In the Cryptpad service? No. Not with the same UX. But you can keep simple markdown notes in it.
Cryptpad is all right though it locks you into Cryptpad. If you want to extract your documents you have to use their UI to decrypt them. What I am looking for is a document interface that works with Syncthing. Let syncthing handle the syncing and encryption.
I'm from the CryptPad team.
We hope to be able to give an API in the future but there are a few concerns to allow sync tools to operate:
- server load and volume of data when syncing large volumes of data, especially for our flagship instance. CryptPad is currently used for realtime editing not for large data sync. We already host 6TB of data and it's unclear were that would lead us. - version compatibility with apps not upgraded to the latest version of the API
These are similar reasons that kept us away from federation.
Our team is small and already a lot of work. Hiring is limited by our funding.
Ludovic
I feel you, but Drive is borderline useless and I can't sell any potential users on "you put all your data here but documents go there (but it still looks like you could put other stuff here but that's an illusion) unless you manually export them and then everything gets weird" - I'll count myself lucky if I can finish the sentence before they renew their existing cloud service.
Hey Ludovic, just to give a shout of appreciation for your hard work over the years.
Keep rocking!
Synching is for syncing your files across several devices of yours. CryptPad is for working with other people, possibly at the same time on the same document.
The tools donc comapte, the needs are very different, and you might find them both useful in different situations.
It seems to me syncthing simply doesn't need anything more, you just use the desktop application of your choice for editing your documents.
And yes, you are kinda locked into CryptPad if you don't export your documents as you go. The server not having your documents at a central place and all the documents having different decryption keys means it's hard to provide a simple "take out" zip export. I guess some automation tool accessing your browser profile could be built to help with this.
The problem is cryptpad pretends to solve the problem with its "drive", but it's just a (not very) fancy browser for your documents. I can't make a folder with a cryptpad document in it and also all the reference material I want to use. Or any other workflow that involves multiple kinds of files of different types. Manually copying over everything between cryptpad and syncthing is a consistency nightmare.
One option for you that's half way there is to use Obsidian on top of markdown files and sync those with Syncthing.
Obsidian has many of the rich editing capabilities, especially when you install plugins. For plus points the files are very portable and there is (almost) no "vendor lock in" because it's all markdown textfiles.
I love this setup. I've now synced between my phone and laptop, with a backup on a cloud server, and it deserved a post on my fledgling blog: https://blog.sahil.ink/obsidian-and-syncthing/
I'm building a plugin for Obsidian called Relay that makes Obsidian real-time collaborative [0].
It isn't end-to-end encrypted (yet), but you can self host the document collaboration server on a private network (like tailscale).
If you're like me and you need real-time collaboration and privacy but e2ee isn't a strict requirement for your collaborative docs then you might enjoy it.
I also use Obsidian sync for e2ee device sync -- it is a fantastic product.
[0] https://relay.md
Or just use Obsidian's built-in E2E encrypted syncing.
https://obsidian.md/sync
But yeah, since it stores everything as flat markdown files, you can sync or archive your Obsidian docs folder with anything.
I came across cryptpad as cryptpad.cz but couldn't figure out who was behind it at the time. At least with this link you can get to at least one seemingly legit dev, which makes me take it more seriously. Is cryptpad.cz a fork of this or vice versa?
cryptpad.cz seems to be one of the many instances of CryptPad. I don't know who is behind.
CryptPad.org is the official website of the project (and cryptpad.fr an instance maintained by the original devs).
CryptPad is developed by XWiki as a side project.
I feel like side needs to be precised a bit. Although it admittedly doesn't generate nearly as much revenue as XWiki, several people are paid full time to work on it, and it receives public grants. It is an important project for XWiki SAS.
(I work for XWiki, on XWiki though)
Do you know of any publicized auditing done on the E2E aspect of it? Curious about that since it's part of the name and a prominent publicized feature.
I'm from the CryptPad team
There is our white paper on the security features of CryptPad: https://blog.cryptpad.org/2023/02/02/Whitepaper/
In terms of audits, we don't have the funding for formal audits but a couple years ago the European Community paid a bug bounty https://commission.europa.eu/news/european-commissions-open-...
We received some interesting reports but not as much on the cryptography than on web related issues
Ludovic
Thanks. Isn't vouching for other online instances a bit risky? Wouldn't you have to constantly verify the source is unmodified in an automated fashion for those instances you don't control?
So, basically any local productivity tool, saving files in a synced folder.
While this works, Syncthing does not really provide anything for fine-grained collaboration or sharing (you only share full folders). Encrypted peers do allow storing files on a machine that you don’t have to trust.
I don't need anything from Syncthing for fine grained collaboration, the text editors do that.
What are you looking for? I used to use Notational Velocity in an encrypted volume hosted on Dropbox, but I ended up switching to Obsidian for the mobile support.
I’m not actually looking, Syncthing solves 90% and I’m hard pressed to believe anyone needs live document collaboration outside of an office context that screensharing doesn’t already solve. Most of the time when everyone “collaborates”, only 1-2 people of the group are doing the typing.
I'm from the CryptPad team
This workflow works for you ! Great !
Unfortunately, most users don't know how to setup the tools you are talking about. Additionally they end up having to share some document at some point or another. They end up with browser based tools and a shared server. Google most of the time for individuals. Most users want their data in one place for all use cases.
Network effects make it so that only tools that allow you to invite anybody to your document (guests without accounts included) end up gaining traction. Desktop apps might be able to achieve this using some web proxy so who knows, it might change in the future.
Our goal at CryptPas is to make it familiar for them to move from Google while having e2ee here to protect their privacy, which also gives them a reason to switch
The more people can get out, to any open alternative, the more alternatives can then decide to fight each other.
In the mean time, we should not try too much to get the rest of the world on our own workflow, just let all the different approaches strive.
BTW maybe CryptPad's API ( https://github.com/cryptpad/cryptpad-api-examples ) could help you solve the case where you do need to edit a document collaboratively from your computer. Would you be interested in a tool allowing to create a session for editing with CryptPad allowing to sync back changes or save the end result back to your computer ?
Ludovic
I've been a heavy Google Docs/Sheets/etc user since they launched almost two decades ago (2006).
I've exported to structured formats a handful of times, out of thousands of documents.
CryptPad really should build this though.
I had to export all of our documents and sheets out of Google Drive. I used something called Google Take Out, that packages everything and puts it somewhere where you can download zip files. It took a few days for it to be available. Except it didn’t do what it said it did. It didn’t export even half the files. I unpacked and compared with what was online.
In the end I had to download folders by hand. Took me half a day. And make sure they weren’t too big, because then it wouldn’t include everything.
Also no easy way to import everything from Google drive.
You have to download everything in your Drive to your local system first, then unzip it all, but then you can upload the entire folder to CryptPad.
Google isn't going to make it easy for a competitor to transfer content, and I'd rather the CryptPad devs work on the product and not a feature users will each only use once at most.
The only annoyance I had was "converting" the uploaded files to the "native" CryptPad format. It doesn't actually have a different native type, it just seems to be a registering with the CryptPad internals which of its predefined types the file is (E.g. Document, Presentation, etc). And you don't have to do it for the file to open and edit just fine. But you have to open each file "as <Type>" from the right click menu, then save it back out and delete the "original" to convert it.
Onboarding is a big one time feature to get users to first value.
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.
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.
> 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"
Well, that's certainly what tools like CryptPad and Signal target: privacy for the non expert.
OP' points are right, and I hope they get addressed at some point.
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.
Your last paragraph is quite insulting to the work we do, suggesting intention to trap people ? Did I read this right ?
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 think the work you've done with cryptpad, while impressive on many levels and, I'm assuming, motivated by a desire to make secure document collaboration more accessible, is actually putting people at increased risk due to how bad this issue with the share URLs is.
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.
Seems like Microsoft and Google employees have joined the room.
They might as well complain that cryptopad isn't secure because it is connected to electricity all the time. They'll never be satisfied, fortunately they are also relatively easy to spot.
...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).
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)
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-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
Hello! Any thoughts on integrating with Nextcloud?
Thanks for the response.
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...
https://elpa.gnu.org/packages/crdt.html
is much more fun and, obviously, vastly more powerful.
I tried cryptpad and it was good, with the main issue being inviting new users is really complicated. Users needed to register and then send their own "invite me" link, because the system encrypted their email address, so you can only use the link to invite them. This turned out too complicated for normal people (ok for computer users)
The normal way to invite people to a CryptPad document is to give them the shared link. No need to register or involve emails. Then, they just need to follow the link and it should just work. CryptPad is specifically designed with nontechnical users in mind, because if you want something to be secure, it needs to be simple, and it is not desirable for privacy to be limited to technical users only.
What did you want to achieve?
Sorry I should have been more specific, I was trying to invite a user to a team (can't remember the right terminology) so that they could read and write into a directory, creating as many document as they wanted.
We are a small team of 5, but I'm the only tech-able person, other older users felt extremely disoriented.
Which is frustrating, because to me Cryptpad did everything we needed in a very, very secure way (all encrypted)
Hi,
I'm from the CryptPad team.
This is an interesting feedback.
Note that you can also invite people by sending them a link to a document and then connect to them from the user sidebar. They don't really need an account to access documents.
The main reason for the lack of simpler invitation using email is that we don't really want users to give us the mail of other users to invite. This goes against the "privacy" we are promising users.
Ludovic
Hi! Thank you for answering this.
We are essentially a group of people (home-owner association but for condos, in Canada). None of these are tech people, they also might not own a computer, but just a tablet and a phone.
The main issue was trying to invite them to a team. I had all their email addresses already, because our main form of communication is email, but I had to go to them one by one and ask them for a link (ID? I can't remember) to give to me so that I could invite them.
Essentially, I get the privacy concern, but I already had all their email addresses, so it was protecting data and making a workflow more complicated, for a use-case we didn't have.
It might have been a long time ago because we have invitation links in teams:
https://forum.cryptpad.org/d/5-improve-onboarding-for-teams
We even implemented links that can be used multiple times before an expiration date.
Concerning the privacy of emails, YOU had the emails, but the SERVER ADMIN does not.. To send an email from the server, the server would need to receive the emails in clear.
As a side note, when you invite somebody to a service by letting the service send the email, you are leaking their email to that service, so to be respectful of people's privacy, we should not send the invite without their consent receive first. I get that nobody does that and there is a sort of implicit consent and that the risks of misuse of the email ate low.. If we ever implement that feature we would have to show a warning.
Ludovic
I understand that, but in this case the server admin and myself were the same people, on my home server, so there wasn't anything leaking anywhere really.
That being said, this was about a year ago. Invite links that you can send manually by email and people can join the team would be more than sufficient, I don't need the system to send the email for me, I just need an invite link.
The problem was the reverse, I needed each user to send me an ID (I think it was an Id) so that they could be invited.
yep i've played with cryptpad and honestly it's wild how much comes down to people stubbornly sticking with the default tools - you think we ever get to a point where open options like this really catch on outside techy circles or will it always be a niche thing
I use CryptPad all the time and it rocks!
I really appreciate that the team hasn't rested on their laurels with just creating an encrypted cloud-based OnlyOffice wrapper and they've actively pushed I to the space of filling tool gaps. Their markdown files are a nice addition for a simple note that doesn't need to be a full Document.
There are other free instances available, for example cryptpad.digitalcourage.de is used by many people I know.
See cryptpad.org/instances for a list.
Honestly my primary peeve with Cryptpad is the incredible load time... which is justified in scenarios of private documents, but completely unjustified in every single time someone shares a Cryptpad link with me which is certainly intended for public consumption.
We have started working on that.
The load time currently depends on the size of your drive/share folders etc..
Public links are now bypassing some actions. We hope to bypass more in the future
Ludovic
How does this compare with the French/German https://github.com/suitenumerique/docs ?
Cryptpad is E2E encrypted. At a first glance, this is not.
Which also means its features won't be constrained by the E2EE architecture.
At a first glance, it seems the suite numerique wants to be simpler than full traditional office documents. It seems to compare itself with notion and outline.
CryptPad has very simple modules and also more complex, OnlyOffice based modules.
Ultimately, if the suite numerique's frontend is able to send editing patches as JSON, it should not be too complicated to make it work on a CryptPad server and make it E2EE, which is exactly what the CryptPad team did to OnlyOfficr (the "why not both" option)
I'm from the CryptPad team.
It would not really make any sense to try to take all Docs in CryptPad, as Docs is both client and server code. The client has both and editor but also sharing features.
CryptPad integrates editors.
However Docs is based on BlockNote for the editor and this editor has been on our watchlist to replace our aging CKEditor which is used in CryptPad. This would make sense to integrate in CryptPad.
As it was said CryptPad is e2ee which is a LOT of work. Then it has 9 types of document files (Docs has 1). CryptPad also has a drive. It also has shared folders, team drives, import and export features and finally also a Survey Tools with e2ee protection. There are many more little or larger details.
Ludovic
Thank you for the reply!
Of course as a part of the Cryptpad team you have a bias, but if I'm looking to replace Google Drive and its functionality, is Cryptpad a good replacement, or is there another one, maybe Nextcloud(?), that could do it better (just user interaction etc wise, not E2EE)?
Would you have a list of things Cryptpad can and can't do compared to other solutions? It would make choosing the best replacement easier.
Why is this dubbed as an alternative to Google suite and not Microsoft suite? They even used the Microsoft icons.
I'm from the CryptPad Team.
We did not use this sentence. It's the person that posted this that wrote 'Google'
However we believe CryptPad can be part of the solution for both Google and Microsoft
Now the targets are different. Google has most of individuals and B2C. Microsoft is more the larger companies
At this point CryptPad seems to have more tracking on the individual market.
For companies, there are different approches like self-hosting. E2EE in companies is a niche market for which collaborative editing is new.
So 'Google' as an exit-target is probably yo the right goal
I think because it's web-based only, much like Google Docs and the like are. For my Cryptpad replaced Google Docs as a live-collaboration tool.
While Google is mentioned in some of the user testimonials I don't think the submitter should have added it to the title here.
Realtime collaborative text editing is afaik something Microsoft is not doing.
It is there with Office 365 and VS Code live share. They were among the first to make a complete and commercially successful coediting experience.
The webified version of Office goes back years. It used to be a free add-on to SharePoint and allowed up to 64 simultaneous users per document.
I believe the current Office 365 came from that codebase as it has similar features.
Can you not effectively use it as such, however?
When cryptpad was first launched, MS Office was very much a desktop product and Google was the web first collaboration platform. That's obviously because (a teeny bit) less true.
See also:
https://etherpad.org
[dead]
[flagged]
In the AI age having all of your files in markdown and away from AI enabled providers is making more and more sense.
I know of several AI companies who use bespoke tools because otherwise their data would be shared with their competitors (e.g. notion -> openai, gdocs -> google, etc).
It used to be that putting your docs on google "felt" safe because it was unlikely that some random google employee would read you random company docs. Now it seems unlikely to me that they aren't reading every doc with AI.
This gotta be an LLM
This looks awful, is it from the 90s?