132
submitted 1 month ago* (last edited 1 month ago) by dl007@lemmy.ml to c/opensource@lemmy.ml
top 31 comments
sorted by: hot top controversial new old
[-] pyre@lemmy.world 28 points 1 month ago

great name if you hate the idea of people searching for it.

[-] Kelly@lemmy.world 4 points 1 month ago* (last edited 1 month ago)

I this is the most effective search I could find:

https://www.google.com/search?q="Mozilla's+Firefox+Send"

Not great for a product that is not Mozilla's Firefox Send!

[-] peregus@lemmy.world 8 points 1 month ago

Send lets you share files with end-to-end encryption

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?

[-] RmDebArc_5@sh.itjust.works 14 points 1 month ago

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

[-] halm@leminal.space 4 points 1 month ago* (last edited 1 month ago)

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.

[-] peregus@lemmy.world 1 points 1 month ago

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?

[-] flux@lemmy.ml 1 points 1 month ago

So the trick is to use the #fragment part 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.

[-] peregus@lemmy.world 2 points 1 month ago

But the JS code could be checked on the webpage, correct? If so, the page could be trysted (if vetted).

[-] flux@lemmy.ml 2 points 1 month ago

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

[-] chebra@mstdn.io 5 points 1 month ago

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

[-] jwmgregory@lemmy.dbzer0.com 4 points 1 month ago* (last edited 1 month ago)

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

[-] chebra@mstdn.io 0 points 1 month ago

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

[-] jwmgregory@lemmy.dbzer0.com 1 points 1 month ago

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:

Nobody will be justifying their existence in front of a random internet user.

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

[-] peregus@lemmy.world 1 points 1 month ago* (last edited 1 month ago)

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.

[-] chebra@mstdn.io 0 points 1 month ago

@peregus Apparently some of your assumptions must be incorrect

[-] peregus@lemmy.world 1 points 1 month ago

Do you mind sharing with us what's incorrect? I'm here to learn.

[-] chebra@mstdn.io 0 points 1 month ago

@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

[-] peregus@lemmy.world 1 points 1 month ago

But it's the server that creates the URL in the first place, so it must knows it, right? ...or wrong?

[-] chebra@mstdn.io 1 points 1 month ago

@peregus No that would be created by javascript in the sender's browser.

[-] peregus@lemmy.world 1 points 1 month ago

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?

[-] chebra@mstdn.io 0 points 1 month ago
[-] peregus@lemmy.world 1 points 1 month ago

@chebra@mstdn.io 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.

[-] chebra@mstdn.io 2 points 1 month ago

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

[-] peregus@lemmy.world 2 points 1 month ago

@chebra@mstdn.io Thanks a lot for your time explaining that to me!

[-] chebra@mstdn.io 1 points 1 month ago

@peregus You're welcome, stay curious!

[-] redxef@feddit.org 3 points 1 month ago

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.

[-] peregus@lemmy.world 2 points 1 month ago

Oh, now I get it, the whole system works if we trust the guy that provide that system.

[-] beyond@linkage.ds8.zone 1 points 1 month ago

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.

[-] jjlinux@lemmy.ml 3 points 1 month ago

This is cool. If you're worried about the safety on their instance, spin your own. They have a very clear and simple docker way to do just that.

[-] 7eter@feddit.org 2 points 1 month ago

Does it already integrate with Thunderbird?

[-] d0ntpan1c@lemmy.blahaj.zone 3 points 1 month ago* (last edited 1 month ago)

https://addons.thunderbird.net/en-US/thunderbird/addon/filelink-provider-for-send/ this add on can be pointed at any send instance, so long as the instance isn't too diverged from the popular fork or Mozilla's original project.

The Thunderbird team has talked in the past about bringing Mozilla Send back as more of a feature for Thunderbird files embedded in emails, hence some of the work that's happening off and on by Mozilla themselves in the original project, some of which has been merged into the project this post is about.

this post was submitted on 05 Nov 2024
132 points (98.5% liked)

Open Source

31712 readers
303 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS