Hacker News new | ask | show | jobs
by pcthrowaway 459 days 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)

2 comments

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.

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-...

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...

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.

It's trivial for the host to inject some JavaScript that reads the fragment and phones home.

The FISA request writes itself.

Oh sure, if you're running malicious code in the browser already then Cryptpad can't protect you.

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