In today’s digital world, data privacy is paramount. While cloud services like Google Drive or Dropbox provide easy file sharing, they may not always align ...
Wiki End-to-end encryption:
> The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves. Because no third parties can decipher the data being communicated or stored, for example, companies that provide end-to-end encryption are unable to hand over texts of their customers’ messages to the authorities.
The recipients retrieve the encrypted data and decrypt it themselves
Ok, but how can the recipient decrypt it if he doesn’t have the key? The only thing that’s shared is the URL and if the key is in the URL, well, I don’t know what’s the use for it since the server knows it.
@peregus It’s explained in other threads here. The key is in the url but behind # and that part is invisible to the server. protocol://host:port/path?query#fragment, server will only see …?query, so both participants can decrypt, but server can’t => E2EE
Oh, ok, now I get it. So it could be checked by a third party if that code is really created by the browser and if it’s not sent to the server, correct?
@peregus @dl007
Wiki End-to-end encryption:
> The messages are encrypted by the sender but the third party does not have a means to decrypt them, and stores them encrypted. The recipients retrieve the encrypted data and decrypt it themselves. Because no third parties can decipher the data being communicated or stored, for example, companies that provide end-to-end encryption are unable to hand over texts of their customers’ messages to the authorities.
You don’t have to trust the server.
Ok, but how can the recipient decrypt it if he doesn’t have the key? The only thing that’s shared is the URL and if the key is in the URL, well, I don’t know what’s the use for it since the server knows it.
@peregus Apparently some of your assumptions must be incorrect
Do you mind sharing with us what’s incorrect? I’m here to learn.
@peregus It’s explained in other threads here. The key is in the url but behind # and that part is invisible to the server. protocol://host:port/path?query#fragment, server will only see …?query, so both participants can decrypt, but server can’t => E2EE
But it’s the server that creates the URL in the first place, so it must knows it, right? …or wrong?
@peregus No that would be created by javascript in the sender’s browser.
Oh, ok, now I get it. So it could be checked by a third party if that code is really created by the browser and if it’s not sent to the server, correct?
@peregus yes, that would be here: https://github.com/timvisee/send/blob/master/app/fileSender.js#L81