Engineering Dropbox Transfer: Making simple even simpler
dropbox.tech
dropbox.tech
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.
https://github.com/prakis/helloele
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.
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.
% 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
For confidential content OnionShare is another good option.
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!).
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.
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.
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.
- [0] https://send.firefox.com
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.
Not good, Dropbox.
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).
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.
I am looking to move as soon as I find something which isn’t garbage.
For crying out loud, I'm already signed in on the fucking app. I've been using it for years.
Are you trying to drive away paying customers? This is how it happens.
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.
EDIT: In the event my comment was ambiguous, I meant these notifications should be configurable by the sender. Essentially "delivery confirmation" for bits.
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.
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.
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.
For those who don't know: compare the visual design of https://www.dropbox.com/transfer with the design of https://wetransfer.com/. Design and location of key elements are super similar.
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.
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.
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://apple.stackexchange.com/questions/389415/remove-drop...
Not a 1:1 here but very useful tool in the same space.