Firefox Send: Free encrypted file transfer service
blog.mozilla.org
blog.mozilla.org
For anyone that is interested: https://github.com/timvisee/ffsend
At any rate, the tool works! Thanks so much.
I wasn't fully ready with this tool for the Firefox Send release to be honest, would have loved to be able to provide better binaries and packages for more platforms, which are a work in progress.
If you believe you can improve the README with your solution, be sure to submit a [PR](https://gitlab.com/timvisee/ffsend/).
Happy to see it's working! :)
cat ~/.cargo/config
[target.x86_64-unknown-freebsd]
linker = "/home/drewg123/bin/cargo-ld"
#!/bin/sh
exec /usr/bin/ld -L/usr/local/lib $*So I can have /usr/local/local/local/local...? :)
disclaimer: I haven't used either cli version.
Along with ffsend, you can use any browser to upload/download files through https://send.firefox.com/ as well.
Mind if I port this to JS?
You are free to port the project to JS as long as you follow the applicable licenses: https://github.com/timvisee/ffsend/blob/master/LICENSE
What changed? Is that rant finally outdated? Couldn't Mozilla at any time serve a corrupted JS bundle (with or without their knowledge) which would leak the key somewhere, silently replace the encryption by a noop, etc?
I ask out of interest, not skepticism. I much prefer an internet where we can trust web apps to do proper crypto than one where we have to depend on some app store to somewhat adequately protect us.
[0] https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
Humans are always the weakest link with the internet and someday, sometime, bad code (unknowingly) will be pushed and something will happen to someone.
Your points around a compromised JS bundle are still possible but that has more to do with a company’s deployment/change management setup than JS itself imo
1: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
Here's a site where you can test your browser's compatibility with many combinations: https://diafygi.github.io/webcrypto-examples/
But that's the only point I intend to address here. If Pascal had been the language of the web then my question would have been about Pascal.
Therefore I don't see how SubtleCrypto changes matters much.
In short, if I get it right, the argument would be that in eg a mobile app, all the e2e logic (the core crypto plus the code around it) go through peer-review, then some release management process, then some review by Apple or Google, before it lands in my hands via their app stores' well secured delivery mechanism. In a web app, a single compromised server will compromise all security instantly. Generally I'm fine with trusting Mozilla's servers, but if I have to trust their servers then what's the point of end to end encryption?
This is only true if the server has access to the keys of your data. E2EE typically means that it doesn't, only you do.
> WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE? You can. It's harder than it sounds, but you can safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography.
In our case we aren't doing crypto inception where the cryptography is meant to secure itself. The crypto is being served securely (by ssl) and then used to solve the separate unrelated crypto problem of encrypting random files.
> WHAT'S THE "CHICKEN-EGG PROBLEM" WITH DELIVERING JAVASCRIPT CRYPTOGRAPHY? If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code.
I haven't looked at the details of how Firefox Send works, but if you can download and decrypt the file with nothing more than an https:// URL, it seems like you'd have to trust the server, either to handle the cleartext or to provide trustworthy code to handle the cleartext.
I suppose an alternative would be to generate a data: URL, but if it has to include all the crypto code, I wouldn't expect it to be nice and compact.
Sounds like a challenge for the code golfers.
The main thing is that unless you're paying really really close attention to the JS that you're executing, you can't trust this any more than you can trust Mozilla and the security of whatever computer is serving their pages. I wouldn't use this for sending data that you're trying to hide from a nation-state, but it looks like a great option if you want to send a video to your grandma without posting it publicly on the internet or teaching her how to use GPG.
I have Signal running on my Linux computer and on my Android phone. On the Linux computer it doesn't have root access, but it does have access to its own files, so in theory there's nothing to prevent it from making a network request and updating itself. Additionally, I don't ever check Signal before installing a new update, I just blindly do it.
On my Android device, I also have auto-update turned on, because my only option is to turn it on for every app or none of them. So there's nothing to prevent Signal from updating itself and changing the crypto. If I were on an iOS device, I wouldn't even have that option -- to the best of my knowledge you can not turn off app auto-updates on an iPhone, but maybe someone can correct me if I'm wrong. In any case, it doesn't matter that Signal is updated "rarely". An attacker only needs to install one back door, they don't need to update it a hundred times.
So for an extremely typical user like me, who has been taught for as long as I can remember that the most secure thing you can do on an OS is install updates as they come in when they come in, doesn't Signal have the exact same problems as Mozilla? If someone compromises Signal's servers, can't they add a side-channel just as easily?
In theory, I could disable auto-updates and only update Signal when I looked at the source code, just like in theory I could examine the JS that I'm executing every time I connect to a site. But in practice, I don't.
When I read tptacek's rant nowadays, the immediate thing I can think is, "The web is malleable? Literally every single computing environment and device I own is malleable." It feels like if I were to take tptacek's advice to its logical conclusion, I would just conclude that ETE encryption in general is dead.
I would assume Signal to have a proper signing infrastructure in place, so that the keys used to sign new releases are not available to the server hosting/deploying the actual update files (or providing them to Google/Apple for that matter). So simply taking over that server would not be enough, as malicious updates could not be installed.
Assuming Moxie goes over to the dark side, however, you are screwed. There's nothing stopping your Signal app from bundling all your plaintext messages once you've entered your password and sending them off to China, save maybe a firewall you have in place. Google or Apple might stop such an update during their reviews, but I wouldn't bet on it.
Again, please correct me if I'm wrong, but Windows doesn't do anything with signing app updates, does it? Come to think of it, I'm not 100% sure my Linux version has this either, since Signal isn't being distributed as part of the official repos.
If Signal is being updated on Windows without validating any kind of signature, could a compromised server even pull off the "send a malicious payload to only one IP address" attack that people talk about with the web?
You can always implement signing yourself, though, without relying on somebody else's infrastructure. Just include the public key in the app itself and use it to verify your updates are properly signed by your private key before accepting them. I haven't checked but assume/hope Signal is doing this with their updated JS packages.
If none of this were to happen, however, then the answer to your last question is "yes", though with a caveat: If Signal's servers are compromised and push out a malicious update, then all bets are off, as the app running on your system has access to all your unencrypted messages. If the compromised server is only one of the messaging/relay servers, however, things are not as bad, as they don't have access to your keys and thus can't decrypt your messages. They can still forward them somewhere else for later decryption, but thanks to perfect forward secrecy this is currently rather unrewarding.
E2E encryption is still valuable, because assuming that the codebase is delivered/signed separately from its app servers, it decreases the number of available attack points. It's usually easier to secure code delivery than it is to secure your entire backend/database. It's even easier than that to secure a private key that you never put on your delivery servers in the first place.
JS has some additional concerns regarding stuff like Spectre and random number generation, but ignoring those for a sec, E2E encryption is in theory viable and valuable on the web, assuming you've split your backend from your code delivery endpoint and are taking extra steps to secure those specific code delivery servers.
But E2E encryption on the web could be improved a lot if we expanded code-signing for browsers. We download code over SSL, but that's just to make sure no one MITMs the server itself. We could, in theory, have some kind of signing system for raw assets that was completely unrelated to the connection to the server -- a "only allow Javascript to download/eval on this domain if it's signed with a key that's not even stored on the delivery server at all" policy. But we don't have anything like that yet.
Is that a reasonable interpretation?
Open the Signal store page and click the dots in the top right of the screen and untick Automatic Updates.
I didn't know that, and there are a few apps that I definitely want to use this with. Why on earth isn't this part of the general settings?
Compare with native tools which you only download once, can check its signatures and which strive for reproducible builds so that multiple parties can verify them independently.
Now I see a similar issue with security experts preaching that merely possessing a single piece of software with a single thing they classify as a 'vulnerability' implies you will be murdered within the next 24 hours, and it seems they'll happily DoS your computer, get you fired from your job, take your second newborn, and blow up your computer in your face if that's what it will take to make you finally feel real danger. Not sure why it takes people so long to see that reality isn't black-and-white, but better late (hopefully) than never.
In particular: you'd hope that WebCrypto would have changed things a bit, but, of course, it doesn't: it leaves all the cryptographic joinery up to content-controlled code. You're probably somewhat less likely to have side-channel flaws if you use it, but in reality timing side-channels are more talked about than seen. Who would bother, when they can just deliver a script that exfiltrates secrets directly?
I think you should consider hoisting more of this stuff out into standalone blog posts that you can flesh out and also update as circumstances warrant. I don't think I'm the only one who has learned a lot from reading you, but often felt myself wishing it had been dumbed down a shade for beginners.
Maybe the best argument for it is that blog posts remain mutable and you can add and expand as necessary, unlike these HN posts that are frozen in amber.
I'll work on it.
And, well, you may disagree but to me it definitely reads like a proper rant :-)
Please note that I chose the words "legendary rant" with all the love imaginable and I had hoped you'd interpret it as nothing other than a compliment. I much appreciate your contributions to HN and the internet as a whole.
mind pointing to or sharing them?
(Update: Yep, just found it: https://github.com/mozilla/send, just before the comment below was posted :))
Data is encrypted at client and a url with a key is generated.
Can be used 'burn after reading or with some specific lifetime.
EDIT: Apparently there's a way to use filesystem instead of S3, it's just not well documented.
I recently implemented a text/snippet sharing tool that uses Minio instead of S3, because I like to self-host everything.
In my case I have Minio in front of Azure blob storage, so Seafile is storing data in that.
I host Seafile and Minio using Docker Compose, which was super-simple to get started with.
But to answer your question, I uploaded a 100mb+ file to FireFox Send, copied the link, RDPd into another computer, kicked off the download, and then cancelled it midway through download. The link did expire after that.
So I guess they don't have an easy way of telling whether the download is successful or not. Maybe Mozilla's engineers can figure something out if the issue is raised.
Firefox might consider keying off the initial IP seen upon retrieval and extending the TTL of the object until the final byte has been retrieved.
There's probably enough complexity and possibility for abuse in allowing automated requests for files again (i.e. a button on the view page) or special logic for second attempts that the safest option is just to have the receiving party ask for the file again through whatever medium originally kicked off the request (an email, an IM, etc).
Firefox could do any number of things to make it easier on the user, but I expect them to take my security and privacy very seriously and to error on the side of those ideas rather than usability, so hopefully if they come out with something it's not at odds with those goals.
In an ideal world, partially-downloading the file would expire the link, but the server would still allow the file download to be resumed (but not restarted).
I've used one-time-link services sometimes, and posting the link to Slack causes Slack to make an HTTP fetch looking for metadata, which then invalidates the link.
It's a very common and easy to anticipate issue, I'm surprised that there are any one-time-link services left that suffer from it.
Then, any automated system which sees the link cannot accidentally cause the file to be "downloaded" which would cause the link to be invalidated. They can see the link itself, but they don't have the password, therefore they can't download the content to scan it.
I have used onetimesecret.com a number of times in this way.
That checkbox is #1 reason I only use Firefox.
[1] Developer console log output: "Failed to register/update a ServiceWorker for scope ‘https://send.firefox.com/’: Storage access is restricted in this context due to user settings or private browsing mode. main.js:38:10 SecurityError: The operation is insecure."
I block _all_ cookies except for a small list of sites (like HN...).
This is how i think Mozilla can capture more users back to Firefox. By providing "extra" services attached to the Mozilla and Firefox brand will make them a superior product to the end user. Sure it's hard to compete with Chrome but if you offer useful features and services integrated in your Browser i see that Mozilla actually has a chance to compete with Google for the browser space.
This is one of the "advantages", if you are a heavy Google user, of Chrome over the competition is that everything is attached to your Google account. Passwords, history, spellers, dictionaries, shortcuts, etc...
If Mozilla comes with Send, Notes, Password Manager all integrated in Firefox i see a good way to bring back some of the previous users that switched to Chrome.
Currently, I need to set up my own email hosting through a service like fastmail and then configure a desktop client(like Thuderbird) to use it.
A Mozilla Gmail-esque service would remove a lot of the friction there and probably bring in a bunch of users who are tired of google running everything.
As a Chrome user I can confirm. But for me the main raison I use Chrome is for the dev tools a found them better than FF
We don't need another AOL Chrome.
How is that different from the complaints people make about Chrome tightly integrating with Google?
1. Bob uploads a file, but specifies no password.
2. ???
3. Sue downloads the file.
Best case, Bob's browser encrypts it (with javascript?) before uploading. Either Mozilla provides a key, or Bob sends the key he used. When Sue's browser downloads it, Mozilla sends the key and her browser decrypts it client side.
In either case, Mozilla has the password for decryption. This makes a mild barrier to mass scanning content that's uploaded, so at least that's something... but that's little more than a promise I have to trust.
Am I missing something? Where is the "end-to-end" encryption? End-to-end means I don't have to trust you (as much). Please don't turn this into a meaningless buzzword...
EDIT: I did misunderstand something. Please see timvisee's comment below.
Browsers don't send the anchor tag (ie: with GET requests). FF Send takes advantage of this by using the anchor tag to store the key for decryption.
That is kinda novel. You still need to trust the upload client to not leak the key, but I see that you've written a CLI version. Interesting! Thanks for the response.
More seriously, did they do anything to fix this obvious design flaw? If they want to fish a key they can just serve you a modified JS file and retrieve the key. Unless of course you chose to audit the JS served every time you browse the website.
Yes, such a CLI tool would help protect you against a MITM with malicious JavaScript.
I'm working on documenting the code now before I release on GitHub, but it works on the same premise :)
WebCrypto is mana from the gods...
So you have to send the link through some previously-negotiated secure channel. At that point, why not just send the file through that channel? Is it because signal/whatsapp/etc don't allow large files or because the interface is cumbersome?
This fills a handy gap for a lot of people with smaller needs.
> This fills a handy gap for a lot of people with smaller needs.
You point out exactly the problem: the people who are technical enough to deal with GPG's UX competently are also technical enough to evaluate whether they should put a particular document through this Send service.
I don't think nontechnical people have "smaller needs".
I think this fills the gap for when you want to share not-critically-secret stuff with non-technical people and would today likely send it over something like e-mail, Drive or Dropbox.
If anything it's probably harder to understand for a somewhat semi-technical person who probably has started to think about encryption and so on but hasn't got far enough to spot that oh - the secret key is in the URL itself as an anchor and so the URL is the secret.
Computer Security is often nicer here than real world physical security, because we are often able to make the extreme cases so implausible as to be irrelevant, enabling intuitive statements to be true in practice rather than subject to endless caveats.
For example a lay person sees a padlock and they imagine that it cannot be opened except with the padlock key. And this is untrue in lots of ways - so a more technical person may think of some of them, and identify that this particular brand of padlock defends against those well, but not realise that other problems are undefended.
So this means the truth about the padlock has to be more nuanced and relative. Breaking the lock open with tools is "difficult". Picking the lock "cannot easily be done in under a minute". But lay people don't like nuanced, relative statements. It sounds a lot like this padlock won't really stop someone stealing my bike! That's because it won't.
But in computer security we often can make these cases irrelevant in practice. What if someone just tries all the key values for this AES encryption? That's fine, there are so many that even if they could try as many as there are grains of sand in the world, every second, the sun would burn out long before they had a meaningful chance of guessing the right one.
I think the scheme is fairly robust against passive interception though.
What am I looking at here? On PyPI 'pipe' is listed as a "Module enablig a sh like infix syntax (using pipes)", and magic-wormhole's own docs just say to install with pip like anything else.
`pipx` is a convenience utility for installing cli python tools in separate virtual environments and then being able to update them nicely: https://github.com/pipxproject/pipx
So i meant
`pip install --user pipx && pipx install magic-wormhole`
That is, who's paying for the server storage and the bandwidth?
Of course Mozilla's not in it for the money, so there's not a direct line from Send to more revenue. Firefox is their main tool to protect the open web, and Send is a way to get more people to use that. And of course, being able to send files encrypted is good for the web as well.
Indirectly, it is primarily financed by the search engine deal in Firefox.
If this were on AWS it would be around $0.09 per GB for downloads.
https://www.backblaze.com/blog/backblaze-and-cloudflare-part...
I remember sending a signed PDF via Firefox Send and was at first horrified when I realized I couldn't get the file back after 24 hours but then relieved knowing that the recipient got it and then it disappeared from the internet. Very cool!
From this it seems that their moneymaker is the new Firefox account creations that will be driven by this service, to whom they can then upsell. But it doesn't state what they are trying to upsell. Anyone got any idea what that might be?
If you already have a Firefox account, the barrier to using Firefox Sync is lower, and with that, the barrier to using Firefox for Android/iOS is lower.
Secondary - In support of Revenue KPI
We believe that a privacy respecting service accessible beyond the reach of Firefox will provide a valuable platform to research, communicate with, and market to conscious choosers we have traditionally found hard to reach.
We will know this to be true when we can conduct six research tasks (surveys, A/B tests, fake doors, etc) in support of premium services KPIs in the first six months after launch.
The metrics section is interesting https://github.com/mozilla/send/blob/master/docs/metrics.md
It sounds like they're investigating a premium service offering targeted at privacy conscious users. (The secondary hypothesis covers "revenue" and will be tested by conducting "research tasks ... in support of premium services KPIs.")
I wish they added a QR code option as well. It would be perfect for quickly copying the link by snapping it with my phone so I can download later.
I also think the blog post could explain more why and how the e2e encryption works. Maybe just by showing an example link and then highlight with colors "this part is private"?
http://send.firefox.com/download/<fileid>/#<secret>
Anyone who obtains the link (e.g. via email interception) gains access to the file.
Since browsers don't transmit the anchor when requesting a resource [1], Firefox servers never see a copy of the key. Provided you trust their JavaScript.
[1] https://stackoverflow.com/questions/3067491/is-the-anchor-pa...
True, but, if a third party decides to use the intercepted link to download the file, and you have it set to a limit of 1 download, the file will self-destruct (if you trust Mozilla). This way, the recipient can know that someone has tampered with the communication, which is certainly an improvement over the status quo (email attachments).
How do they handle abuse though? Like, people using it to host, say, pirated TV shows? Maybe a max download limit that makes it impractical for that use case?
One can always split files.
The torrent protocol is already there. Don't put that cost on the Mozilla Org.
It only takes screenshots within the confines of a Firefox window.
[1] The protocol is named Google Cast, but all the consumer branding is Chromecast.
Currently, my scanner conveniently sends me emails with scanned documents. But I have not insight into how they actually store and delete the document on the backend.
Would be great if the scanner had the option to upload to Firefox Send and show me a QR code to download it on other devices.
If you want, you can also set a passphrase on the file to share via another channel
https://tools.ietf.org/html/rfc3986#section-3.5
"(...) the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme."
Ed: as for an untrusted network, tls should be able to secure that. Except if the network owner can insist on/enforce a tls stripping mitm/proxy.
If that's the case, I think setting a passphrase should be mandatory. Proxy servers are extremely common at every workplace. Since they probably log all requests, they will capture all keys in the URL.
Hinges on the browsers never sending that key, though.
For certain reasons I get a ton of dropbox space, but for my friends, data quotas kick in on even simple files shared like this.
I believe this is a primary upgrade mechanism for DB--I'd say this new firefox offer is in competish.
Using their revenue from search, like everything else they pay for.
> What's the upside for Mozilla?
"Our mission is to ensure the Internet is a global public resource, open and accessible to all. An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe and independent."
It works on chrome, and does not work on IE 11 (win 7 doesn't support edge)
https://news.ycombinator.com/item?id=15450524
I haven't been able to upload a file to try.
Much lower trust assumptions
Functionality for dropboxes
We get a lot of customers who want to send us secure data (customer info, etc...) and I’d love a way to make it easy for the customer but still secure.
Does something like this exist, or is this still a pipe dream? Basically FF send, except I provide a known public key to use, rather than it being generated on the fly, requiring the user to find a way to send it to me out-of-band.
Documents are mostly emailed to recipients at the moment (unless they're too large, in which case... um....). The main problem we see is that you end up storing documents in email attachments on your email provider, and using email search tools to try and find documents.
Would this end up the same, only with all documents ending up in the Downloads folder?
Am I wasting my time working on creating a cloud storage sharing solution, and be better working on a method of organising files on the drive, that can also send them to other people?
I'm encrypting the file on arrival, and storing it encrypted, so it has to route back through the decryption stream. But I could move that to a separate module and replace it with signed S3 if there was benefit.
So why not just use Google Drive (or dropbox)?
I feel with features like secure file sharing (though only with other ppl with google accounts), reasonably good security[1] and Inactive Account Manager[2] it should work for legal docs. Especially considering Google is going to be around for a while.
I would rather use a Mozilla offering but they don't really have too many things for regular consumers outside of firefox and send.
[1]: https://myaccount.google.com/security [2]: https://support.google.com/accounts/answer/3036546?hl=en
Google reads (and censors, not that that would be an issue) anything added to Drive (and uses that data to target ads at you). And Docs is primarily aimed at collaboration rather than secure file sharing. And revoking permissions isn't easy. And it's all tied up in to Google identities, which may or may not be a recipient's personal Google ID rather than their professional ID - everyone has a separate work email, not everyone has a separate work Google ID.
Dropbox is designed to synchronise a folder between two devices. You can use it to share documents, but that's not what it was designed to do. And if someone deletes it off the shared folder, it gets deleted for everyone... not ideal in this use case. It also creates a dropbox folder on the user's hard drive, and will automatically upload anything in that folder, and copy that to everyone else sharing that folder... it's democratic when this use case needs to be authoritarian.
Does that make sense?
But, if I'm logged in, it looks like Mozilla's storing that fragment on their servers: if I upload a file from one browser, then sign in on a different browser, I can see the link I generated (including the fragment) from the first browser in my list of uploads, and I can download the file.
Doesn't that negate their end-to-end encryption if Mozilla servers have access to the keys?
Volafile’s multi-file “room” functionality, with chat, makes it more suited for sharing files among multiple people, while Firefox Send is optimized for sending a single file to a single person or a targeted group.
Is it possible to audit the tech? Is Firefox send open source?
"Firefox Send: a free encrypted file transfer service"
1 to 100 downloads, 1 is the default; or 5 minutes to 7 days, 1 day is the default. And an option to protect with a password.
Upon expiration, entering the URL behaves the same as if you enter a bogus URL, it's basically denied to have ever existed, i.e. it doesn't say this URL has expired.
So what happen once this get popular and waiting to be abused? Just like Mega. Who is going to continue and foot the bill?
about revenue, there are so many valuable directions this can go. It could undercut competitors in ways they cannot sufficiently respond to. (google responding in kind would leave them less reason to not add encrypted storage for drive) By stabilizing this platform they can start to build new privacy-enhancing apps on top. Calendar, contacts, etc. With more dependency on the platform, they will find areas where more storage, longer retention, will be income generating.
privacy may be the only frontier that can displace google,apple,microsoft.
Tutanota also provides free encrypted file transfer service.-- Tresorit Send:https://send.tresorit.com/ ,which allows you to upload and share up to 5GB files using the same end-to-end encrypted technology.
Elseways, It might be that they have bigger plans with it. This might be just a product to learn about market potentials.
Mozilla's manifesto is all about the Internet and Internet privacy. File sharing is one of the areas where the internet is losing privacy.
Edit: mine was actually (partially) better because it assigned a short PIN instead of a full link, which meant you could just look at it and remember it for typing-in, instead of requiring a separate channel to "send" the link.
The motivating case was when you're in physical proximity to the destination device, but don't have any account linkage between the two (not even messaging/email/social accounts that are connected). The original idea came from university computer labs: transferring homework between the lab computer and a personal one was a pain. I had to sign into dropbox in the browser (and 2FA), or attach it to an email, or carry around a flash drive (which wouldn't work on phones), or whatnot. Just to move the file three feet. A glanceable code with no sign-in bridged that gap.
Other use-cases include people you don't know very well (and therefore don't have an email, phone number, etc.). We demonstrated the prototype to a crowd by uploading a file with the code visible on the projector, and suddenly everyone in the crowd had the file. That was pretty cool.
That's basically a hello world project. As you found out, the hard part is everything else, like funding it.
Honestly half of why I took it down is nobody was really using it. I didn't work terribly hard to market it, as I had no aspirations of getting rich and it would've been tenuous to monetize at all. I just told friends about it, etc.
I didn't imply there was a "hard part" to it. Just a neat idea. No need to dump on it.
About 15 years ago, my sites were pushing 400-600mb/s non stop. Nowadays, I barely hit 1% of my network cap at each VPS location.
It was called "Catch"
Here, I'll type the download link for you: https://firefox.com
P2P would be much better, but this isn't that.
Hope Firefox Send solves this ever present problem ;)
Back in my hacker day I used to have an SSH server open on my cellphone and use it to transfer files back and forth with my computer. Why isn't there a mainstream service like that?
EDIT: I know you said without going through the internet. Syncthing can be configured to only transfer over specific networks (e.g. home LAN/WI-FI)
I keep my phone's picture in sync with my personal computers ("send only" so I can remove old photos when my SD card is getting full).
I sync a "media" folder where I dump all the music and video I download with the youtube-dl CLI (a "yt" alias makes sure the files are stored in the right directory with some custom parameters).
I sync my KeepassXC databases (work and personal), between my personal Linux laptop, my Android phone and my work MacbookPro. Databases can be merged in a single click if there's any conflict (happens very rarely). I love the Android secure autofill service and fingerprint quick unlock
I use a "temp" folder to drag'n drop stuff between computers so I can file it properly on the right device. On Android, I prefer to use the Syncthing "sharing intent" to make any file/media available on my other devices in just a tap.
I also have installed Syncthing on my Android TV, and occasionally drop HD movies that I download on my phone over P2P (I have a pretty fast connection, so it's easier for me to choose a move from my phone, while in commute, have it download in a few seconds, and either stream it to my TV via Chromecast or open it from the synced folder through Kodi)
This really is a dream setup.
Here is the related issue: https://github.com/syncthing/syncthing-android/issues/29
I'm sure people who know more than me will give me a list of great reasons why it's not straightforward to implement...
But it doesn't change the fact that I have this incredible device (iPhone X) with 256gb of blindingly fast NAND flash storage, of which I am only utilizing 30gb, yet I still have to tote around a f*ing stupid little plastic USB dongle if I want to copy some files around.
Nah, Android phones have done this forever, it's not technical difficulties stopping it from working. It's The Apple Way. They don't want you using your phone that way, or something.
It sounds like the only thing that would’ve satisfied you would’ve been for iOS to natively understand whatever the Microsoft system is for broadcasting videos? I agree it would be delightful if Apple and Microsoft could agree on a “I’m a short term drop-point” “send to any nearby open drop-point” API, but the absence of this doesn’t seem likely to be either Microsoft’s or Apple’s fault.
The Apple way to do this would’ve been to send an iCloud email. Apple Mail would’ve uploaded the file to a server, and a short-lived link would’ve been created, to avoid SMTP size limits.
Pretty much exactly what you ended up doing but manually via Firefox Send.
Since iOS 12 they also have a "copy iCloud link" share option that gives you a Dropbox-style file download page.
What could be done is to dedicate a file on the phone as block storage, and expose that as a mass storage device. This would suffer from the same problem (of the phone not being able to access it at the same time), but if it's dedicated "flash drive emulation" space then perhaps this behavior won't be as surprising to the user.
I don't think that's true. My S8 storage is mounted and accessible from my computer right now while at the same time playing music from the same storage. I can still take pictures/write to the storage.
Pointing out that the protocol used is leaky or bad in some technical way doesn't change that Android phones do in fact show up as removable storage devices when connected to (at least Windows) PC's. Your original assertion was incorrect.
samcday even said they just wanted to copy some files around. You don't need to be able to modify files in-place from the PC to accomplish this.
Android devices don't support UMS anymore.
They don't? Since when? I still have a Pixel 1 but it's running Android P, so the latest major version of Android, and this still works fine.
Wikipedia tells the sordid story: https://en.wikipedia.org/wiki/Media_Transfer_Protocol#Compar...
Nevertheless, it's still removable storage that can take the place of the most common use case of portable flash drives: moving files around from one computer to another. Which is explicitly what we were originally talking about.
Pointing out that it doesn't work for some other use case that you yourself brought up doesn't make any sense. That's not what everyone else was talking about.
Ultimately this is an argument about the precise semantics of "removable storage". I don't regard an MTP device as "removable storage" - it's another computer that one speaks to using a special protocol, with severe limitations. So is an iPhone - with special, protocol-speaking software, you can certainly put arbitrary files on it. I interpreted the parent to mean that they wanted to plug the phone in to "any PC" and have it Just Work. MTP isn't so great at that, especially from my perspective as a Linux user, where MTP support is no more built-in than iOS-protocol support. From this standpoint, "removable storage" == "USB mass storage".
On the other hand, it sounds like whatever Apple provides is much worse even than MTP, and less well supported in general.
This is absurd. You don't get to tell someone, "you're wrong", then later when it's pointed out that the original assertion was actually true, then say, "oh, I meant that you're wrong as long as we're using my version of the word, the one that's very different from the one everyone else was using."
Sorry, but that's blatantly disingenuous. The original context was very clear. If you really meant, "well it sort of works as removable storage in one sense, but not in this other sense" you should've just said that to begin with.
As a possible explanation for this issue, I think that if you use the internet to share data, it's more likely that Google makes money from some of the interactions (either via ads in the app or via play store tax or idk because the service is hosted in GCP or whatever) than if you used an internet-free method, so Google doesn't prioritize bugfixes that would hurt their revenue. Edit: would love to be proven wrong though!
The argument from apple is even if you put a warning label on on a setting "allow filesystem access over SSH" for example, if you give users unmanaged file or other systems access, it will be exploited and in reality, what most users (or at least my mother and father) want is to just use their phone and never think about it.
It's fair not to like it and it may be wrong, but to imply that apple did it just to frustrate power users is either misinformed or dishonest.
Lastly there's a cool ios project https://github.com/tbodt/ish that gives you an emulated shell. Works pretty well.
Your only option today is MTP on Android, and it stinks.
At one time, Android did support showing up as a mass storage device. I know when I first got a G1, then the phone I had after that - both you could plug in, and they appeared as a mass storage device. Just like a USB thumb drive.
I don't recall if you could use the file system at the same time on both sides; I doubt it, though. This was never a problem for me. It just worked - just like a thumb drive.
Then something changed; I don't recall which Android version, but they gradually phased out the phone appearing as a USB drive, and started to phase in MTP. I recall MTP being absolute POS on Linux, barely workable everywhere else, and where it did work, it was slow.
It's gotten better over the years on all platforms, but it still isn't anything like it should be.
My theory on why they switched was to keep people from easily side-loading APKs, and backing them up easily, etc. I think it was all part of the battle to keep people from really owning their phones, keep them from rooting them, etc. The ever and ongoing battle in which nobody really wins, everything is left as rubble, and the results are futile, because if they lock things down completely, the people that want things open will just leave to create their own devices, and they don't really gain much.
As an aside - that's a direction I've been thinking about pursuing. There are now some relatively cheap 4G modules out there, and some open-source "phone" operating systems for the Raspberry Pi and other embedded controllers (with varying levels of "working-ness"). I'm just getting tired of not really owning my own phone, and I want to do something about it.
My current phone is an S7 (TMobile version) - and they've made it hard as heck to actually root; it seems like every time they come out with a way to do it, Samsung/T-Mobile updates to prevent it. I'm just tired of the whole cat-mouse thing; I want things completely open, even if it means I have to write my own apps.
Or, more realistically, by having file access mediated by the phone, you can:
* have the filesystem available to multiple systems at once. If it's mounted as USB mass storage then it must stop being visible to the phone itself. That's not great, especially if there are apps etc. there. To not have apps there, you'd need to partition. That sucks. So, also...
* you can use any filesystem you want. You're not restricted to things like VFAT. By not being USB mass storage, you can run BtrFS if you're so inclined and not have Windows get upset when you plug it in.
* the phone is able to restrict what is seen by the computer. This is a security benefit. I don't want someone slurping my TOTP key database because I foolishly leave my phone unlocked somewhere.
Also, you can still root phones just fine if you buy one that isn't user-hostile.
So, there are solid technical reasons for the change that make things better for a large number of users (who, amongst your average user these days, really wants to plug their phone in to the computer to move files around? I'd estimate vanishingly few.)
> My current phone is an S7 (TMobile version) - and they've made it hard as heck to actually root; it seems like every time they come out with a way to do it, Samsung/T-Mobile updates to prevent it.
Well of course they do. a) they are use hostile, so they don't give you a path. b) because there's no official path, any method that does exist must be a security vulnerability. Do you want to have a vulnerable device?
Don't buy user hostile stuff and then complain that it doesn't let you do what you want.
I bet it was simply to prevent having to implement FAT32 or some feature related to FAT and pay royalties to MS for that, like long filename support or similar.
This is why MTP was created. However MTP is - in my experience - complete garbage and creates as many problems as it solves.
So yeah, apple is only mobile you cant do this on at all, and apple is only desktop OS you cant access other phones that permit it on (without installing some 3rd party tool).
As an aside, I write this as an apple user (iphone, ipad, watch, macbook pro), and Im feeling quite infuriated thinking back on this.
I get the point of MTP is that is't supposed to be a transparent (to the user) interface but my experience is it falls short by a long way of achieving this in practice.
But, they don’t let you access to full file system for some reason.
Instead, there are these 3 ways to share files between your phone and other machines: https://support.apple.com/en-us/HT201301
You may also want to check Syncthing, which others have also recommended.
[0] https://userbase.kde.org/KDE_Connect/Tutorials/Useful_comman...
That uses MTP which the OP already discounted as being "a mess". Frankly my experience matches his and thus I actively avoid MTP whenever I can.
> I think the problem is if its too easy then people will be copying files off of each others phones without permission.
You usually need to unlock the phone to use MTP. If an attacker has access to unlock your phone then it makes no difference if they copying the files via USB, Dropbox, email or whatever - your attacker already has the permission they need to do so.
1. P2P doesn’t give Google all that juicy mineable data that they get when everything you do makes round trips through their servers.
2. This would also implicitly encourage Android users to rely more on services like Google Drive/Docs for all files, which is good for them.
Edit: Apparently it is disputed that iOS has superior P2P file transfer support vs Android (see reply below), so perhaps all this is a moot point. I was assuming the truth of the parent post, and didn’t realize it was contentious; and since I’m not an Android or iOS expert, I can’t really argue that topic either way.
It's a feature of the Files app https://play.google.com/store/apps/details?id=com.google.and... which has over 100M installs.
Look at the 3rd screenshot.
ENCRYPTED FILE SHARING
Files’s offline file sharing is secured with WPA2 encryption, providing a more secure file transfer. Files app uses Bluetooth to set up encrypted and direct fast wifi connection, so that you can transfer app APK or large files in seconds, send videos or pictures to your friends. Safe and secure.
SHARE FILES OFFLINE
Share your pictures, videos, documents, or apps with others nearby who also have the app. With fast speed up to 480 Mbps, it’s fast, free, and it works without the internet, so it doesn’t cost mobile data. Just pair up your phone with anyone nearby who has Files app.
If you're using Android, you could just use USB transfer using Android File Transfer [2]. Super easy, super fast.
[1] https://www.resilio.com/individuals/ [2] https://www.android.com/filetransfer/
IMO if something doesn't require the internet connection, it is more likely to be called "software", not a "service".
Not technically internet so much as intranet.
Your comment took me a little by surprise actually because there's no actual need for the internet in SSH and in fact I probably do 90% of my SSHing on local networks. But I guess your usage differs significantly?
I do use this arrangement with split DNS: inside the local LAN, the desktop's DNS resolves to the desktop directly; outside, it resolves to the gateway's external port, whence it's NATed to the desktop. SSH from anywhere :)
I do have an iPhone and I love AirDrop for sharing photos with the few friends who also have an iPhone but it's not even an option for me with a Linux laptop.
So not so much for my Linux box or my Android phone, then. As usual with Apple's shiny crap it "all just works" as long as you're only playing inside the walled tarpit.
woof -i <ip_address> -p <port> <filename>
termux: https://play.google.com/store/apps/details?id=com.termux&hl=....
woof: http://www.home.unix-ag.org/simon/woof.html
Edit:
1. Allows directory upload/download (tar/gzip/bzip2 compressed)
2. Local file server (doesn't go over the internet)
3. Allows upload form (-U option)
4. Allows file to be served <count> number of times (-c option)
KDE Connect, https://community.kde.org/KDEConnect#What_is_KDE_Connect.3F i've been using it for years
export $(dbus-launch)
kdeconnect-cli -l
*then I sent the file from the phone*
What I'm really looking for is a Share button enabled app that can POST arbitrary files to a customizable URL.
Proprietary but free as in beer.
https://github.com/andyholmes/gnome-shell-extension-gsconnec...
Works great, and I'm planning on integrating that functionality into my project which transfers files between laptops using only wireless cards, no LAN required. https://github.com/spieglt/flyingcarpet
If there's any chance of this thing being exposed to a public network (like, say, a cell network), I'd say that's a very good thing!
I run the reverse; my laptop runs sshd and then I ssh/scp/rsync from termux on my phone. But either way works.
We have tons of protocols for transferring files over networks, there's no reason for them to go to the public Internet, nor for them to be mobile phone specific.
It seems like this should be a solved problem but maybe it takes a Mozilla or some other larger entity to push the marketing and the customer support and development to really solve the problem of transferring large files securely.
It's decentralized, end-to-end encrypted and does local discovery of devices on a LAN so it will also works offline.
As long as one device lives and is synced, I have a copy of the files.
cd my/directory && python3 -m http.server 80The correct way to do this is to configure your phone to emulate USB mass storage and then connect with a USB cable.
Your phone looks like a thumb drive. It's the easiest workflow in the world.
Unfortunately, this workflow is off limits because of some licensing requirement from MS for fat32 (or something) which is why neither android nor ios has this very basic, simple feature.
> We receive IP addresses of downloaders and uploaders as part of our standard server logs. These are retained for 90 days, and for that period, may be connected to activity of a file’s download URL. Although we develop our services in ways that minimize identification, you should know that it may be possible to correlate the IP address of a Send user to the IP address of other Mozilla services with accounts; and if there is a match, this could identify the account email address.
Is there something special about 10 or 30? (You wouldn't ask the same question about 10 or 30?)
I understand the need to keep logs to thwart abuse, but with longer lengths you're just helping law enforcement.
Sure they're shorter, but wherever they draw the line somebody like you is going to complain. Putting myself in their shoes I don't see any reason why you wouldn't complain about 30 days (even if you really wouldn't).
> I understand the need to keep logs to thwart abuse, but with longer lengths you're just helping law enforcement.
90 days cannot be to thwart abuse because...? And helping law enforcement is inherently terrible because...?
Helping in the sense that they open themselves up to be strong-armed by LE
As a side note Nightly build for Ubuntu has been broken since version 61 and there's no sign of any effort to fix it.
I thought this would be some cool realtime system to send from browser to browser, using WebRTC or something. Something that doesn't involve them paying for file servers, by the way.
I believed in Mozilla ! But no, here we are and I just don't see the difference between this and Mega.
EDIT: except for the auto-deletion trick that addresses the piracy problem. But still...