Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox Send: Private, Encrypted File Sharing

send.firefox.com

Post reply on HN
Print view View original

161–170 of 285 posts

Re: Firefox Send: Private, Encrypted File Sharing

#161

Post by juliendorra »

bubblethink wrote: post #9
NikolaeVarius wrote: post #5

It really is a shame that there still isn't a easy way (A person whose computer knowledge extends to using facebook), that I know of, of sending arbitrarily large files that isn't tethered to a specific cloud service and is also reliable (can tolerate connection dropping). It seems that bitorrent protocols are pretty close, but I don't think there is a seamless client that allows for "magical" point to point transact…

Both parties would have to be online for any p2p solution to work. And if they are online, there are plenty of ways to create a p2p link. It is complicated by things like NAT though. However, that is the less common case. In most cases, the receiver isn't going to be online. So you need an intermediate server, and that's how you end up with third party solutions.

Smartphones in Europe are close to being online 24/24. Energy management by OSes might limit apps in what they can do, of course. In any case, 4G networks rise might lead to interesting new solutions.

Re: Firefox Send: Private, Encrypted File Sharing

#162

Post by the8472 »

Vinnl wrote: post #138
KwanEsq wrote: post #33

Earlier quoted context omitted.

The key is the hash, which isn't sent over the wire when loading a page. Now granted it's accessible via location.hash in the client, but one has to trust Mozilla not to do that.

> one has to trust Mozilla not to do that Well, the advantage of the client is that you can inspect the source, so you can verify that it doesn't actually access location.hash.

But software loaded from webpages are not immutable. They could be manipulated at any given time. So even if someone audits the code you still cannot trust it because all the audit would show is that the specific downloaded version which the auditor saw was non-malicious.

As long as websites have no fingerprints that encompasses all loaded resources and can't be pinned to that fingerpint crypto in the webbrowser is not trustworthy.

Re: Firefox Send: Private, Encrypted File Sharing

#163

Post by sf_rob »

superkuh wrote: post #147
programmarchy wrote: post #61

Earlier quoted context omitted.

Not sure how true that is anymore. They seem to by trying hard to squander their reputation. First their MITI officially signaled they now consider themselves a political force, then the whole Cliqz debacle following shortly after showed their willingness to sacrifice their principles.

Don't forget their switch to a walled garden for extensions in order to protect users from themselves.

Power users can use unsigned add-ons in Dev Edition. Regular users would be exploited by any middle ground solution in the main release. It's unfortunate the web is a dangerous place for the average user.

Re: Firefox Send: Private, Encrypted File Sharing

#164

Post by AgentME »

ge0rg wrote: post #116
Aissen wrote: post #93

I've just checked the code. It indeed deletes the file once a download has been completely consumed, so it can't really replace other file-sharing services. BUT I wonder how does it deal with race conditions ? My guess is that if many people start a download at the same time, they'll all be able to complete it before the file goes away. At least that's how I'd see it working with S3 or local storage. You could abuse…

The sender could open a download connection and stall it as far as possible (maybe keep the download rate shaped to some bytes/second, to prevent an inactivity timeout). That would open a large time window for further downloads.

I assume the file would be deleted as soon as any client finishes downloading. (If the files are backed by regular files on a unix-like system, then the existing open handles to the file will keep working, allowing currently-connected clients to finish downloading, but preventing any new clients from starting the download.)

Re: Firefox Send: Private, Encrypted File Sharing

#165

Post by mtgx »

ReAzem wrote: post #136
microtonal wrote: post #67

Earlier quoted context omitted.

