This seems like table-stakes for a modern file transfer system. Accepting unencrypted files and storing them temporarily in the clear on your own servers seems like it only introduces tons of additional risks without much gain.
I've been using croc for a few months and it works perfectly: https://github.com/schollz/croc . End to end encryption, command line only, and claims to be "faster than wormhole, rsync, scp through compression and multiplexing (speedups 1.5x to 4x)".
I've been using croc (as alternative for for a while, it's fast and reliable. Personally I think it's better than magic-wormhole in the way that it can be statically linked as a standalone Go binary which is easier to distribute in an environment that one does not have root / administrator priviledge, especially when one has to use a Windows machine with domain/AD login but not a member of local Administrators...
If I might ask a lazy question - do any of these work with basic (e.g easily available on a lightweight container) command line tools on the terminal? I assume not since they must all be Javascript-based.
Ele is a command line tool works with your own cloud.
Main difference from ffsend and other cmd tools is no need to share links, files are referred by file-indexes.
Neat tool. Just read the documentation, for others interested, it is a command line tool where you enter a send command on one machine, it generates a 16-bit one time code, then you type a receive command on another machine (which includes the one-time code) which is used to negotiate a strong shared key that is then used to transfer the file.
The initial handshake uses the 16-bit code with an interactive PAKE algorithm to generate a shared key. An attacker would need to MITM the initial connection and guess the one time code on their first guess. So this gives a network privileged attacker a 1-in-65k chance of breaking into the connection, or if they fail you would see an error message on the sender side. Offline attacks on the one-time code are not possible.
The pre-built program uses a hard-coded server for assisting in making the network connection in order to setup the initial connection (discovery, key negotiation) as well as a TURN server to assist in the file transfer. You can setup and use your own servers for discovery and transit with command line arguments.
Looks like this;
% wormhole send README.md
Sending 7924 byte file named 'README.md'
On the other computer, please run: wormhole receive
Wormhole code is: 7-crossover-clockwork
Sending (<-10.0.1.43:58988)..
100%|=========================| 7.92K/7.92K [00:00<00:00, 6.02MB/s]
File sent.. waiting for confirmation
Confirmation received. Transfer complete.
And on the receiver side;
% wormhole receive
Enter receive wormhole code: 7-crossover-clockwork
Receiving file (7924 bytes) into: README.md
ok? (y/n): y
Receiving (->tcp:10.0.1.43:58986)..
100%|===========================| 7.92K/7.92K [00:00<00:00, 120KB/s]
Received file written to README.md
I believe the "7" in the wormhole code is what's used so that the two peers can find each other when connecting to the "Rendezvous Server" which forwards messages between the two machines to facilitate the key generation.
Dropbox Transfer follows the same encryption protocols as the rest of Dropbox. While at rest, all Dropbox files are encrypted, but end to end encryption would severely limit the functionality of heavily used features like previews and search.
We're always looking to improve and certainly open to suggestions (we have a feedback form on the Transfer page just for these kind of suggestions that the Transfer team actively monitors!).
Not using end to end encryption for personal files in 2020 is fail by design. It's not only a problem that people at Dropbox can read the content, numerous data breaches have shown that this is not a good choice and never will be.
The sad truth is that users usually don't understand the implications until it's too late.
Features like search and preview can be implemented at the client side as well and synchronized between trusted peers. This might be harder to do but it's possible.
Please don't get me wrong, I admire the technological achievements done at Dropbox and their excellent engineers. But sooner or later they need to switch to a secure model as more and more people gain awareness of the security and privacy implications.
> helped us break away from preconceived notions based on what is easy and incremental to build on top of the Dropbox stack.
In my experience, this is one of the biggest challenges for developers involved in product design, expressed succinctly there.
And to try to step out of this is why it's so important to have product owners/managers who are NOT technical staff, and who technical staff doesn't unduly influence. When you've invested your time and energy in building a hammer, you really want to figure out how to treat anything as a nail.
> When you've invested your time and energy in building a hammer, you really want to figure out how to treat anything as a nail.
And to be fair, this is reasonable, right up until it isn't. When every tool costs onboarding and maintenance effort, it makes sense to leverage as few tools as possible to the greatest effect - but much as "everything should be made as simple as possible, but not simpler", you want the fewest tools that will do the job well, but sometimes that is N+1, and a new tool will pay for itself.
But it's really hard to tell when it is and isn't reasonable, when it comes to UX.
I find that the only thing you can do is try to have peopel who aren't developers and don't even know what's "easy to build incrementally on top of the existing stack" determining the appropriate UX for the customer/market/business need.
Then the developers can say "OK, but if we did it like THIS, it would be a lot cheaper to implement because we can incrementally add to what we've got", and the product manager/owner can push back "Eh, that's not going to meet the market need", "OK, but we can't afford it" -- it's a negotiation. But in my experience you really have to have someone who isn't a developer at all standing up for the user need, for anyone who will be involved in the implementation, no matter how smart and user-centered, it's just too tempting to decide that the thing that can be met with the incremental change to existing stack is "nearly as good" no matter what, when it's so much easier and more elegant under the hood.
And Firefox Send has much higher limits too, for free. Without a Firefox Account, the user can upload up to 1GB. And with a Firefox Account, the limit is 2.5GB. Dropbox Transfer, in comparison, provides (just) 100MB in the free tier.
Yea but it doesn't seem like Firefox Send lets you right click on any file anywhere on my computer and just right click to Transfer. The uploading with Dropbox Transfer (through the desktop client) is super reliable too -- I have Time Warner internet and when it invariably craps out, my upload auto-resumes. Looks like this here: https://www.dropbox.com/t/jJNe5IBPrezaw7aE
As an existing Dropbox user, Firefox Send or WeTransfer is not as good a product for me. Because I already have the Dropbox client installed for file storage, I don't need to visit any websites to upload to Transfer. I can literally just right click on any file anywhere on my laptop and click "Transfer" -- then it automatically pops up, I can add more files into it, rename it, etc. and then just send an email or copy link. I screenshot how it looks here https://www.dropbox.com/t/jJNe5IBPrezaw7aE (and it's so easy I find myself just automatically use it). What I really like about it is that it sends a copy of the file and my grandma won't just delete my photos like the good ol' Dropbox links.
I uninstalled Dropbox and moved my files elsewhere because there was NO WAY to disable the annoying notifications asking me to 'upgrade' my account (when my account was almost full). My whole family used Dropbox with paid accounts and I'm actively moving them elsewhere because of this.
The client is now full of all kinds of irritating nagware to enable this and that unnecessary feature, even though I’m a paying customer already. Doing so whilst ignoring the design language of the OS is a hallmark of applications arrogantly deluded of their own importance. The Dropbox client UX now puts me in mind of 90s-era RealPlayer, which surely ranks as one of the worst software products of all time.
I do not appreciate intrusive micromanagement and passive-aggressive interdepartmental memos from humans, let alone from my file sync utility, and when this occurs separately on every god-damn device and even after a time machine recovery, I find myself verbally abusing it, and the product managers that spawned it, aloud in the most vulgar language.
The web interface also went downhill from its initial simplicity. Hitting the download button for a pdf file in my own dropbox folder (99.99% of my use case) has become a whack-a-mole, with a constant danger of accidentally connecting some app with the document, entering some kind of crazy collaborative editing/commenting mode, updating my "profile", installing a dropbox app, getting notified of something, or activating some kind of sharing feature, none of which I ever used or wanted.
When I click the Dropbox icon in my system tray, 43% of the space is used on two ad units: trying to "introduce Gmail integration" and "Recent shows the latest activity." Here you go - https://imgur.com/a/51MiWOb
You silently enabled some new syncing mechanism that doesn't actually download files to my computer. This was absolutely nuts and is a far more serious violation of why I used Dropbox, and it almost made me churn. I was so angry that I had to change some kind of setting on the web to sync with selective sync and have real bonafide files in my Dropbox folder again.
The ultimate nagware: Open folders in: Dropbox desktop app by default is garbage. Obviously people want to open Finder / Explorer, that is the whole value proposition of Dropbox. I don't care about your product manager's monetization schemes or introducing Paper or whatever, please just never mess with defaults because I'm not comfortable suggesting this app to my parents if it litters them with new paradigms and garbage. How do your PMs not understand how important those referrals are? How integral simplicity is to those referrals? Just because you guys don't measure them, just because there isn't a chart going up and to the right, doesn't mean it's not real.
The backups nagware. Nobody wants that. People get they have to store stuff in the dropbox folder. I do not want to confuse my parents, "Sometimes Documents is backed up, sometimes not." It's unambiguous. Again, messing with the simplicity.
The photos nagware. Nobody wants to do that. People use Photos on their iPhone, it's fine. Don't eat up storage on something they use iCloud for.
The Accessibility prompt. You don't need it. Why are you asking for Accessibility?
Permissions to access Documents, Desktop, Downloads without backup. Again you don't need that.
Nagware, adware, product managerware. I hope this is sufficient.
The lack of care here is mindboggling for a product so simple. Everyone should embrace the idea that they're much more likely to make it worse rather than better. Drew Houston should be putting that on a huge billboard behind him on his Zoom calls to 22 year olds fresh out of school, it should be your motto, it should be the first sentence out of everyone's mouth, regardless of what the numbers or metrics or surveys say.
Yep. I’ve been a paying Dropbox customer pretty much from the start. The quality of the current Dropbox is atrocious and I ended up with entire directories of corrupted files full of null bytes as a bonus.
I am looking to move as soon as I find something which isn’t garbage.
I'm mostly a macOS user, so by this I'm referring to the litany of prompts I have to dismiss in the menu bar drop-down.
I just opened it up on this machine and behold, there's a new one, bizarrely hoping I might connect my calendar (no thanks).
Fun fact: I mostly option-click the Dropbox icon to force it back to system style. The UX inconsistency and unwelcome intrusions otherwise just interfere with whatever I'm actually trying to do (usually, pause syncing).
For all the UI badness Real Player had some impressive compression support, at least back in the day. I remember watching the stream of a launch of one of the early ISS modules over what was effectively a dialup connectio. The quality was pretty good for that and you could see what was going on pretty well.
I've been a paying Dropbox customer for over a decade. But I'm also planning on moving away (likely to Tresorit).
One of the things that really piss me off is that they still do not have a (good) way to avoid files from being synced by pattern. This was one of the top-requested feature requests in the good old Votebox that has been discontinued years ago. The community has been suggesting something like .gitignore but for Dropbox. Yet, they only now have added a half-baked solution for that: https://help.dropbox.com/files-folders/restore-delete/ignore... The problem with it is that it relies on xattrs and that obviously does not work for temporary, auto-generated files/directories in the first place. So instead of listening to their community they mainly add features that I cannot remember having seen in the Votebox at all. And they even manage to increase their prices.
PS: Tresorit has that feature and it works very well.
This is something we started providing recently (based on user feedback we heard, like yours). There's now a "let me know when someone downloads" checkbox when you're making a Transfer (both on Desktop & web)
Can you also support "Let me know when the download completes successfully?" I assume this is easy if the recipient is adding to their own Dropbox account, or downloading to their client using a Dropbox client, but may be slightly more tricky with a browser download.
EDIT: In the event my comment was ambiguous, I meant these notifications should be configurable by the sender. Essentially "delivery confirmation" for bits.
I see it now. Thanks for adding this feature. It would also be nice to control other notifications. For example, an email notification for transfer creation doesn't really make sense in 99% of the cases. And I think ideally all those controls should be in the main Dropbox settings (notifications tab). Or at least defaults should be there.
Does anyone know if there's a CLI tool to transfer files? Ideally I'd want to give it a file as an input and then have it return a shareable URL that transfers the file directly from my computer to whoever clicks the URL.
Why is there so much talk about hypotheses and market validation in the article when the product is a straight up clone of WeTransfer almost down to the name?
Right, this is a really good question. Dropbox Transfer achieves the same purpose as WeTransfer with a few differentiators. Unpacking this a bit, there are two parts here:
1) For a company with an established sharing model (shared folder, live-updating links), a departure or addition to this needs to be thoughtfully orchestrated. Moving to snapshotting content, gathering content inside and outside your Dropbox, and enforcing expiration in this tool is a very different paradigm.
2) However, specifically because we are also a storage provider, we can provide a much faster sending experience for them as we can remove the upload step, which is especially important for folks sending really large files. We have a large user base storing their content in Dropbox, this is a net new added value/functionality for them.
Even if the internal discussions were "other services do this and we want a piece of that pie", no company is going to come out in a product launch announcement and directly say "another service is doing this and we want a piece of that pie".
And in this case, I would still hope they did do market validation internally, even if it is just a copy of wetransfer. Just because some other company is doing something doesn't automatically mean it's a good fit for your company to do it, too.
As for the design, it's pretty hard to say that "a generic file selection panel in the middle of a page and a Sign Up button at the top right of the page where it typically is on most sites" is a "straight up clone". The color schemes are similar, but that's just because the main color branding of both companies happens to be light blue.
Same issue on Windows. If you are adding new context items automatically, please have decency to add option to remove them, without hacking the registry. Also, please do not add it back in later update, which happen quite often.
Great work on this. I had to send 100GB files last year (1TB in total) and it was extremely difficult to send them as-is. Most clients that upload data choked while attempting it. Had to break the files up into smaller ones using a compression tool. It actually increased the file size overall but the transfer could then be facilitated.
Hope to see you guys add a feature like DocSend next. It’s like a missing puzzle piece from a utility perspective. I have no idea who downloads a shared file once a url is generated. Would be nice to request emails and get alerts when it’s downloaded.
If you use 7zip on Windows or just split/cat on macOS/Linux, you can split without compressing or archiving, saving you unnecessary CPU cycles (and space).
Hi! Sending groups of files was definitely one of the focus areas here so hope Transfer can be helpful in this role.
Re: Tracking content, we actually do provide this in Transfer. If you specify a set of email recipients, rather than copying a shared link, we provide a few tracking features for you.
1) Record who has viewed or downloaded your content.
2) Remind your recipient if the content you sent is about to expire.
3) (Optionally) notify you to let you know when your recipient has downloaded your content.
What was the most technically challenging part of the project for you? And do you do any tricks for handling failures during very large downloads or uploads (Eg ranges)
The most technically challenging part was probably wiring the storage & sharing side up to not behave like a traditional Dropbox shared folder or shared link (e.g. not take up storage quota or sync down to your machine). There were certainly a long tail of internal reliability work to get that operating smoothly (there are many internal services to work with here).
In terms of tricks at handling failures:
The first (and probably most important) thing is finding the failures. Bug bashing sessions and also just reading failure logs can help catch the trickier transient problems our integration or unit tests do not catch.
In terms of mitigating them, retries and correct error handlers in code are essential (e.g. Promise.catch case should not be ignored!). Retries on the client side are made a bit easier as we chunk uploads into 4mb blocks so any upload errors of actual content can be retried piecemeal.
1) Thanks for your hard work advocating for us and for that interesting writeup, and
2) This was never a problem I needed solved until Dropbox killed the Public folder four years ago. It took exactly two clicks to create a direct link I could send to anyone, and it just worked.
https://send.firefox.com/
https://www.sendsafely.com/
https://github.com/warner/magic-wormhole
https://webwormhole.io/ (magic wormhole over WebRTC!)
This seems like table-stakes for a modern file transfer system. Accepting unencrypted files and storing them temporarily in the clear on your own servers seems like it only introduces tons of additional risks without much gain.