7 ms·

A European alternative to Google Docs that won't read your files

34 points by lorinab 2y ago

lorinab 2y ago
Most online collaboration tools ask you to trust them with your data. Google Docs and Microsoft 365 store your files on their servers, scan your content, and build profiles on users. CryptPad does the opposite. It’s a real-time document editor where everything is encrypted—only you and your team can see what you write. Not even the server can read your files. 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:
- Fire-Dragon-DoL 2y ago
  I like cryptpad and wanted to use it for a team of 6,but the less tech savvy couldn't really understand how it works. The concept that even the user is encrypted is beyond what they could think, so they couldn't understand that I needed their link to invite them
tantalor 2y ago
How does search work, if the files are unreadable? What do you do about copyright or CSAM?
- choo-t 2y ago
  Why would E2EE hinder search ? Any clients could build or update the search index.
  - tantalor 2y ago
    Because that's a job for the service, not the client. 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.
    - Woodi 2y ago
      Because it provide critical part named "hosting" - because everyone is constantly ad'ded to be too moronic to setup their own. "Send your data to us! And pay us! LOL" 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 ? :>>
    - lxgr 2y ago
      Says who? 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!
deleted 2y ago
[deleted]
alwayslikethis 2y ago
But isn't the key just in the url? If the key is sent to the servers in any way, it can be used to decrypt and read the files. I'm not sure that this achieves anything more than a pinky promise of "we won't read your files" because when push comes to shove the keys will be logged and turned over to the authorities.
- voxic11 2y ago
  I haven't used the product but if the key is in the fragment segment of the URL then its not sent to the server. This is a pretty common pattern for these e2e encrypted web apps. > 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/Fragment https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...
  - xnx 2y ago
    Couldn't on-page javascript read the fragment and send that to an endpoint?
    - voxic11 2y ago
      On page javascript could just read the locally decrypted content regardless of how the decryption keys are managed, the key being in the URL doesn't change anything.
      - pcthrowaway 2y ago
        You have to trust the server to not serve a page which will exfiltrate the encrypted data with Javascript (and why wouldn't you if it's self-hosted). Though I'm not sure exfiltration is actually prevented since extension scripts can still run in the page context.

34 points by lorinab 2y ago

Most online collaboration tools ask you to trust them with your data. Google Docs and Microsoft 365 store your files on their servers, scan your content, and build profiles on users. CryptPad does the opposite. It’s a real-time document editor where everything is encrypted—only you and your team can see what you write. Not even the server can read your files. 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:

Fire-Dragon-DoL 2y ago
I like cryptpad and wanted to use it for a team of 6,but the less tech savvy couldn't really understand how it works. The concept that even the user is encrypted is beyond what they could think, so they couldn't understand that I needed their link to invite them

tantalor 2y ago

How does search work, if the files are unreadable? What do you do about copyright or CSAM?

choo-t 2y ago
Why would E2EE hinder search ? Any clients could build or update the search index.
- tantalor 2y ago
  Because that's a job for the service, not the client. 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.
  - Woodi 2y ago
    Because it provide critical part named "hosting" - because everyone is constantly ad'ded to be too moronic to setup their own. "Send your data to us! And pay us! LOL" 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 ? :>>
  - lxgr 2y ago
    Says who? 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!

deleted 2y ago

[deleted]

alwayslikethis 2y ago

But isn't the key just in the url? If the key is sent to the servers in any way, it can be used to decrypt and read the files. I'm not sure that this achieves anything more than a pinky promise of "we won't read your files" because when push comes to shove the keys will be logged and turned over to the authorities.

voxic11 2y ago
I haven't used the product but if the key is in the fragment segment of the URL then its not sent to the server. This is a pretty common pattern for these e2e encrypted web apps. > 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/Fragment https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...
- xnx 2y ago
  Couldn't on-page javascript read the fragment and send that to an endpoint?
  - voxic11 2y ago
    On page javascript could just read the locally decrypted content regardless of how the decryption keys are managed, the key being in the URL doesn't change anything.
    - pcthrowaway 2y ago
      You have to trust the server to not serve a page which will exfiltrate the encrypted data with Javascript (and why wouldn't you if it's self-hosted). Though I'm not sure exfiltration is actually prevented since extension scripts can still run in the page context.