Can you please make installing a kext an option, rather than trying to install it behind our backs? If you unload + remove the kext, it gets installed again automatically.

The only way to block the kext is using e.g. Little Flocker.

Moreover, the kext does get installed on my machines and I have a Pro account without Smart Sync.

I have been pondering to uninstall Dropbox, because all this behaviour is not acceptable. Unfortunately, I haven't found a good alternative yet.

Can you check if you're in the (opt-in) Beta Channel by looking at https://dropbox.com/account at the checkbox that says "Include me on early releases"? It's not uncommon for folks to have clicked this long in the past and not given it thought since.

Yes, I am in the early releases channel, sorry for not mentioning that in my earlier comment. But I still don't see why it should install a kext for functionality that is not provided?

The beta channel exists so that we can ensure upcoming components are stable, if you're uncomfortable with this you can always switch back to the stable channel. We'll add a help center article to make it more clear what happens when you opt-in to early releases.

The only reason for this kext to be installed as aggressively as this, is because it is vital for Dropbox Inc. to use to capture their users. There is no valid reason for this kext: none, zilch.

Frankly, I find this use of kext's offensive. I'm putting Dropbox in my "do not recommend" list.

These shenanigans finally made me delete my Dropbox account, and set up an OwnCloud instance on Digital Ocean.

I've found the OC client to be very nice on the platforms I use (Linux, Windows, iOS). The Dropbox client on Linux was terrible to the point of being unusable.

> These shenanigans finally made me delete my Dropbox account, and set up an OwnCloud instance on Digital Ocean. I've found the OC client to be very nice on the platforms I use (Linux, Windows, iOS

So an implementation-detail for a feature on a platform you don't use caused you to shift to another product, which doesn't even support the feature you are complaining about? Am I reading you correct?

By all means. If you're happy running a FOSS solution on servers you control, more power to you. I'm just confused about your reasoning.

> So an implementation-detail for a feature on a platform you don't use caused you to shift to another product, which doesn't even support the feature you are complaining about? Am I reading you correct?

I don't think he's talking about only this one issue. Dropbox had an issue with something of this sort recently [0]. They secretly gave their Mac application root privileges. They may have crossed the line for him here. I should say that I'm not speaking for him but I can see how something like this could have been the last straw for someone.

I personally think that the way a company treats it customers is a good display of how good it's culture is. It's not a good sign that they did this.

[0] https://news.ycombinator.com/item?id=12619722

Is this a different issue, or just a different part of the same thing ?

I hazard the latter since they have had a series of problems except the one here.

There was also a time that when you uploaded to Dropbox a file that was already on its servers, instead of storing the new file they stored a reference to the old one (that they already had) as per https://news.ycombinator.com/item?id=2478567

If it's a feature I don't want and can't disable, yeah, I'm going to investigate alternatives that don't have it.

More likely referring to the fact that Dropbox has had many an issue lately of doing things that may not have been intended to look nefarious, but look that way nonetheless. This is just the last straw for some users, whether or not the feature was used by them.

I actually do have a Mac machine, but I use it so little I didn't include it.

Anyway, there have been other Dropbox issues of a similar nature reported here on HN, and while I haven't been harmed by them personally, it speak to a style of development I don't agree with.

But what finally pushed me over the edge, was this racist initiative at Dropbox. I want no part of that.

https://blogs.dropbox.com/dropbox/2016/12/diversity-at-dropb...

Automatically self-installing a component when I have removed it is malware, not "implementation detail".

