5 ms·

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 a

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.
      - lxgr 2y ago
        If you have compromised browser extensions with script injection access, it's game over from a security perspective of any sites you visit. 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.)
        lesuorac 2y ago
        I think you missed the point they were making. 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.
        lxgr 2y ago
        They mentioned extensions though, and I made a comment on that specific attack vector.
        pcthrowaway 2y ago
        Above commenter got it exactly right. Yes, if you've installed extensions with malicious code, your data anywhere can be exfiltrated. 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).
- alwayslikethis 2y ago
  It doesn't seem to be.
  - pcthrowaway 2y ago
    Do you have an example? As per their docs, they do put the encryption key after the '#': https://github.com/cryptpad/cryptpad/blob/main/docs/ARCHITECTURE.md#encryption https://github.com/cryptpad/cryptpad/blob/main/docs/ARCHITEC...
    - alwayslikethis 2y ago
      Oh, I wasn't aware that slashes can follow the #. In that case it seems to be. Thanks for the correction. So the only concern here is injecting js to exfiltrate the key then.
pcthrowaway 2y ago
Cryptpad (the non-enterprise version anyway) puts the encryption key for its document links after the fragment ('#') which means that doesn't get sent to the servers. 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)
- voxic11 2y ago
  Safari and Chrome (and Firefox!) cloud syncing are e2e encrypted so you should not be handing over anything to Apple or Google. I haven't looked into Edge/Microsofts solution but I would hope they would e2e encrypt as well. 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.
  - pcthrowaway 2y ago
    You can request your Chrome history from Google Takeout; I don't see how this is possible if they don't have access to your browser history. 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-very-bad/ 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...
  - lxgr 2y ago
    Is that true by default for Chrome? 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.

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.
    - lxgr 2y ago
      If you have compromised browser extensions with script injection access, it's game over from a security perspective of any sites you visit. 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.)
      - lesuorac 2y ago
        I think you missed the point they were making. 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.
        lxgr 2y ago
        They mentioned extensions though, and I made a comment on that specific attack vector.
        pcthrowaway 2y ago
        Above commenter got it exactly right. Yes, if you've installed extensions with malicious code, your data anywhere can be exfiltrated. 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).
alwayslikethis 2y ago
It doesn't seem to be.
- pcthrowaway 2y ago
  Do you have an example? As per their docs, they do put the encryption key after the '#': https://github.com/cryptpad/cryptpad/blob/main/docs/ARCHITECTURE.md#encryption https://github.com/cryptpad/cryptpad/blob/main/docs/ARCHITEC...
  - alwayslikethis 2y ago
    Oh, I wasn't aware that slashes can follow the #. In that case it seems to be. Thanks for the correction. So the only concern here is injecting js to exfiltrate the key then.

pcthrowaway 2y ago

Cryptpad (the non-enterprise version anyway) puts the encryption key for its document links after the fragment ('#') which means that doesn't get sent to the servers. 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)

voxic11 2y ago
Safari and Chrome (and Firefox!) cloud syncing are e2e encrypted so you should not be handing over anything to Apple or Google. I haven't looked into Edge/Microsofts solution but I would hope they would e2e encrypt as well. 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.
- pcthrowaway 2y ago
  You can request your Chrome history from Google Takeout; I don't see how this is possible if they don't have access to your browser history. 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-very-bad/ 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...
- lxgr 2y ago
  Is that true by default for Chrome? 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.