- Clearly we need to do a better job communicating about Dropbox’s OS integration. We ask for permissions once but don’t describe what we’re doing or why. We’ll fix that.
- We only ask for privileges we actively use -- but unfortunately some of the permissions aren’t as granular as we would like.
- We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions).
- We use elevated access for where the built-in FS APIs come up short. We've been working with Apple to eliminate this dependency and we should have what we need soon.
- We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).
- We check and set privileges on startup — the intent was to make sure Dropbox is functioning properly, works across OS updates, etc. The intent was never to frustrate people or override their choices.
We’re all jumping on this. We’ll do a better job here and we’re sorry for any anger, frustration or confusion we’ve caused.
To clarify for others: In /Library/DropboxHelperTools, you'll find a folder for each user full of setuid tools which run as root and do various privileged things. I assume that the client is presenting the normal OS X "ask for elevated access" UI and then using that elevated access to configure and install these. (I don't work for Dropbox or anything; I've just been poking around.)
> - We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions).
@newhouseb, I don't have Office, so I've turned off the badge. Is Dropbox now going to leave my accessibility permissions the way I set them? Or is it going to reactivate a permission behind my back that it no longer even needs?
I understand the desire to make your features "just work", but circumventing the user's privacy controls to do that is never acceptable. Especially accessibility, which is basically a general warrant to snoop on everything the user does. You wouldn't be on my system anymore if my work didn't require Dropbox. You're going to lose a lot of trust over this, and it won't even be half of what you deserve.
And it's not even in your interest in the long term. This fiasco has probably made it more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement. Since Dropbox can't really do its job when it's locked in a sandbox, I really don't think that's what you guys want to happen.
Teams like yours are why we can't have nice things.
(P.S. plz respect NSFileCoordinator this isn't Tiger anymore kthxbai)
Yep, we’re going to fix this so that if you uncheck it, we leave it unchecked.
> This fiasco has probably made it more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement.
As alluded to elsewhere in this thread, this is already happening in macOS 10.12. We’ll be switching to the same approach that Steam (among others) do to request accessibility.
Granted my team is small, but we just uninstalled dropbox today. Going to use the web interface and look for another solution in the meantime.
I'd love to see Box or someone else encourage popular apps to support their sync platforms, but I doubt it will happen. I blame Apple for not supporting easy 3rd party integrations.
With that said, on the assumption that it is a way to exchange files between computers and/or share with other users, it would seem to be the case that ownCloud (nextCloud) fits the bill. You can host it yourself (as I do) or use a third party to host it for you. I have been using it for a number of years and I'm entirely happy with it.
Also, depending on your use scenario, another possible option may be https://www.stackfield.com/ a German end-to-end encrypted storage company. I believe there are others offering similar services.
FWIW Kim Dotcom, the founder of Mega, has distanced himself from it, saying the company had "suffered from a hostile takeover by a Chinese investor who is wanted in China for fraud"
So yeah, don't trust Dropbox. Instead trust some shady Chinese characters. Can you name one of them? In comparison, note that Ben Newhouse, a Dropbox employee, is actually posting in this discussion.
There is also the added benefit of encryption
Without full source code to said encryption, all you have to go on is "trust us".
Forced to choose between the two, I know who I'd trust, and it wouldn't be Mega. YMMV.
And they're actually usable.
What does Chinese have to do with this?
Dropbox has done the opposite.
I like it though
Admittedly I'm not a Mac guy, but that can't be common practice.
And then the response isn't "we're going to stop endangering our users with this dangerous practice", it's "we're going to stop doing this one particular thing that happened to be called out this time".
It's not. It's very unusual.
Please feel free to duplicate my radar! Accessibility and Productivity/Utility app developers would love a Sandbox entitlement.
rdar://13570189 - Sandbox entitlement for Accessibility API to allow apps for the disabled
The Accessibility toolkit has always been off limits to Sandboxed apps, and no entitlement exists. This seems unlikely to change. It's unfortunate, as this keeps many good and useful apps out of the Mac App Store.
Without the source code and large amounts of resources it is not possible to determine whether an app is malicious or not. The only way would be for Apple to trust that developers actually do what they say they do. The unfortunate reality is that they cannot be trusted. I don't blame Apple for not taking that responsibility. Unfortunately that means the responsibility ends up with the user who cannot make the determination either. Such is life.
If I unzip a large archive in /tmp, Dropbox is eating 60% of my CPU.
If I open the new Xcode for the first time (and the system verifies all the signatures) Dropbox is eating 100% of one CPU.
It really seems like the Dropbox client is monitoring the entire filesystem (all FSEvents) instead of just the dropbox syncing folders, and doing it relatively inefficiently at that.
At this point if I'm doing anything filesystem intensive I close Dropbox first.
It started with my laptop running incredibly slow. A bit of digging showed dropbox saturating an entire cpu core despite no recent changes being made to my dropbox folder. What was happening at the time is a lot of disk activity on a folder that Dropbox should know nothing about. I'm not 100% sure but it also seems to me that Dropbox is monitoring all FSEvents on my machine and doing something with them.
I've been a paying Dropbox user for several years, but this has tipped me over the edge. The only way to regain my trust at this point is providing an official explanation of what's going on, with technical details. I'm paying for a service to keep my files safe and sync them across devices, nothing more, nothing less. Now that I got the impression that Dropbox is doing something outside of that envelope, even if that impression is wrong, my money is going to go elsewhere, probably to a competitor.
As to the original article, I think you have a lot of explaining to do and a lot to clean up. Too much has been swept under the rug.
Would definitely like an explanation of what's going on here.
It's cool they are moving into the kernel soon anyway, just install their kext...
I thought it was common knowledge that Apple's own sync (nevermind the APIs they provide to third parties) was terribly unreliable. Even long-time Mac developers like Panic & Omni developed their own sync services because the Apple ones were so unreliable.
(Support was prompt but basically “let us know if it happens again”)
Then I start getting console messages like this:
mds (Error) FMW: WE ARE DROPPING FMW EVENTS!
All disappears after disabling Dropbox (and rebuilding caches and the spotlight database)
Behaviour seen on multiple macs I own.
Also I should probably mention that we keep 1 month of version history for free users and even more history for paid users, so if the corruption is recent you should be able to undo it yourself. But please report either way.
(Full disclosure: I work for Dropbox).
I'll log a ticket :-) might need to reproduce the issue first. Pretty awesome that you have employees who respond to posts on HN incidentally, that automatically increases my loyalty to a company several notches!
This has been a long-standing thing with them - some years back there was some stink about the forced Dropbox branding in the Finder (which we now see is related to this). Many people (including me) found it rude that it insists on adding useless widgets, badging icons and inserting crap in the Finder sidebar. For whatever reason, Dropbox (the corporation) apparently believes that junk to be important enough to their business to disregard what the owner of the machine wants, and now we see the lengths they go through to force themselves on the user.
I used to simply consider Dropbox rude enough to make me not want to use it. Now that I see the company is actively going out of their way to break the intended function of security-related OS components, I now consider Dropbox malware and will begin warning others about the company.
Their branding strategy is really annoying. I pay 10 Euro per month for Dropbox Pro, but they have Dropbox Business ads plastered all over the web interface.
Permission systems in general seem like a solution without a problem to me. Nobody but a minority of people very concerned about theoretical security problems wanted them on platforms that didn't have them, almost nobody cares what permissions programs use on platforms that have them now, and people get along perfectly fine and with less inconvenience shoved in their face running programs without permissions systems aside from a simple admin rights/no admin rights today on Windows and Linux.
Even if you trust the software vendor, security concerns can cascade.
What if the hack pushes a rogue client? Or one CDN endpoint serves a malicious update? Or a little bit of code is sneaked into the development process? Or an employee gets sour? Or a million other things that you hope never happen. There is a reason we don't run apache/nginx/any networked service as root. (You don't, right?)
...For values of "perfectly fine" that include millions of malware slaves on the net, hundreds of millions of stolen passwords, targeted 0 days attacking human rights workers, file-encryptor extortion apps, etc. etc. etc.
> What nefarious and yet undiscovered things
If they're undiscovered, how am I supposed to list them?
As far as discovered things, the permission allows Dropbox to sniff the keyboard and interact with any other application as the user. Add that to unrestricted filesystem access, and the right question to ask is what nefarious things Dropbox can't do.
Hell no they don't? They have some shared folders between classmates and a few encrypted archives for personal backups.
2. Dropbox does not use sandboxing (at least, the one I have doesn't)
So, they do.
1) My files are not on their service and thus not available at their discretion; they would first have to be uploaded.
2) With that logic all applications "have" all my files, but you bet I'd find it weird if I caught Libreoffice uploading files of interest to a service of theirs.
That said, I do see your point. Most desktop applications (as opposed to mobile apps) are capable of a lot more than they need to, and even many popular mobile apps are. I just wouldn't say I implicitly trust them with all of my files.
On macOS this is not true though, for well-behaved document-based apps! Sandboxing prevents access to anything you haven't explicitly granted access to. I don't know if Libreoffice implements it correctly, though.
The reason for needing Accessibility API listed in your response is pretty vague, especially for those Mac users not having Microsoft products tainting their systems.
I've deleted Dropbox from my Mac for now. I'm not installing it back till there's reasonable explanation and remedies.
I'm not affiliated with Dropbox, but compare the UX of Dropbox (type in your admin-password and that's it) with the one of Steam (opens the System preferences and forces you to make manual changes). Both need to be allowed accessibility access for one feature or another, but only one of them provides convincing UX.
For us power users, the "official" way is better, sure, but what's the percentage of power-users compared to normal users who actually enjoy the office intrgration and other things made possible by the accessibility API?
I would be happiest if it didn't do the dirty thing and also didn't offer office integration. Maybe that's the change they need to make. But if they insist on doing the things that need accessibility, then the current solution is so much more convenient than the steam dance.
One wonders what Dropbox would say if someone decided to obtain elevated access on their servers by surreptitious means because Dropbox's API "came up short".
Can you please provide an example of such shortcomings and accessibility APIs that are better?
When you designed an agent that specifically overrides the user's choice to turn off Accessibility rights for Dropbox, frustrating that attempt, I suspect that was intentional.
Bob (who less technically savvy) installs Dropbox for use with Office. Chuck (someone more technical than Bob) removes Dropbox from the accessibility list. Chuck has now broken Bob’s Dropbox, and Bob (being less technically savvy) blames Dropbox resulting in another ongoing thread about broken Dropbox.
I completely understand how Dropbox reached this point, and purely from a technical support point of view, how it is justified. There are probably better ways for them to have done this (still have the “hack”, but only insert it if Office applications are detected to be installed; have an option that can turn it off even if Office is installed, but warn about it and make it “easy” to turn back on).
If that's the case, How is it that the accessibility preferences are changed without root authorization?
> "The allow-root property specifies whether a right should be allowed automatically if the requesting process is running with uid == 0. This defaults to false"
So the agent does not (by default) make an exception for applications running with uid 0. It does not say anything about modifying a certain file, it's just about the agent (if I understand it correctly).
> "In other words, if allow-root isn’t explicitly set, the default is that even a process with root user privileges does not have the right to perform that operation. Since that’s not specified in the default shown above, then even root couldn’t add Dropbox to the list of apps in Accessibility preferences."
Same thing again. Agent won't allow, but file permissions are not mentioned.
> "Root wasn’t allowed to override Accessibility, and authenticate was on, so it couldn’t be this way that Dropbox was hacking my mac."
And that's all places where root is mentioned. Later on, however, sudo is used:
> "To insert an app in the list, you grab it’s bundle identifier (in the case of Dropbox, that’s com.getdropbox.dropbox), and issue:
> sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db “REPLACE INTO access VALUES(‘kTCCServiceAccessibility’,’com.getdropbox.dropbox’,0,1,1,NULL, NULL);”"
So sudo, which makes a command run as root, can modify that database.
And as far as I know this makes sense, because at least in Linux file permissions are simply not checked when uid is 0 (root user). Darwin/BSD might differ, but my unix family tree knowledge doesn't go that far.
Also, how else could Dropbox do it? As mentioned in the article, one of the helper applications contains an SQL statement (see the part about running "strings"), so it does seem to be directly modifying that database.
Other Integrations: Too vague to justify what is potentially a large security threat. You've really got to do better than that.
Which API are you using that allows you to circumvent the OS X Accessibility Permissions control dialog? Or do you mean you're simply asking for administrative permissions in order to write directly to TCC.db? And in that case, what mechanism are you using to circumvent the permissions structure to permit you to rewrite to TCC.db without re-requesting the user's permission?
Nice euphemism for "catch all" permissions...
- There are numerous setuid binaries without any documentation or source code available. These have the potential to breed nasty zero-day privilege escalation exploits, possibly worse.
- Dropbox goes out of its way to obfuscate its Python bytecode. This doesn't prevent intellectual property theft: there will always be people capable of reverse engineering it (e.g., https://github.com/rumpeltux/dropboxdec). The only effect that it has is to significantly decrease the security of the application: technical users can't easily review the inner workings without a substantial time investment. Hackers, on the other hand, have massive profits to gain from reverse engineering something as popular as Dropbox, and won't hesitate to do so. This represents a lack of regard for security on Dropbox's part, indicating that they favor intellectual property protection over the security of their customers. When I buy a car, I can open it up, check the brakes, and be sure I'm not going to crash into a tree. I expect to be able to do the same with the software on my computer.
Output from extracting a Dropbox-signed tarball (in this case, DropboxHelperInstall's own tarball):
crypto error while Verifying Signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
crypto error while Verifying Signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
mkdir '/Library/DropboxHelperTools' 0755 -> 17
missing magic number
unable to read_digest
couldn't verify signature
crypto error while Verifying Signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
crypto error while Verifying Signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
crypto error while Verifying Signature: bad signature (in rsa routines:INT_RSA_VERIFY)
couldn't verify signature
Off topic: can you help me understand why when a file is locked (e.g. Outlook accessing .PST file) this causes Dropbox to peg the CPU to 100%.
I've opened multiple bug reports over the years and support dismisses my finding.
This makes Dropbox un-usable for me. I literally have to run Dropbox as "paused" 90% of the time and only "unpause" Dropbox when I close Outlook.
Is it a native OS X dialog API, or native OS X authentication API? I could make a password prompt myself, and call that "being official Win32 API".
Can you show me the class where you invoke it, so I can judge for myself?
If you look under "Authorization Services Tasks" you'll see there's details about calling a privileged installer.
Apple really should kick you from the App Store and blacklist dropbox as malware.
Re blacklisting, I'm referring to Apple's Xprotect (https://www.intego.com/mac-security-blog/topic/xprotect/).
And as for the rest of the privileges, we just take them without asking. Who knows, someone might refuse!
 - http://applehelpwriter.com/2016/08/29/discovering-how-dropbo...
Additionally, AMP wants to become the arbiter of the mobile web. Just look at their list of "Supported ad networks." 
Who gave them the authority?
AMP worries me greatly.
NEVER give this power to a central authority that's not democratically controlled.
And yet, some people still do that mistake.
But you can fork them, so it should be okay, right?
Another way to do that is to strip your page down to core, performant components without loading a JS library from Google. But Google dangles the carrot of improved SEO with AMP, so everyone has to do it anyway.
(note: they don't actually prioritise AMP pages, they prioritise page load speed. But AMP pages are put inside a Google CDN, so, what do you know, they load fastest)
AMP is not meant for page authors — usually, they are painfully aware of how much bloat they add. They don't have a choice when sustainability is in the balance.
AMP is for the ad networks. It draws sane restrictions to what they can do. On their end, ad networks agree to that because Google is a large partner of them and because the worst possible outcome would be having everybody use ad blockers.
This is not solved by AMP, it's absolutely the choice of publishers.
> AMP is for the ad networks.
Not really, you can see their official roadmap. Many of the original principles have already changed and many of the intrusive ad formats are already back in (like autoplay outstream video units). The only real optimization is better async loading which could already be done with proper coding by publishers and ad networks.
This isn't really a solution when many authors use a CMS, like WordPress and others, where the bloat is built-in. Sure you can write a custom theme etc, but not everyone (1) has the ability to do that, and (2) wants to dedicate the time to do that.
AMP integration still a work in progress, but getting better: https://github.com/Automattic/amp-wp
My preference would be to remove the borders/underlines, also remove the bold, and make the margins equal above and below the h3+ headings. If I were to actually use more than three headings, I'd probably do something completely different at the deepest levels (e.g. inline the headings or indent the whole text).
But I think we agree that it's worth some effort to fix up the browser's default styles. It's too bad they can't all just switch to something like Firefox's reader view without breaking the web.
This design isn't responsive other than having some reasonably sane defaults. It's derived from a more complex style that does resize headers and such as the pagesize varies. As far as niggling over header formatting ... that's getting into layout-weenie stuff and sweating the small stuff. The point is to have distinguishable headers. How you distinguish them ... is somewhat moot, though size, colour, underline, margin, typeface, etc., are some obvious dimensions. What I've given here does not, I'll posit, for the most part suck.
It may offend some sensibilities.
What I've started taking a strong liking to, actually, is using CSS numbering to create numbered sections (see https://reddit.com/r/dredmorbius/wiki/faq for an example -- I actually contributed the Reddit code, all one line of it, to enable this). It's a bit technical-documentation-ish, but tends to give a sense of place and structure within a document.
In practice, having too many levels of nesting is probably distracting. A book might have: Parts, Chapters, Sections, and possibly Subsections. That's H2 - H5 in a standard HTML hierarchy, with H1 reserved for the title.
A paper will rarely have more than Sections and Subsections -- H2 and H3 elements, plus h1 for the title. My reddit styling and docs tend to reflect this.
I will use more detailed breakouts when I'm outlining stuff, though I'll make pains to try to flatten the structure reasonably as I can. I'm often digging in the weeds myself, in complex topics, and achieving a workable structure is a considerable effort.
We've had requests for this feature for years. I can't stress how much customers request this feature; it's put a lot of egg on our face that Dropbox beat us to it.
In order to do this on Mac, we'd need to register ourselves as an accessibility client. I don't remember the details about registering ourselves, but from what I remember, it doesn't require hacking into OSX.
We've had to hack into OSX in the past: Adding menu items and icons to Windows Explorer is supported via well-documented Microsoft APIs. It wasn't until about 2014 that Apple supported this, prior to that, we had to reverse-engineer Finder. We didn't get OSX APIs to do this until we hired a contractor with "connections" to Apple he petitioned his connections to provide an API. I know that Dropbox, Google Drive, Box, and an open-source project called Liferay-Nativity all performed the same hack.
Based on my Syncplicity experience is that, what happens in these cases, is that a product manager gets so focused on the pixels that he/she is completely blind to the practical implementations. There's probably a bit of "I told you so" coming from some of Dropbox's engineers now.
I appreciate the trend of Apple forcing Dropbox to stop doing dumb shit, though. (Previously, of course, the SIMBL-style Finder hacking)
There was no other way to do what they did. The only reason Apple added API was because Dropbox came up with an idea that demonstrated the need for such an API to exist.
It's also a very useful feature that served people well.
Personally, I use KDE's file manager (Dolphin). Plus a curl-cased Bash script for when I need to upload an arbitrary file from one of my home computers via my phone (SSH from phone to computer, sometimes over sat link, run "~/bin/upload.sh /some/file").
I manage my own ownCloud servers (one personal, one company), but hosted options are available.
And yes, it does keep file history (optional, enabled by default), as well as encrypted storage (optional, disabled by default).
Neither the client, nor the server even, require any administrative access.
If every app I installed did this then my mac is closer to getting hacked.
Anyway, Apps that asks for root password on installation always makes me cringe, e.g. they could turn on SSH and put a pubkey into authorized_keys, or they could upload SSH identity files. But I still proceed to enter my password.
You don't need root to do any of those things. If you're going to run the SSH server on port 22, sure, but it can be run on any port above 1024 by a regular user in user space.
If you're already running an SSH server, a non-root app can most likely edit your ~/.ssh/authorized_key file. It's just a regular file, nothing special about a malicious app adding an entry to it.
Think a NAT is going to save you? A malicious program can SSH out and create a reverse tunnel to circumvent it.
Short answer: running anything you don't know or trust is dangerous, root access just makes it more dangerous.
That file is -rw-r--r--, so only the owner or root can change it, unless I am misunderstanding you?
1) the Dropbox client stores the password and uses it to hack the accesses db at every login.
2) the Dropbox client runs as root and does the same thing.
Both options are simply terrible from a security point of view
And this is what they actually do.
% ls -l /Library/DropboxHelperTools/Dropbox_u501
-r-s--x--x 1 root wheel 9632 Sep 8 20:10 dbaccessperm
-r-s--x--x 1 root wheel 116668 Sep 8 20:10 dbfseventsd
So, "How Dropbox uses the root access you give it during installation to gain full control of your Mac without triggering the usual popup."
The first bit, for me, is key.
(Not disbelieving you at all, I just haven't understood this part.)
Dropbox doesn't save your password.
...But I am wondering why one of these suid binaries is world-writable.
Slimy, slimy, slimy.
So it's more like "how dropbox uses the root access you give it after installation to install software which will permanently re-add itself to accessibility even if you attempt remove its authorization".
Being an app developer that was bitten in the ass by the new "security" in El Crapitan, and having spent 2 weeks trying to get our app back to normal, this makes me really mad that Apple makes us developers jump through all these hoops for security that isn't actually secure anyway.
$ tree -p /Library/DropboxHelperTools/
├── [-r-s--x--x] DropboxHelperInstaller
└── [drwxr-xr-x] Dropbox_u501
├── [-r-s--x--x] dbaccessperm
├── [-r-s--x--x] dbfseventsd
└── [-r-s--x--x] dbkextd
$ kextstat -b com.getdropbox.dropbox.kext
Index Refs Address Size Wired Name (Version) UUID <Linked Against>
163 0 0xffffff7f835b5000 0x6000 0x6000 com.getdropbox.dropbox.kext (1.7.5)
Finder doesn't have plugins, hence the accessibility API shenanigans necessary to get the same effect.
If you can demonstrate how Apple has access to my files on an OS X installation with no iCloud configured, I will round up a massive bounty.
Your OS does have access to all files that you have on your computer. It manages all network connections. It exposes all information that tools such as little snitch display to you. Apple signs and provides all software updates to you. They control SPI and app sandboxing. I'm not saying that Apple does access your files. I do trust them not to since they've shown that they at least attempt to step up and defend themselves and their users. Still, they could if they wanted to.
I'm still looking for a linux alternative to lil snitch that is just as robust and intuitive - but I'm stuck using a few different things to achieve the same effect. Anyone have a recommendation with a slick GUI (for some reason I really like a GUI for firewall management)
This is correct. Consider, however, the motivations of the people involved. Apple's motivations are to make money from you. Debian's motiviations (intentionally avoiding Ubuntu here) are to make a good user-centric system. Packages are signed by named individuals that I can personally get to know and trust, and with an accessible process - I can download their package sources and build or verify or tweak them the same way that the maintainer can, report bugs and ask questions directly to them, etc. I trust this model much more than I trust the model of a company who, at the end of the day, has a bottom line and will make compromises to ensure it remains where they need it.
Apple is very well known for using proprietary formats, adapters, you name it. Apple's cloud is also write-only, they intentionally make it difficult for you to pull data out of it and interop with other services. These decisions serve the company's interests, not yours.
>how often do you audit source code?
You would be surprised!
>You would be surprised!
It doesn't really matter if you do. OpenSSL is one example showing there are critical mistakes of grand level everywhere, same as there might be cleverly hidden backdoor in that multi-100k source tree (or any of the myriad of dependencies) you "audited".
> You would be surprised!
How often do you audit OwnCloud's source code? (I'd describe it as "naive.")
Plural? Who else?
There's a difference between bringing in a single famous person and the rest of the board agreeing with them on certain issues.
I don't necessarily agree with them, but that's the sentiment here.
Edit: by the way, regarding open source projects, it doesn't matter if you don't look at the code personally. Somebody else does, and if there is problem with it, it becomes a huge public scandal sooner or later.
Perhaps better for limited use cases that don't really apply to the vast majority of Dropbox's user base.
You start off comparing apples to oranges, and with your latter solution, you aren't even comparing to fruit anymore.
I use cloud storage (e.g.) have access to my password file between my computers and my mobile devices. NFS shares on ~/share that only work on the local network don't really solve this issue.
For my passwords I use pass and store them in a private git repo on a server I trust. http://password-store.org
Some people are willing to spend their finite life building personal infrastructure and the rest pay others to do it. You conflate the two at your peril. The best decision I've ever made was to stop running all of my own stuff -- you get literal days back in your life. Days.