[voxic11]

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

[xnx]

Couldn't on-page javascript read the fragment and send that to an endpoint?

[voxic11]

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]

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]

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]

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]

They mentioned extensions though, and I made a comment on that specific attack vector.

[alwayslikethis]

It doesn't seem to be.

[pcthrowaway]

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

[alwayslikethis]

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.