A European alternative to Google Docs that won't read your files
xwiki.com
xwiki.com
Now, we’re bringing that same privacy-first approach to businesses with CryptPad Enterprise. It’s a self-hosted, end-to-end encrypted alternative to Big Tech’s office suites, designed for teams that care about privacy, security, and data sovereignty. With governments and companies across Europe looking for ways to move away from US-based cloud services, solutions like this are becoming more relevant.
We’re hosting a webinar to talk about how it works, the technical challenges of scaling encrypted collaboration, and what’s next. If you’re interested in privacy-first infrastructure, join us:
> The fragment of a URI is the last part of the URI, starting with the # character. It is used to identify a specific part of the resource, such as a section of a document or a position in a video. The fragment is not sent to the server when the URI is requested, but it is processed by the client (such as the browser) after the resource is retrieved.
https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...
Though I'm not sure exfiltration is actually prevented since extension scripts can still run in the page context.
As a sidenote, that's actually one significant benefit of the "Manifest V3" Web Extension model – it's possible to grant these permissions on a per-site basis. (For example, you can allow uBlock Lite script injection access only on some sites, and limit it to declarative network request blocking otherwise.)
When you go to say Google Docs, you're retrieving JS from _not_ your stuff. That JS (theoretically) can be altered to send back unencrypted data back to Google Docs.
The point they were making is that in this scenario you've self-hosted the JS and so it's not going to be altered to send back unencrypted data because you yourself aren't going to do that alteration.
---
Sure in both scenarios if you have an extension that uploads the content of the page it doesn't matter but there are more threat scenarios that apply to JS served from not your server than from your server.
That is one of the privacy dangers of cryptpad, and it's not particularly far-fetched. Specifically with shared documents, one needs to trust that every extension every user who visits your document has installed is non-malicious in order to have an assurance that only approved people will see those docs.
Of course this is a browser-based consideration that would affect shared docs on any browser-based platform, but as a privacy-focused app I think it's fair to consider modes of failure inherent in it being a browser-based app. Signal and other Desktop applications, by contrast, wouldn't have these same risks (and Cryptpad could similarly bundle its client as an electron-based app to provide better security).
However, anyone using a browser like Chrome, Safari, or Edge that has cloud syncing will be sending this URL to the respective browser manufacturers, which means you're still handing over the documents to Google (or Apple, or Microsoft)
Edit: Actually just looked and I can't find any information indicating Edge sync is e2e encrypted except for enterprise accounts. So beware of that browser if you weren't already.
Edit: it looks like e2ee is an option, though it's not the default, and Google goes out of their way to make this inconvenient for users: https://palant.info/2023/08/29/chrome-sync-privacy-is-still-...
But unless you're able to ensure that all users of your cryptpad documents have e2ee configured with a strong password, it's likely that Google will see the URLs with decryption keys to your cryptpad docs. It only takes one weak link...
Safari does use different types of encryption for open tabs and history vs. bookmarks (the former E2E, the latter depending on whether the account is using ADP), and I believe Firefox is completely E2E (based on the Mozilla password) by default, but I can't find a description of what Chrome does in details.
Specifically, enabling Chrome's end-to-end sync encryption opts the account out of history sync. I can't think of any reasonable explanation for that other than Google wanting to discourage its use.
The FISA request writes itself.
I'm saying that in addition to this, Google, Microsoft, and Apple will be able to read your Cryptpad documents because they'll have the URL with the decryption key. The only thing putting the key in the fragment portion of your URL accomplishes is ensuring that the cryptpad server itself (which you control anyway if you're self-hosting) can't access the data
What do you do about copyright or CSAM?
If the client needs to implement the search index on its own, why even have a service? What benefit does the service bring?
If I need to host the search index myself, that makes a much more vulnerable target for surveillance or attack, compared to a centralized service which has a dedicated security/privacy team. I would need to roll my own security, or trust the vendor. We are back to square one.
Just wait for some fuck up story or news that data wasn't actually encrypted on provider part - yes, that already happened in some "encryption provider".
Or maybe teach managers for routine darknet checking to find if their data are already there ? :>>
Just because that's the easiest solution if you already have the data unencrypted on the server side doesn't mean it's the only one.
> What benefit does the service bring?
It allows synchronization between clients, online collaboration, and serves as an automatic backup. That's basically everything I want from most document cloud services!