134
Send: Share Files Safely with This Open-Source Successor Of Firefox Send(Firefox Send Fork)
(techwavearena.com)
this post was submitted on 05 Nov 2024
134 points (98.6% liked)
Open Source
31374 readers
51 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@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.
that still isn’t an explanation of how the server supposedly “does not have the means to decrypt them [the messages]”, which isn’t me saying it’s impossible. i’m well aware of possible cryptographic solutions here. but, it isn’t wrong to be sus of this application until the organization/developers have demonstrated a degree of trustworthiness. i honestly don’t see why you would use this over just encrypting and transfering the data yourself using more traditional methods that involve the minimum number of parties. i might just be ignorant of this project, but i’m weary of it until i have a chance for further investigation
@jwmgregory I think you misunderstand some of the technical terms, it would be quite clear how it works and why it's ok, so let's just keep an open mind. Nobody will be justifying their existence in front of a random internet user. So feel free to be sus, but keep an open mind about terms like E2EE, there is much to learn.
i made my comment pretty early before getting up to go vote in our election. i’ll admit i was premature on having an opinion as i just skimmed the content here and didn’t look into things much.
this project is definitely interesting. i suppose my sentiment initially was less that i don’t trust the cryptography, and more a general weariness of new open source projects. after reading more about the implementation there isn’t anything that jumps out at me as particularly egregious.
i support FOSS and the related philosophies a whole lot, i believe it to be one of the only ways to take our lives and communities back these days.
however, with that said, i have to disagree with this sentiment:
random internet users are the open source movement. new projects must justify their existence and trustworthy nature to the community. not that these people haven’t, obviously they haven’t had the chance yet.
an open mind, absolutely. but history has shown bad actors are abound, as well. i’m not sure what the proper solution here is, and i don’t think anyone else is absolutely 100% certain either. removing trust from the equation isn’t easy.
idk i’m kind of just babbling at this point tho. thanks for the civil discussion
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
@[email protected] but the owner of the server could change it, could it be checked directly on the webpage of the service? Not that I will do it (I can't, I can't read that code), I'm just curious.
@peregus yes, well the javascript on the site is minified, but I found this place even in the minified code. At this level it would be easier to take the source code and compile your own, host your own instance, then you know exactly what code is running there. And their minified code could be directly compared with your minified code... the beauty of open-source software.
@[email protected] Thanks a lot for your time explaining that to me!
@peregus You're welcome, stay curious!