Does CryptPad meet Document Collaboration requirements?

Why should this tool be removed?

Hi,

I see CryptPad being recommended as Document Collaboration tool:

It seems that it doesn’t meet Minimum Requirements though, namely:

Must have sync clients for Linux, macOS, and Windows.

Is that a mistake in how criteria are worded? Or perhaps some disclaimer should be added to CryptPad’s reccommendation?

Cheers!

1 Like

CryptPad is a web-based tool and should be compatible with the platforms you mentioned as long as your browser could run CryptPad.

1 Like

It is a web service and therefore cross-platform to that extent. I don’t think the tool should be removed for that. If anything, we should suggest a change in the min. requirements or add a clarification for why we are including it even though it has no non-web client.

1 Like

@TinFoilHat
@anonymous492
Being able to edit documents on multiple platforms is one thing.

But I think equally important is to have a possibility to sync (and backup) these documents on client’s machine. Especially when public CryptPad instance is used.

Finally, web-browser-based clients are subject to malicious JavaScript code being served, as described, as described in Common Threats - Privacy Guides :

Therefore, you should use native applications over web clients whenever possible.

I get that sometimes it’s better to recommend some tool, even if it is far from ideal. But for Privacy Guides to maintain credibility - I think such flaws should be transparently, and clearly emphasized.

2 Likes

You can always download the documents. But for shared documents, keeping local backup and sync is suboptimal. And honestly, the threats with JS are very theoretical. I haven’t seen any real-world case where such attack was performed.

1 Like

Oh I see. I understand why you are concerned now.

I initially interpreted your post as asking whether we should we remove the service to arbitrarily align with the criteria, but you’re instead saying that the criteria should be enforced for security purposes. If that’s the case, I’ll let others speak on that. I’ve no idea about that stuff.

so your concern can basically alsdo apply to any other services using web app, this is just simply broad (now I thought you said about removing, that’s what I disagree with, a warning may be fair enough but it will have to be applied broadly)

I’ll shout-out @Encounter5729’s sentiment that while it is a risk, it isn’t something we’ve seen happened or reported out in the wild and it isn’t a huge concern, malicious javascript is the least of worries at this point, I’d be much more concerned if it was targeted

You can also self host cryptpad or use stuff like nextcloud with onlyoffice if viable

1 Like

CryptPad is an online “ONLY” tool, I don’t think the “SYNC” requirement is applicable to online only tools. It offers backup / export feature, which ensures data portability, I think it is good enough and should be the bar for online tools.

Javascript injection requires a compromised browser to happen, it is an endpoint security issue , it has nothing to do with the online tool itself.

If the endpoint is compromised, nothing can really save you, no matter it is web based or native application.

1 Like

I think you misunderstand the concerns with malicious JavaScript and web based cryptography. The issue is that the data might indeed be encrypted, but the service if it is compromised can add a malicious JavaScript file to the page which exfiltrates the data after it is decrypted. The threat would be a compromise to the service, not the browser. And it is a significant concern because the whole point of end to end encryption is that you don’t have to trust the service provider, but without a native client updated out of band from the data (as opposed to a web app where the app and data are both served in real time by the service) the entire trust model of E2EE goes out the window.

I don’t think this is worth removing them, though. Probably just worth adding a note about it for people to make up their own minds. I don’t think that is a concern for everyone’s threat model.

2 Likes

I think it’s better to change the criteria so we aren’t all over the place with “exceptions.”

I think this post should be about a criteria change. Or maybe someone else can make a new post for that and a mod can migrate the off-topic replies there. As it stands, cryptpad doesn’t fit the criteria we have, and there seems to be contention about what the criteria should be as well. This should be resolved before we talk about adding or keeping cryptpad.

IMO it’s either we

  • keep the criteria and remove cryptpad (I don’t personally agree with this),
  • keep the criteria and clarify that cryptpad is an exception (exceptions are annoying though and can get messy over time),
  • make cross-platform clients a best case criteria as opposed to a minimum criteria (which doesn’t make sense IMO and would introduce a lot of unwanted, OS-specific services),
  • or add an exception within the criteria that a web service is exempt from cross-platform clients requirement (but again, this is contentious and is being debated in this thread).
1 Like

Agreed. To clarify, I meant a note about the risks in addition to removing it from minimum requirements.

Another similar option is to make it a minimum requirement that if there are native clients and it is not a web-only service then the clients would be cross platform, and a separate best case requirement that a service is not web-only with an explanation of the risks posed by web-only E2EE.

1 Like

Seems to be the most sane option. I don’t think Cryptpad should be removed simply because it is web-based, so the criteria should be changed to reflect that. And yet, as you all said, web-based encryption is a valid attack vector. It seems to be only briefly mentioned on the website. Adding a full-fledged knowledge base article about it, then linking it under Cryptpad (along with other relevant web-based encrypted services) seems to be the way to go.

1 Like