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 ...
How it works: I don’t know about this service in particular, but usually the shared contains the encryption key so like this: example.com/files/file_id/encryption_key or something similar
As for trust: This appears to be a individual, so you will have to just trust it when using the public instance. However, since it is FOSS, you can audit the code and spin up your own instance
Absolutely. If you’re at all worried about sending files through third party sites, set up your own. Provided you trust your own security skills, of course.
I would certainly be more interested in having an install under my own domain than using some rando’s that I don’t know.
How it works: I don’t know about this service in particular, but usually the shared contains the encryption key so like this: example.com/files/file_id/encryption_key or something similar
But if the key is in the URL, that’s provided by the server, where’s the utility of the encryption since the server knows it and so does everyone that has the URL?
In theory, yes. But if you follow the link and that leads to downloading the JS and running it, you’re already too late inspecting it.
And even if you review it once (and it wasn’t too large or obfuscated via minification), the next time you load a page, the JS can be different. I guess there could be a web browser extension for pinning the code?
The only practial alternative I know of is to have a local client you can review once (and after updates).
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?
The fragment of a URL is not sent to the server, so that’s where such platforms usually store the key. That’s also the way cryptpad does it. You can thus share the URL and with it the key.
Of course, you still need to trust the platform. The sourcecode link at the bottom of the page links to https://github.com/timvisee/send who forked from mozilla/send and links back to the web page.
If you trust the client that is encrypting and uploading the file - which runs on your computer and thus can be audited, modified, or even entirely replaced by you. You do not need to trust that the server (which ideally is also free software, but in practice is a black box you don’t have any visibility into) is sending you trustworthy code.
How is this possible if the only thing that is shared between sender and receiver is just a link (that is provided by the website)?
How can we trust https://send.vis.ee/? Who are they?
How it works: I don’t know about this service in particular, but usually the shared contains the encryption key so like this: example.com/files/file_id/encryption_key or something similar
As for trust: This appears to be a individual, so you will have to just trust it when using the public instance. However, since it is FOSS, you can audit the code and spin up your own instance
Absolutely. If you’re at all worried about sending files through third party sites, set up your own. Provided you trust your own security skills, of course.
I would certainly be more interested in having an install under my own domain than using some rando’s that I don’t know.
But if the key is in the URL, that’s provided by the server, where’s the utility of the encryption since the server knows it and so does everyone that has the URL?
So the trick is to use the
#fragmentpart of the URL, that is not sent to the server.Of course the JS one downloads from the server could easily upload it to it, so you still need to trust the JS.
But the JS code could be checked on the webpage, correct? If so, the page could be trysted (if vetted).
In theory, yes. But if you follow the link and that leads to downloading the JS and running it, you’re already too late inspecting it.
And even if you review it once (and it wasn’t too large or obfuscated via minification), the next time you load a page, the JS can be different. I guess there could be a web browser extension for pinning the code?
The only practial alternative I know of is to have a local client you can review once (and after updates).
@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?
The fragment of a URL is not sent to the server, so that’s where such platforms usually store the key. That’s also the way cryptpad does it. You can thus share the URL and with it the key.
Of course, you still need to trust the platform. The sourcecode link at the bottom of the page links to https://github.com/timvisee/send who forked from mozilla/send and links back to the web page.
Oh, now I get it, the whole system works if we trust the guy that provide that system.
If you trust the client that is encrypting and uploading the file - which runs on your computer and thus can be audited, modified, or even entirely replaced by you. You do not need to trust that the server (which ideally is also free software, but in practice is a black box you don’t have any visibility into) is sending you trustworthy code.