Mozilla’s Send makes it easy to send a file from one person to another
theverge.com
theverge.com
Joke aside I transfered a lot of files inside instant messengers and they worked quite well. Nearly everyone had at least a yahoo/messenger/skype/icq account, which made this rather simple, and, because nobody had the capacity/wasn't insterested/was actually p2p, it was perfectly fine. A bummer if the modem connection went down or you had to hang up because the family wanted to make a call, but hey, it was glorious. (no, this is not sarcasm, it really did work.)
Sometimes it doesn't though, and then I have no idea you tried to contact me, because skype is so broken that it /never/ rings when you call me.
This makes matters worse when my skype number is listed as the contact number on some contracts I've signed (their computer system was set up to only accept Japanese phone numbers).
One thing I used to do when I wanted to send files to people outside of the context of a chat was just drop them in a directory on the web server that was running on my machine. Sharing files with folks in a private IRC channel was incredibly easy this way.
I agree about NAT, but that doesn't negate the fact that it was peer to peer that worked for over a decade.
I remember my brother's, can't remember his password, though.
Why is it more difficult to get back in to my 20 year old ICQ than it is to reset any other password I have, even "high security" sites like Bitcoin exchanges or Domain Name providers.
Shall we try stenography next?
So much for emailing a draft of a web application to a colleague.
https://support.google.com/mail/answer/6590?hl=en
To protect you against potential viruses and harmful software, Gmail doesn't allow you to attach certain types of files, including:
> Certain file types (listed below), including their compressed form (like .gz or .bz2 files) or when found within archives (like .zip or .tgz files)
> Documents with malicious macros
> Archives whose listed file content is password protected
> Password protected archives whose content is an archive
File types you can't include as attachments:
.ADE, .ADP, .BAT, .CHM, .CMD, .COM, .CPL, .EXE, .HTA, .INS, .ISP, .JAR, .JS (NEW), .JSE, .LIB, .LNK, .MDE, .MSC, .MSI, .MSP, .MST, .NSH .PIF, .SCR, .SCT, .SHB, .SYS, .VB, .VBE, .VBS, .VXD, .WSC, .WSF, .WSH
In the end I had to throw it up on the web with a strong password.
Not sure if they the prior attempt unpassworded set a flat for the subsequent attempt but Google though is almost superhuman when it comes to blocking malicious stuff I do wonder what the false positive rate is like.
Format like 7z works well for this purpose as it has an option to encrypt header info.
So really Facebook is pretty reasonable.
Some friends even ran their own ftp (I think most people used War ftp) before ISPs started blocking ports.
Now it's all about uploading to "the cloud" or use sneakernet. My friend uses mega.nz, which seems decent for file sharing. I, personally, never underestimate the bandwidth of a sedan, driving down the highway with a single USB key.
www.file.pizza
Let the p2p transfer commence
https://file.pizza/ does connect
I haven't seen a app more ignored than Skype. This should have been what Whatsapp is today. But MS just killed it
There just doesn't seem to be anything out there that's friendly, old-school messenging (except for complicated stuff that would be difficult for other users to get setup).
The protocol is a little bit strange, though. The file metadata is transmitted as an X-File-Metadata header on upload, and includes the SHA256 hash of the original (unencrypted) file (as the "aad" parameter to the X-File-Metadata upload parameter). This is a little concerning for privacy; while the filename is easy to disguise, hiding the SHA256 sum requires modifying the file in some way. Of course, this might only be a concern for uploading known files, but it's still a bit of an infoleak.
It's also strange in that the key isn't checked in any way (even for sanity) before initiating a download, so if you mess up and leave it off (or corrupt some bits), you won't find out until the end of the download that you can't get the file. Worse, the file will be deleted, forcing you to ask your sender for another copy.
The client-side crypto has one other downside: there doesn't seem to be a standard way in JavaScript to stream a POST request yet. You could emulate it with e.g. WebSockets, but those are a lot more heavyweight and CPU-intensive (for the server) than simple POST requests. So, the current implementation just encrypts the entire file as one giant block, and then uploads it - placing the whole file in memory. Hence the 1GB soft-limit. Downloads are similarly limited.
Luckily, non-browser clients can do whatever they like, so I wrote a Python client that's compatible with the server, but uses streaming POST and on-the-fly en/decryption to save memory. Check it out at https://github.com/nneonneo/ffsend - feedback welcome!
Does it matter? The file is behind a URL with a random id (and the hash expires from redis after a day). Even if someone guessed your id within a day, they know essentially nothing about your file or you. And if they had your URL, they could download the file anyway, making it moot.
> Hence the 1GB soft-limit.
Mozilla stores the files on S3. That needs a reasonable limit.
We can send the shit out of some files... if you know what you're doing (browsers retrieve tons of files all the time, for example).
It's difficult creating a service that is accessible to people who barely understand what a file is in the first place.
If all computers were publicly reachable it would be trivial to send files peer-to-peer.
I guess IPFS can be an interesting solution to this problem.
The world got paranoid, as any exposed port to the raw net is seen as an invite to worms.
NAT punching is a thing, but it makes the implementation of p2p a lot more complicated.
WebRTC exists today, and it's quite good. It's not a technology problem, it's a matter of practicality. Mobile devices being reachable over the network 24/7 is just not realistic (connectivity falls off, battery considerations, etc.). I don't want my phone to heat up and come to a crawl because the video I just shared is being downloaded by three friends over LTE while I ride the train.
Unfortunately AFAIK there has been no successful open point to point file transfer protocol that different OSes could implement and be interoperable over the Internet. Going to https://send.firefox.com/ and drop a file there is not an improvement. It's still centralized. Is there any solution to the problem of discovering the address of the sender and the recipient without a central server? I would think it's an impossible problem but there are clever people out there. Maybe mesh networks?
The fact that files can only be downloaded once from this new service isn't just a coincidence.
But yeah, some sort of ubiquitous fat client, possibly even integrated in the OS, would probably have appeared, and it would cost $50.
Unfortunately, it only works in small groups. If you're in a large office, or need to send something to someone outside the building, you're SOL.
Well, not all the time. Never works at my parents, for example. Works in my flat about 80% of the time (although iOS 11 + High Sierra seem to be improving that ratio slightly). Never worked at $JOB-2. Doesn't work if you want to send to a non-Apple device. etc. Maybe Apple will spin up something out of the DeskConnect ashes for these cases.
When it does work, mind, it is bloody magical.
If it's free there's little incentive for a company to spend the money developing the easy UI and marketing it to critical mass. Even simple to use Dropbox has not made a significant dent. BitTorrent never became mainstream at the level of email but it did incentivize people to seed with the prospect of pirated content. The MPAA/RIAA have deputized any websites that accepts user content as copyright police and demonize non-enterprise file hosting services.
In a way the success of Facebook is a reflection of the spammy, phishing/malware filled, and slow nature of email and difficulty making your own website; if email continued to improve there wouldn't be demand for a modern solution. File syncing and sharing should be integrated into the operating system. However Microsoft's OneDrive and Apple's iCloud are inferior to Dropbox so a third party solution is still relevant.
Your browser is not supported. Unfortunately this browser does not support the web technology that powers Firefox Send. You’ll need to try another browser. We recommend Firefox!
It would be nice to know what web tech they are using that isn't supported. Whatever it is, Chrome works.
EDIT: It requires support for the AES-GCM key type, with a size of 128.
Mozilla Send works in Safari Tech Preview.
Source: I work on Test Pilot
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
I'll leave it up to someone wiser than me to indicate if this is the proper choice. AES-GCM key type with a length of 128.
[edit] Works in TP, lucky me.
That does seem to happen more often than makes sense for many software/industrial/government organizations, doesn't it?
Really the whole thing is set up to limit manager accountability (since managers can just point the finger at each other when something goes wrong) and increase worker frustration...it's not uncommon for two managers to tell you to do two different things.
The idea of FB status updates (and Twitter) literally came from the status line you could set in AIM.
I wrote the original TCPSocket implementation for Firefox OS. As I was doing it I imagined an architecture like what you described. I know at least some prototype apps which worked in a similar way were developed.
One issue with the experiment is it has such a narrow use case. Disappearing after one download / 24hrs makes sending a file to multiple people--or just one person who drags their feet on the DL-- makes it really inconvenient to use. Even offering "1 download -OR- 24hrs" would make it far more useful.
There are other existing solutions like https://share.riseup.net which do not do things like this too and which do allow multiple downloads.
Do they communicate that sending any known file is non-private?
If I email myself a pop-song, does the client automatically start the extradition proceedings for the RIAA; or does that come later? /s
Also, you wouldn't need add a file. Zipping it alone would be enough to change the hash.
I don't think you can expect the file mod time to be identical, as it isn't preserved through many forms of file distribution.
[1]https://en.wikipedia.org/wiki/Zip_(file_format)#File_headers
Why would they do that? It's not like anyone can send them DMCA notices: the act of verifying that the upload violates your copyright already removes the file from the service. And I don't see anything in the DMCA that requires them to search for offenders, they just have to act once they become aware?
The Megaupload case sadly is a good example of what no one wants to repeat, as there this was exactly argued - that, once notified, the hoster has to ensure this file won't ever be uploaded again, and all other copies are removed, too.
Unfortunately it seems like most of the time a physical USB flash drive is the most efficient way to accomplish this. Seems absurd to me that in 2017 there's not a common, user-friendly way to just establish a direct connection between two web browsers and directly push files through.
They were never inteded to be active senders or p2p workers. I know, we've come a long way in the past 2 decades, but I never expected this to be the job of the browser. I'm also aware of webRTC and I'm a bit uncertain why that can't be used to send/receive files.
When it works, AirDrop between Apple devices seems like it does exactly what you describe. Of course, this assumes that the two devices can see each other via Bluetooth and I'm pretty sure the thing is partly mediated by iCloud.
I'm not sure if there's an equivalent in the Windows world.
> ...establish a direct connection between two web browsers and directly push files through
Is this really a web browser's job? Why does it feel like the default answer to every "Why can't I do X easily?" question is to make the browser do it?
I used to transfer stuff between different Windows machines (on the same network) by simply going Start, Run, \\OtherComputerName and authenticating. Regular users, like my parents, would just go to Network Neighbourhood and find the computer in question. It was pretty easy and all built in to the OS.
Somehow just not in the mainstream, integrating into browser should increase some awareness.
this Mozilla service seem really useless over tons of others like mega.nz, is it really that big deal to delete file manually?
It would be nice to be able to self-host this on a small home server for friends and family. That way, even if they shut down their server, you could still share files with your friends.
This uses WebRTC to transfer files peer-to-peer.
Unfortunately it is not.
My only issue with filepizza is, I wanted to host one internally, but it has a hard dependency on a hardcoded list of torrent trackers. (I have a DENY ALL firewall rule at the border which can't be touched) :(
I really prefer p2p if available, and on my LAN it doesn't have to traverse NAT or anything.
Or just start poking through their code and WebRTC docs/libs to see what you can build yourself.
We do NAT traversal but also connect to local peers over multicast DNS. Command line client should have a local or offline option to restrict only to local peers soon.
=)
EDIT: Well what do I know, it worked today, but hasn't a few weeks ago when I first heard of it. The transfer speed however makes it seem like it's actually pushing it through the entire internet, it's flying at about 500kB/s.
Most of the time, I want to send a link by email, and let the receiver choose when they want to download the file.
For example, modern email services (Google, MS, etc.) accessing links in emails and download the content and check it for malware. They probably mitigated this but its caveats like this that cause messages to be burned before the intended reading.
Not sure if this is viable.
Give the product a chance, imho.
But if they would handle 1:N file sharing, they would risk being attractive to a lot of users they don't want (mostly those distributing in a copyright-infringing way)
The url is not memorable on purpose: it's a uuid so people can't just guess it and access other's file.
I can message my wife from my phone to her phone, but I can't message myself from my phone to my PC. At least, with most messaging programs.
[1] https://ipfs.io/
If my impression was correct, then Firefox Send supports different use cases than IPFS.
Here is a link with installation instructions for every major platform.
1) It can't traverse NAT, you have to forward the ports on your router- which is quite frustrating.
2) It can't use ipv6, which would have eliminated the first problem, but unfortunately without ipv6 it can't do that.
Unless of course you have a dedicated IPv4 for your DCC sender and receiver, but I think that is improbable.
I ended up copying over on an SD card after ~1 hour of fighting with smb version compatibility, smb vs linux permissions, workgroup mismatches due to localised windows.
woof also supports uploads (shows a basic uploading page), which is nice when you want to transfer to a server.
http://www.home.unix-ag.org/simon/woof.html (but it's packaged in Debian)
twistd -n web -p 8000 --path ./path/
npm install -g http-server && http-server -p 8000 ./path/ python -m http.serverEither way looks like a good promotion trick for Firefox if many people end-up using. Good job whoever came up with it and convinced Mozilla leadership to deploy it.
For a cross-browser, self-hosted tried and tested alternative, there's 0bin: https://github.com/sametmax/0bin
Then they implemented a whole bunch of features that I thought were clunky, emailing the passphrase, QR codes I think, the ability to require approval to access shares, sub-permissions, etc.
2 years ago or so they released a version that was not backward compatible, so everyone had to upgrade or not, and if only some peers had upgraded, things got out of "sync" heh.
Finally, we got my team all on resilio sync and we all had 100% CPU pegs on certain shared folders.
I gave up on it.
When it was really simply and it synced it was great
This smacks of Mozilla misjudging the market again and wasting a lot of time and money on things that just won't work at scale. Annoying because they are by far the richest 'tech charity' and have a lot of really amazing engineers. More Rust and Servo (concepts that very few people can execute on), less random startup ideas, I think.
It's an experiment, part of the Test Pilot program. A relatively low-budget MVP to test the waters and see if the concept is worth exploring. If not, the experiment ends and the organization moves on.
The program exists precisely to counter your concerns here while ensuring Mozilla can continue to innovate in new areas.
I assume it is a bit difficult though, since the encryption is performed in the browser. Thus API clients had to perform the exact same crypto to use this service.
Great that Mozilla are experimenting but this article literally adds nothing to the original Mozilla blog post and website and has no value whatsoever
I think that it would be better if Mozilla focused more on their important projects, such as Firefox, Servo and Rust.
https://dropfile.to/ - 1GB (requires js, not third party however. It also has a nice API)
https://lewd.se/ - 5GB
That being said, there are many more permanent file hosting services which one can use instead.
Disclosure: I work at Microsoft.
Mozilla's service could just plug into it.
This can't possibly be true. Since Mozilla is encrypting the file, they can also decrypt it (and must do so when the recipient downloads it).
Edit: I was wrong, but will leave this comment because the explanation is useful.
The URL that is shared contains the key for the file. You'll notice that the URL contains a fragment identifier, i.e the #foo part of http://example.com/#foo, this isn't transmitted to the server by the browser and therefore the key isn't exposed beyond who the URL is shared to.
https://github.com/mozilla/send/blob/master/frontend/src/fil...
https:// send.firefox.com/download/<$file_identifier>/#<$encryption_key>
Data after the # in the url should not be sent to the http server by the client. Encryption/decryption is presumably handled in the users browser by JavaScript.
The statement about not having the ability to access the contents of the files is perhaps somewhat misleading as they do control the JavaScript that either creates the key or will be given access to the key when someone retrieves the file (by reading it off the end of the url).
Are there other ISP based systems, say, that perhaps sample the head of a file for anti-malware purposes that might do the same?