I wonder if they're running some malware scanners plus do they have to comply with DMCA takedowns? Based on what I see, the files are hosted on their servers, so they kind of have to, no?
Hypothetically, you could wrap this storage solution in a service that automatically creates new underlying links as old ones exhaust their quota or expire.
> 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.
> 10 or 30 seem shorter, no? I don't have anything to say about 10 or 30, but 90 seems too long in my opinion.
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...?
If they're committed to users' privacy how come there are so many FF "privacy tuning" scripts?
Nice service but how is that better than posting encrypted files on one of established web drives (Dropbox, OneDrive, Google Drive, Keybase, etc?)? I can't imagine it's better and privacy-wise it's likely about the same.
Important fact: google is probably best at monetizing this crap, so FF likely can't squeeze more dollars out of the same amount of data, which is why I think this service will ultimately not become popular.
I can't believe that there isn't a simple service to transfer data between my cellphone and my computer without going through the internet. iTunes is terribly bloated, MTP is a mess, and Bluetooth is slow and frustrating.
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?
I seem to remember that there was an app on android that allowed you to access your files via a webserver you could turn off and on. I used that a lot before I got nextcloud.
I've been using it for (almost) everything and it has always work perfectly:
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)
I love it as well, but my one gripe with the Android app is that it does not support read/write sync on external storage (SD cards). This means, in my case, that I have to share photos from my phone in a read-only fashion. It's not a deal-breaker by any means, but it's annoying, because if I want to add photos to my collection that were obtained elsewhere (e.g. my underwater camera), I have to transfer those files to my phone first in order for them to properly propagate to all my other devices.
I would suspect that if you reconfigure your SDCard to be internal storage then it will work again. This is a limit of Android permissions that happened a couple of major versions ago (I use a different tool for file transfer and I remember when it stopped being able to transfer files to external storage).
I suggest to use https://f-droid.org/en/packages/com.github.catfriend1.syncth...
and setup the synced folder on the SD Card as a subdirectory of the app data folder. It's worked well with an old phone (until I replace it with one that no SD card but 128+ GB of storage)
Syncthing is in dire need of an iOS client. There's an unofficial one, but it was unmaintained and didn't sync with recent versions of Syncthing last I checked.
I feel like there must be some iOS limitations as well. Dropbox can't even sync files in the background, so if I take a bunch of photos, I have to leave it running and touch the screen every couple of minutes in order to get all the photos uploaded. I feel like Dropbox apps are generally pretty good, and this was way janky, and had to be an iOS limitation, but I'm not 100% sure.
iOS apps (including Dropbox) can sync data in the background, but it's a bit janky. You have to give the app permission to access location services. It'll upload a bit of data in the background every time your phone location changes.
Tangentially related - I've always thought it's dumb that I can't just plug my iPhone in to any PC and have it show up as a removable storage device.
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.
> I'm sure people who know more than me will give me a list of great reasons why it's not straightforward to implement...
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.
Argh! I just went through this with a friend's iPhone when he asked spur of the moment to have a video on his iPhone displayed on some monitors for a presentation. The monitors are driven by a Win10 computer. My first thought was to transfer the file from the iPhone with Bluetooth to the computer, but apparently an iPhone can't be paired in that manner. So lame. The video was too big to email, so I used send.firefox.com and uploaded the video to it, and then downloaded the video to the computer. Thanks to the iPhone's protective wall that little stunt cost my friend 200MB of cellular data. The computer didn't have iTunes, and there was no Lightning cable available so direct hardwired transfer wasn't an option either.
Beyond AirDrop which only works between like devices, how else can files on an iPhone be transferred to another device without iTunes, and without using a 3rd party? I'm not being adversarial, I really want to know.
I’m a little confused, you don’t want to use 3rd party apps (like a Microsoft app to interact with nearby MS stuff) AND you don’t want to use Apple 1st party apps?
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.
I don't understand your confusion. What I would like to see is the iPhone to support the use of its native Bluetooth radio to connect to another device with a Bluetooth radio and implement the native Bluetooth file transfer protocol. Why would I want to use a 3rd party app/program which incurs a data charge to download, and possibly an account setup which means information leakage.
Android phones don't do this anymore, for the technical reason that allowing a computer to mount a filesystem directly requires that the phone unmount it. Mass storage expects a block device, so there's no wrapper that one could provide that would make this work with the native filesystems of the phone.
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.
> allowing a computer to mount a filesystem directly requires that the phone unmount it
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.
You said "Android phones don't do that anymore", "that" referring to "have it show up as a removable storage device".
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 phones show up as MTP devices, which are basically file-level storage instead of block-level storage. Most OS's (besides MacOS) will display this with the same interface as a USB mass storage device.
MTP is a horrible protocol which renders the abstraction very leaky in my experience, to the extent that it's inaccurate to refer to it as "removable storage" and expect to behave in similarly sane fashion to a proper flash drive. For example, there's no support for modifying a file in-place - the entire file must be read out, modified, and then written back. These kinds of restrictions render it slow and unreliable.
> MTP is a horrible protocol which renders the abstraction very leaky in my experience
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.
I'm not going to debate you in three places at once, that's just obnoxious and clutters the thread.
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.
> Ultimately this is an argument about the precise semantics of "removable storage". I don't regard an MTP device as "removable storage"
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.
MTP is super buggy tho. Sometimes I can get it to work, sometimes I can't. Thought it was the fault of GNU/Linux on the desktop, but I've heard similar stories from Windows users. Most people I've spoken to are just annoyed about MTP.
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!
Android and iOS user. I"m not defending it per say because the frustration of a real shell existing (I've jailbroken iOS and used it) but no access to it is real.
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.
> 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.
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.
> My theory on why they switched was to keep people from easily side-loading APKs, and backing them up easily, etc.
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.
Other vendors used to allow you to do this back when internal storage was vfat formatted but it's not been an option these days because Windows and Macs wouldn't have the file system drivers to read the storage.
This is why MTP was created. However MTP is - in my experience - complete garbage and creates as many problems as it solves.
Mounting MTP is transparent to the user on non-apple OSes as well. You can drag and drop files as you could when it was when mounting the VFAT block device. Its only on MacOS that this isn't handled gracefully.
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've used MTP and my experience is it that it leaves a lot to be desired regardless of the platform. My wife's Samsung phone never worked right with her Windows 7 laptop. Neither my Huawei nor the HTC handset I had before worked properly with any of my Linux machines either.
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.
I recently switched back to iOS after years on Android, and on this point I've been very impressed with Airdrop. Dead simple UI, very quick transfer speeds, uses WiFi or Bluetooth as available. It's just a shame that it's limited to Apple devices.
Isn’t it because it’s limited to apple devices that it works so nicely? Even some times before recent updates they’ve made, ive had airdrop work improperly where my old MacBook Air wouldnt show up, etc etc. it would be a nightmare to get that working across android and pc devices
The conspiracy theorist in me wonders if Google simply wants to maximize the use of their servers here (independent of what users want/need):
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.
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.
It's not really necessary on a desktop or laptop., Unlike an iPhone, all you have to do to transfer to a desktop is plug in a USB cable. After that, you select to share your storage with the PC on your android phone and you can operate on it as if it were a USB drive or a digital camera. On an iPhone you have to install iTunes, log on, jump through a bunch of hoops, and then you only get access to a fraction of the phone's filesystem anyway.
Just to be clear, Wifi network doesn't need to be available. If I remember correctly, initial connection setup is done through Bluetooth, then one device invisibly sets up an adhoc wifi connection to the other to transfer. The two devices don't have to be attached to a Wifi network. Quite spiffy.
Plugging in a USB cable still works fine. I think the problem is if its too easy then people will be copying files off of each others phones without permission.
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.
A number of Android File Managers these days (Amaze comes to mind) include a toggle option to turn your phone into an FTP Server. You would then just pull it up on your computer via ftp://192.168.X.X and put an optional user/pass over it. I've used that for many years if I need to quickly transfer some documents or songs between devices.
I use Syncthing, personally. It usually works pretty great, the only real issues I've seen are with locked down internet connections (the sort which also seem to meter or block VPNs).
I just use iCloud Drive. Files on my desktop and in my documents folder get automatically synced to my phone and vice versa. It's extremely easy and painless. I often find myself on my phone, saving a file to my iCloud desktop, and finding the file on my desktop the next time I open the lid of my laptop.
I'm a bit confused, in what sense is accessing an SSH server not going through the internet? Was the phone connected to the same LAN as the desktop via Wifi?
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 don't think that is a fair assumption because it's very common for people to set up WiFi on their phone. In fact you'll often find some platforms will not download OS updates or warn you against downloading larger "apps" when not connected via WiFi.
A mobile network is still mostly a fallback "if there's nothing better available", and IIRC all current smartphones prefer a WiFi link over a mobile one (if one is up). Perhaps with 5G, we might get to the point where WiFi is too much hassle to set up...
That's the usual arrangement, yes: phone - WiFi AP - ethernet switch - desktop; no internet needed. SSH is not some only-works-in-the-cloud magic, just a TCP/IP service; as long as you can access the server, it is cloud-agnostic.
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 :)
It does - just so long as you and anyone else you might want to share with are paid up into the Apple walled garden.
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.
> copy text, images, photos, and videos on one Apple device and then paste the content on another Apple device
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.
On iOS having a file manager web server is a common workaround, some apps like VLC even have their own. The only issue is that the server stops if you switch apps. There's also iMazing which uses the iTunes protocol and is pretty good, but unfortunately is paid.
You might be interested in KDE Connect, which provides (among other things) essentially a thin wrapper around SSHFS. It's the most convenient method of computer<->phone transfer I've found.
AirDroid is pretty handy on Android; file transfer, browsing your phone's files/images, sending SMS from your desktop browser (although Messages now does that native) etc. Much to my surprise, there's also an iOS version - https://itunes.apple.com/app/id1194539178
When pushing files from phone to computer, I setup my Pixel to use AndFTP. The ubiquitous "Share" button offers AndFTP as an option and lists preconfigured destination SSH servers. I upload photos this way to a distinct account (which gets scooped up later by a more privileged script).
What I'm really looking for is a Share button enabled app that can POST arbitrary files to a customizable URL.
What I'd like to see is an app that runs a webserver on my phone to share a slideshow of pictures or videos to a browser on the lan. I haven't found this and I'm thinking about writing one.
There is. It's called dukto (http://www.msec.it/blog/?page_id=11), and works on mac, linux, windows and android. It will use zeroconf to automatically find all duktos on the local network, and let you send stuff to them in a blink.
There are plenty of cross-platform local file transfer tools available but they all require manual setup and some knowledge of networking. If "without going through the internet" is a requirement, I don't think an easier and secure tool could be made better than what's already available.
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
SimpleSSHD is a simple ad-free open-source SSH server for your Android phone (available on Google Play). It's very useful. It only supports public-key based authentication, so you can't use a password, however.
I often first try MTP and when it is acting up again, I'm using adb pull / adb push to do it. Once set up, adb turns on automatically and all you need to do is to invoke the commands on the computer. If USB is unavailable, adb works via the network as well, provided the phone's IP is reachable. However, you need to know the ip address. The only problem really is figuring out the paths, but at least it works and overall I'm wasting less time than with MTP usage.
You can literally do that; termux will run sshd quite happily. I'm pretty sure there are sftp servers in the app store as well, but I don't really trust them.
I run the reverse; my laptop runs sshd and then I ssh/scp/rsync from termux on my phone. But either way works.
If you use Apple devices, it's called AirDrop and works surprisingly well. I use it a lot, between computers, phones, and ipads, within the family and sometimes with other people, too.
SMB over local network would be my default, I recall an app for using SMB with Android back as far as the 2.x days.
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's because the whole app ecosystem is proprietary and the open source packages aren't as polished. I remember when it was a huge pain to use Bonjour.
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.
I'm on Android, and Syncthing is pretty seamless once configured. I just configure my cellphone, my laptop and my desktop to sync a specific directory in both directions.
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.
There are a few around...I use File Explorer which can actually start an FTP server from my phone (iPhone) that my PC can connect to over LAN. It also can be a client to a remote FTP/file share.
"I can't believe that there isn't a simple service to transfer data between my cellphone and my computer without going through the internet."
The 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.
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?
The files are available up until they have been downloaded (from 1 to 100 times) or until a certain timeframe has elapsed (from 5 minutes to 7 days). See the screenshot at the article.
We are working on a plugin for BitTorrent that will automatically re-upload a file to Firefox Send when the old link expires and then make the new link available in the torrent.
One really big advantage of Send over attachments is that you don't have seemingly immortal copies of the files hanging around in people's mail clients and/or IMAP servers.
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...
But that would require more brain and effort. Since many users are usually behind a NAT, some NAT-traversal is neccessary. Combined with a robust detection (for shitty networks) and fallback to "normal" servers ... you get the idea.
I think Syncthing has a good model for this sort of thing. Anyone can stand up a rendezvous (and/or relay if you want) server which joins the network and starts helping people traverse NAT.
As far as I can see, this requires S3 or a S3 compatible service. Kind of defeats the purpose of self hosting unless you can set one yourself (it may be, I didn't look).
EDIT: Apparently there's a way to use filesystem instead of S3, it's just not well documented.
FWIW, It took me about 5 minutes to get it going after I updated nodejs to version 10. It took me another 5 minutes to realize it setup a local filesystem storage in $TEMP automatically. I was impressed with how easy it was to get going, and that it picked sensible (though not well documented) defaults :)
It doesn't exactly meet the needs of "sending files to a non-technical person", but Magic Wormhole [0] has been truly great for flipping files around between me and anyone who is capable of being trusted to run `pip install --user pipe && pipe install magic-wormhole`. This is by no means everyone, but it's been very useful quite often.
I have no clue why you would suggest a tool that requires using a linux command line after telling firefox send doesn’t meet the needs of non-techical person.
I remember elementaryOS had a GUI for this in its app store. Never got around to try it, Linux is not well known in the consumer world, let alone Elementary
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.
I typoed. I meant `pipx`, not `pipe`. My phone tried to help.
`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
I wish Mozilla focused on core Firefox functionalities instead of coming up with so many small side projects that don't target their typical audience. Since Chromium-based browsers are not an option, many of us are stuck with Firefox as the only remaining choice. But even Firefox has to be heavily customized before it's completely deGoogled and stops contacting various motherships.
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.
Is there anything specific you are missing in Firefox today? Or is it purely the fact that it's broken since version 61? Did you submit a bugzilla issue, or know the existing number? I'd be happy to check it out.
A million things, like missing functionalities from the new extensions api (meaning no Pentadactyl), no good way to manage keyboard shortcuts, having to disable many google integrations after installation, no way to disable "do not track" if using built-in tracker blocking, no sidebars a la Vivaldi, buggy rendering (e.g. transitions animating elements using css transforms), unexplained slowdowns, lack of proper tab isolation (one slow/crashed tab takes the whole browser with it), etc. I could rant all day.
Thank you! This is great input to us, it just needs a few more details to become actionable: bugs filed (for things that are not by design, of course, like the extension API), repro steps and detailed information provided. If I can reproduce it, I can file bugs myself, but I still need to get some clarifications on how to reproduce.
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."
I've used Firefox Send for several months while it was still a test pilot program. It's been very useful for quickly sending files to family. The fact that the link expires as soon as the other party downloads it means I don't have to worry about clean up.
No one I've tried it with has ever had it fail on them.
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.
I can see benefits to keying off the IP, but also to keying off some cookie that can expire shortly. One of the reasons I imagine a download might fail could be because of a spotty of problematic VPN or proxy, or attempting to get it from a location that can't handle it well if somewhat large (some random coffee shop wifi that's overused).
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.
If they did, you could abuse it by just trasfering every byte except the last, add that in a custom link to complete the file transfer and have unlimited distribution ;) I think it's best the way they did it.
Did you test to see if the download could be resumed?
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).
Do you ever run into a problem when an overzealous email service or virus scanner pre-fetches the link and invalidates it before an actual person clicks on it? This used to happen with all sorts of links in emails, though I haven't heard about it in a while.
To my knowledge, the link is only invalidated if the person actually downloads the file. Simply viewing the link does not invalidate it. I can recall a couple of times emailing a Send link to my brother, then checking it in the morning to see if he had grabbed him or not. It was still viewable, so I deduced that he hadn't grabbed it yet, sent him a follow-up e-mail ("Hey you lazy bastard, grab the damn file before it automatically expires!"), and checked again a few hours later to find it gone.
> To my knowledge, the link is only invalidated if the person actually downloads the file.
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.
The easy solution is for the link to lead to an interstitial that shows "do you want to view the content? It will be the only time you can do so.", and make the underlying HTTP resource unpredictable (e.g. different ID to the link) so that it cannot be directly addressed.
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.
Which is why you put a trivial password on the file, which isn't included as part of the link.
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.
What if the download was interrupted because, e.g. the other person had a temporary issue in their internet connection? Does the server at least detect that the entire file has been sent over the socket? Does the server at least check that, on a TCP level, receive all the ACK packets it is meant to receive? Of course this still isn't foolproof but it's a good way towards detecting interrupted downloads.
FWIW, I built and successfully ran it on FreeBSD-current. The only hiccup I ran into was that it puked building due to not having /usr/local/lib in its lib search path & not being able to find libxcb. I had to manually add -L/usr/local/lib to the cc args and manually link it. Not sure if that is a FreeBSD issue w/Rust, or something in your package.
Thanks for sharing your solution! Not sure what is causing it (maybe it's OpenSSL binding related), and am currently not really targeting FreeBSD yet.
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.
It's a BSD world thing :). Local (i.e. non-system) executables and libraries go under /usr/local around here (i.e. libraries under /usr/local/lib, binaries under /usr/local/bin and so on, the hierarchy under /usr/local has the same structure as that under /usr).
At least on BSD, you want to be able to separate external 3rd party libs and system libs in case they overlap, so that is why BSDs don't automatically include things under /usr/local.
Cool. Sadly, I don't think the client supports the current Firefox Send version though. Method of encryption has been changed during the last few months.
I had the expectation that it would use WebRTC before opening the link, disappointed on that side. But really glad of the privacy minded offer. I appreciate Mozilla's work and effort towards a more private and encrypted internet!
How is this using end-to-end encryption? It seems like the recipient just clicks a link to download. How can it have been encrypted for that person? end-to-end encryption normally means that there's no way for the intermediary to unencrypt the data but I can't see how that's possible in this case.
Client side JavaScript that encrypts locally befor uploading and puts the encryption key in the url you share with someone that never gets sent to Mozilla. Also client side decryption on the person you shared the link with. It’s end to end.
That's why the key is in the hash part of the URL; the server can't access that (unless it also sends client Javascript that parses it and sends it back to the server, but that could be detected).
What if I'm on a network I don't trust? Is the only option to set a passphrase? More importantly, the UI doesn't call this out explicitly, so uninformed users may think it's "secure enough" without a passphrase.
"(...) 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.
The browser will never send the key across the network by itself because it is in the fragment. Of course, you have to get the url with the fragment off your computer and to the intended recipient, so a MITM of this communication could intercept and download the file before the intended recipient. The intended recipient would know that this has happened, though, as the link will then be expired (assuming it was set to 1 download); if this is a fear, I would suggest adding a passphrase and sending the passphrase out of band, for example over a voice call.
> The url effectively contains the decryption key, so the web server could be set to capture the urls and decrypt files.
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.
IIRC The link contains an anchor `#abc123` which is the decryption key. Browsers do not send anchor parts of the URL to the server, and so the browser decrypts.
Hinges on the browsers never sending that key, though.
538 comments
[ 5.7 ms ] story [ 500 ms ] thread> 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
Nice service but how is that better than posting encrypted files on one of established web drives (Dropbox, OneDrive, Google Drive, Keybase, etc?)? I can't imagine it's better and privacy-wise it's likely about the same.
Important fact: google is probably best at monetizing this crap, so FF likely can't squeeze more dollars out of the same amount of data, which is why I think this service will ultimately not become popular.
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
https://github.com/syncthing/syncthing/issues/4995
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...
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.
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.
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".
[0] http://www.msec.it/blog/?page_id=11
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
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.
[1]: https://nitroshare.net
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.
https://f-droid.org/en/packages/org.primftpd/
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.
The 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.
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.
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...
(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.
https://minio.io/
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.
https://github.com/mozilla/send/blob/master/docs/docker.md
[0] https://magic-wormhole.readthedocs.io/en/latest/ has
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`
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.
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.
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."
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.
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
Where cargo-ld is just a wrapper: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
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.