[1] http://applehelpwriter.com/2016/08/29/discovering-how-dropbo...
https://news.ycombinator.com/item?id=12464730
I don't believe there was any intention of making Dropbox hard to uninstall. I think the intention was to make the process seamless for users, and there was a bug that caused a setting to get reapplied after a user changed it.
I was talking to someone just two days ago, who was tearing their hair out because their application's "Open" panel took something like ten seconds to open. Why? Because the Dropbox extension decided it didn't want to play along nicely. It's foolish to think that your software will not have bugs, and outright foolhardy to do this for so little benefit.
The kernel extension is another example. AFAIK it was added for Smart Sync[1] (née Infinite[2]). Infinite is amazing, truly amazing, and the only way to implement it is via a kernel extension. Microsoft tried to implement it via the GUI with OneDrive's "smart files" (aka placeholders), they removed it because the files didn't work in too many places, like via syscalls and from command line.
Dropbox Infinite is kind of like the source control systems Google and Microsoft created to handle their huge repos. Microsoft's GVFS uses a file system filter driver (kernel extension) called GvFlt (or ProjFS)[3]. From what I understand, Google's Piper uses FUSE[4], which would be a third-party kernel extension on macOS.
My point is, these are technical achievements that provide seamless and intuitive user experiences, they aren't betrayal of trust.
[1] https://www.dropbox.com/smartsync
[2] https://blogs.dropbox.com/tech/2016/05/going-deeper-with-pro...
[3] https://www.visualstudio.com/learn/gvfs-architecture/
[4] https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
You having put a lot of effort in this thread into weaving trust into your description of Dropbox operations, I'm surprised that you wouldn't trust an end user when they tell you that this in fact is a betrayal of their trust in Dropbox.
> Dropbox Infinite is kind of like the source control systems Google and Microsoft created to handle their huge repos. Microsoft's GVFS uses a file system filter driver (kernel extension) called GvFlt (or ProjFS)[3]. From what I understand, Google's Piper uses FUSE[4], which would be a third-party kernel extension on macOS.
I find that your examples really show a lack of understanding of why I'm frustrated by Dropbox's behavior. The products you linked are source control systems used by software engineers. Dropbox is aimed at nontechnical users. One of those groups understands what a kernel extension is, and the other one can't point their finger at Dropbox when their computer crashes. How is this not betrayal of trust? When a user installs an app they don't expect it to literally put its fingers all over the operating system. Not only does Dropbox look like any other application on the surface, it actively works to perpetuate this myth by spoofing operating system dialogs and prompts. If a doctor did a procedure on a patient that they didn't fully explain or even mention that they were doing they'd be sued for malpractice.
Also, I don't really like doing this, but you seem to be overly positive about Dropbox's work in this field. Do you work there, or have you ever worked there? Did you have a vested interest in this project?
https://github.com/facebook/IT-CPE/tree/master/chef/cookbook...
They use Munki for software updates, which, just like you describe, gives the user a grace period where they can reboot at their leisure. Ignore it for long enough and it'll crank up the nagging, and eventually force a reboot.
It talks about killing GUI processes. Is it common to run a display server on macOS servers?
I worked for the corporate infrastructure team at Dropbox, at the time my team was responsible installing/managing things like osquery on laptops, with the data going to the security team's tools, so I have thought about this. Speaking for myself, the Dropbox culture takes trustworthiness very seriously. "Be worthy of trust" is #1 on the list of company core values, and it is deeply embedded into the culture. The trust covers so much of how the company operates, including privacy. Spying on employees is so against company culture, even though I knew exactly what data being sent, I trusted the security team would not use that for anything other than protecting me. The detection and response team is made up of the most security and privacy conscious people I've ever met.
I think the mindset of respecting coworker privacy is important for anyone in corporate infrastructure, including network and system administrators.
But I've worked for other big corporations too, without that trust. I think employees need to know that when they use corporate computers and communications systems, they aren't private. Don't do stuff you shouldn't be doing at work.
> what do you do with all that information? I see how this addresses malware response, and I see how this would be useful as a forensic archive for general IR. But as a day-to-day tool, connection-by-connection, file-by-file granular data
When I worked there the security team reached out to me to ask about anomalous behavior, so there is active detection going on. That was a couple years ago, I'm sure they have improved since then too. Keep in mind, they have a full time detection and response team, in addition to all the other security teams.