Resilio Sync (formerly Bittorrent Sync) pretty much offers that. They use relays in case both peers cannot pierce NAT, but the relays only see ciphertext. They also have apps for Android and iOS, making transfers to mobile devices also possible. Since it is closed-source software, it's up to you to decide whether you trust the software. SyncThing is a free software alternative, but I wouldn't say that it is usable (y…

Instead of Resilio Sync, I would suggest that people take a look at Syncthing. They have similar features but Syncthing is open source.

I haven't tried Synthing in about a year, but to me Resilio and Syncthing look like they are from completely different classes of apps/they target different markets.

Syncthing is simply not designed for the mainstream. Resilio is. If Syncthing devs can fix that, I'll gladly start using it over Resilio with my non-technical friends.

Re: Firefox Send: Private, Encrypted File Sharing

#166

Post by z3t4 »

bubblethink wrote: post #9
NikolaeVarius wrote: post #5

It really is a shame that there still isn't a easy way (A person whose computer knowledge extends to using facebook), that I know of, of sending arbitrarily large files that isn't tethered to a specific cloud service and is also reliable (can tolerate connection dropping). It seems that bitorrent protocols are pretty close, but I don't think there is a seamless client that allows for "magical" point to point transact…

Both parties would have to be online for any p2p solution to work. And if they are online, there are plenty of ways to create a p2p link. It is complicated by things like NAT though. However, that is the less common case. In most cases, the receiver isn't going to be online. So you need an intermediate server, and that's how you end up with third party solutions.

If you can assemble IKEA furniture you can also run a Linux server.

Re: Firefox Send: Private, Encrypted File Sharing

#167

Post by arjie »

programmarchy wrote: post #61
soapdog wrote: post #35

Earlier quoted context omitted.

When thinking about a Mozilla offering, it is healthy to think beyond "money and product" as this type of analysis will usually leave you with a conclusion of "this doesn't make business sense". Mozilla is in the game of keeping the internet healthy. Part of it involves products, such as Firefox and its quest to recover userbase. Parts of it involves money, such as MOSS awarding grants or prizes for FOSS stuff they u…

Not sure how true that is anymore. They seem to by trying hard to squander their reputation. First their MITI officially signaled they now consider themselves a political force, then the whole Cliqz debacle following shortly after showed their willingness to sacrifice their principles.

How is Mozilla been ever anything but a political force? Like 12 years ago, when Firefox came out, it was accompanied by probably the largest marketing campaign for an open project barring Wikipedia.

They followed that up with some ten years of "web standards! web standards! open web standards!". This is the game Mozilla plays. That's why they won on the web: everyone does it their way now, even if their browser isn't dominant.

Re: Firefox Send: Private, Encrypted File Sharing

#168

Post by okanesen »

QasimK wrote: post #144
ReAzem wrote: post #136

Earlier quoted context omitted.

Instead of Resilio Sync, I would suggest that people take a look at Syncthing. They have similar features but Syncthing is open source.

There is no iOS app for Syncthing as far as I can tell

You can use fsync() [0] for that.

[0]: https://itunes.apple.com/us/app/fsync/id964427882?mt=8

Re: Firefox Send: Private, Encrypted File Sharing

#169

Post by the8472 »

carussell wrote: post #149
Yoric wrote: post #80

Earlier quoted context omitted.

Send is meant to be an improvement on Dropbox & co for a specific use case. Is it perfect? No, it isn't. But it is still a considerable improvement. If you have a better solution in mind for the average user crowd, feel free to suggest it, of course.

Spec out and implement resource pinning, already. Like RFC 8246, but authored more with the user's interests in mind, rather than the service's. As a show of nothing-up-the-sleeve, a service asserts that it's in a stable state and will continue to serve exact copies of the resources as they exist now—that they will not change out from beneath the client in subsequent requests. When a user chooses to use resource pinn…

This would also have the added bonus that one could reload such pinned resources from anywhere once you got the pin. Even without TLS setup or having to trust certificate chains.

Caching proxies would suddenly become viable again because only the first download has to through HTTPS while "I don't have this in the local cache anymore, can you serve me this content" requests could go through sidechannels or outside the TLS handshake or something like that. Caches could even perform downgrade non-attacks.

Re: Firefox Send: Private, Encrypted File Sharing

#170

Post by CaptSpify »

giaour wrote: post #88
zeveb wrote: post #74

Earlier quoted context omitted.

> one has to trust Mozilla not to do that. Exactly. One has to trust Mozilla every time one visits the page . They could easily configure it to be malicious one time out of a million (say); what are the odds that they would be caught? Web-page-based crypto is fundamentally insecure, and Mozilla is committing an extremely grave error in encouraging users to trust it (as they also do with their Firefox Accounts). Secur…

I don’t think the second paragraph is a logical extrapolation of the first. If this is using the WebCrypto API (which it appears to be doing), then trusting this browser-based solution isn’t fundamentally different from trusting an installed application that can update itself.

> trusting this browser-based solution isn’t fundamentally different from trusting an installed application that can update itself.

Which is still a bad idea to trust, so I'd say that it is a logical extrapolation.

Post reply on HN