Yeah, can vouch for Owncloud (although I've moved to the NextCloud fork), its a convenient replacement for Dropbox, just thrown an OrangePi Zero ($7), a JMS567 USB 3.0 to Sata adapter ($3) and any old HDD and you've got yourself a libre Dropbox that uses just a few watts and works consistently on all platforms.

Note that the Wifi drivers aren't libre, but besides that everything else on the OrangePi Zero, from audio to ethernet is in kernel 4.10 under GPLv2.

Do you think something like this is feasible for a home media server? I suspect things like video streaming from this would be slow, am I wrong?

Am not OP, and not speaking from direct experience,

but a coworker was using a Pi-2 as a home media server without issue in some situations - basically he did the math on the bitrates per second and determined that the disk/wifi I/O (on the shared USB bus) was fast enough for his use case (IIRC streaming to main TV, possibly 1-2 more devices)

I do know he was looking at upgrading to another mini-arm board with a dedicated PCI Nic or separate SATA due to the bus contention on the USB limiting data/network I/O because he wanted to serve more clients (family of 5 and associated devices)

so I guess the short answer is 'maybe, depending on use case'..

The OrangePis have much better IO (with the exception of the OrangePi+ 2, which is a bad buy), with each USB port being direct wired & capable of 40MB/s, and an onboard 100mbps PHY. Comparatively, the Raspi shoves all that over 1 USB port, ethernet included, so 4 to 5MB/s is about the best your gonna get with it.

You don't need to stream the data from the OPi, that is the wrong way for watching video because it would transcode the data on a light processor then send it unpacked on the network, which would consume a lot more bandwidth.

Once you have the files on the disk attached to the board just set up a NFS and/or SMB server on it and let the clients players mount it as a network drive and suck the data. This way you can for example have all home TV sets playing each one a different movie at the same time.

>Do you think something like this is feasible for a home media server?

Absolutely. It's easy to install, works great, the only problem you need to solve is DNS. Either you need to use a service to point the domain to your dynamic IP or rent a static IP for your home address, which could pot expose your home network to attacks.

>things like video streaming from this would be slow

Depends on your uplink. Probably. If your home internet is fast you can stream for yourself or even a couple of people, but you can't really run a video streaming operation. It's easy math, just watch your bandwidth while your stream a video. On private customer plans, uplinks are usually artificially made a fraction of the bandwidth of downlinks by ISPs because they want businesses to be unable to run on them and buy the more expensive options instead

Well, you're probably not going to push 4K reliably. I have a feeling that tech will actually catch on, as opposed to 3D.

If you get an OrangePi 2e ($35) or an OrangePi PC2 ($20) both have gigabit that performs well, you could easily push 4k reliably from either. They also have libre VPU support so you can playback 4k content if you plug in an HDMI cable.

I like OwnCloud as well and use it for all my dev stuff, keeping things synced between desktop and laptop (and my hosted server).

The one issue I've had was sometimes if it tried to sync while I was working in my IDE (gamemaker studio), somewhere between saving and compiling it would lose sync and want to redo the whole folder. I tended to pause sync until I finished working. Could have been a bug that was since fixed, but I still do it just in case.

I second this. I would much rather not have Dropbox install any kexts at all, and the only thing preventing me from replacing it (so far) is widespread support on iOS apps and Linux (which I rely on for a few things).

Otherwise I'd have switched by now - as many folk point out, this is the third or fourth time this kind of approach has come to light, and it reflects badly on the company and the product.

For Google Drive on Linux I've been using Insync happily for a long time now: https://www.insynchq.com/

I installed that software on Linux. It then randomly spread my music library around my Gooogle Drive. Support's answer "Your local sync db must have got corrupted. But here is a list of all the files that got moved" wtf?!

I've had an extremely good experience with syncthing. There's no kext and volunteers run relay servers to get around NAT (everything is encrypted so you don't need to worry.)

I wish they'd combine the relay server functionality into syncthing itself so that it could automatically use peers as relay servers.

I'd prefer not to rely on the generosity of others or running the relay server and having to manually configure syncthing clients to use it.

Thanks for the Little Flocker tip! Didn't know this app yet!

+1 shut up and take my money :)

My personal experience here only: Google Drive + INSYNC is a pretty damn good combination which replaced Dropbox entirely for me. (edited... written insync wrong).

Is there a culture at Dropbox that just encourages these kind of dark patterns? I originally started using the service out of respect for Guido's work, but it seems obvious at this point that Dropbox has little respect for users' security or privacy and will push through this kind of nonsense, hoping that their less-knowledgeable user base won't catch onto the implications.

Well, as far as I'm aware, there have been no actual implications. I think it's a perfectly reasonable summary to say that Dropbox does a bunch of weird shit to enable features customers want that can't realistically be delivered any other way, and so far there have been no drawbacks to the approach in practice.

I get the argument from the other side as well, but if you're Dropbox, you just want to make the best file-syncing application you can make, and any other choice they could have made in these situations would be worse in lots of ways. We can quibble over which set of compromises is the right set, but I doubt you'll find a single set of uniformly preferred options. To be sure, there are probably some low cost wins they could make -- making the signing status of everything more obvious, etc., but I'm not sure what your desired outcome here really is.

I guess I mostly just find it annoying that people seem to think anything other than presenting my 67 year old mother with a dialog of full disclosure about kernel extensions is somehow the nefarious work of a shady company rather than a conscious design arrived at through a reasonable comparison of the options.

Because there is no middle ground here, like, say, a sensibly labeled checkbox in the preferences, which defaults to on?

As for implications: We're here talking about it. That is an implication. This is not the first time either.

As for uniformly preferred: not futzing around with system level stuff without a preference or notification tends to be pretty much universal.

What is a "sensibly labeled checkbox"?

    [x] Enable Smart Sync
    [x] Install Dropbox drivers required for Smart Sync

What happens if I uncheck the second checkbox but not the first? Does Smart Sync just sit there and look sad?

Maybe just a note under the Smart Sync thing saying "Smart Sync drivers are installed. Disable Smart Sync to remove"? Will that actually make anyone happier?

Also—Dropbox is a filesystem. (Logically, the entire product is a filesystem; pedantically, traditional Dropbox might not be but Smart Sync definitely fits the definition of a network filesystem.) Traditionally on UNIX, if you're installing a third-party filesystem like AFS or Lustre or ZFS or whatever else, you're installing drivers. The fact that installing a filesystem installs both userspace software and drivers doesn't feel weird to me at all.

> What happens if I uncheck the second checkbox but not the first? Does Smart Sync just sit there and look sad?

Is this a serious question? I've seen dozens if not hundreds of UI's that gray out a checkbox (either with or without the box checked) once you click a different one. Obviously this might not be an optimal solution for this specific dialog, but you could easily do something like:

[x] Enable Smart Sync (NOTE: This requires installing a driver onto your computer)

This is actually what the opt-in looks like for Smart Sync (except at an admin level since team admins opt their users into it). There's also an individual opt-out if your team admin has opted you in and you don't want things enabled.

Traditional UNIX filesystems didn't backdoor the accessibility panel for persistence.

Well, where the analogy falls down a bit is that traditional UNIX filesystems have traditionally been installed and maintained by UNIX systems administrators.

My point wasn't to blindly defend everything Dropbox has done. I'm sure they've made mistakes, both in design and implementation. My point was that things like their hack of the accessibility panel are, in my opinion, overblown by the average technical reader.

I think bothering the user with an accessibility panel is tedious "Charlie work" that I'd prefer be avoided. I understand why it works the way it does, and I understand the theoretical risk the OS is trying to mitigate. But I'm already trusting Dropbox with my data. It's silly for the OS to treat them like some unknown piece of malware, it's just that the OS isn't a generally intelligent agent able to make accurate determinations of that sort.

I get all that. It doesn't change the fact that I as the user of my computer just want Dropbox to do whatever it needs to do to work. I'm capable of doing the accessibility dance that most applications require, but not everyone is, and I think it's a reasonable position for Dropbox to take that if users are signing up and downloading our app, then implicitly they trust us to check the accessibility box. Is that an objectively acceptable argument? No, but all I'm arguing is that it's reasonable. It doesn't imply maliciousness that that's the argument that won the day inside Dropbox.

I think at least some people object more to the less than forthright disclosure of what they're doing than the technical tricks. If they had a blog post "behind the scenes at dropbox kext headquarters" that'd be fine. It's the coverup, not the crime.

You mean like https://blogs.dropbox.com/tech/2016/05/going-deeper-with-pro...

Yeah, something like that would be pretty good. :)

I'm not sure that's true, actually. The ways that AFS hooks into the kernel, especially on kernels that don't have actual loadable module support (older commercial UNIXes) or on kernels that try to limit syscall hooking (e.g., Linux), are distressingly close to the ways that a rootkit hooks into the kernel.

>I originally started using the service out of respect for Guido's work

Guido has nothing to do with Dropbox, apart from being an employee at the company. He is neither the one who created the platform, nor is he responsible for how it operates.

It would be like using Gmail because you respect Brian Kernighan.

And what would be the issue with factoring that into your choice?

At the time I was choosing between these kinds of services, Dropbox and its competitors were all pretty comparable. I have great respect for the Python community and it's values, so when I learned that Guido was working there and that they were giving him time to work on Python, I thought it indicated a positive company culture. Why not go with Dropbox, all else being equal. Then they pulled this kind of BS repeatedly and appointed Rice to the board. I guess lesson learned about thinking good people will work at places that align with their values.

>And what would be the issue with factoring that into your choice?

Obviously that it would be an irrelevant criterion?

Besides you answer that yourself: "I guess lesson learned about thinking good people will work at places that align with their values."

I don't think that hoping for quality work and a promotion of good values from someone with a track record on those issues is an irrelevant criterion. I may end up being repeatedly disappointed, but I'd rather weigh it than not.