Live data from Hacker News

Dropbox telemetry can't be disabled

dropboxforum.com

181–190 of 249 posts

Re: Dropbox telemetry can't be disabled

#181
post #49
post #44

Earlier quoted context omitted.

There is a reason it's popular: it's extremely useful for software development to a) have actual hard data on how your software is being used, and b) have a large selection of crash data for debugging rare issues. If it's not the software engineers who want it, it's the technical management who see the immense value in having it.

You're forgetting the monetary incentives. It allows companies to collect personal data of every user and sell it to "our partners" to build larger marketing profiles.

This depends on what kind of data they're collecting. The most common kinds of telemetry data is not actually particularly useful for that, and usage of it for selling advertising, especially to third parties, would be contradictory to most privacy policies (now how much you trust that they are actually following their own policy is another matter: and dropbox does call out that they may try to use this data to upsell you on their own products).

Nonetheless, the potential is there and GDPR does consider it personal data from the point of view of consent, so dropbox is almost certainly violating the rules here even if they do not sell the data for advertising (as unlike the actual data they store, it is not necessary for providing the service, merely useful to the company for improving their service). Such telemetry almost certainly requires an opt-out, and most likely should be an opt-in as far as GDPR is concerned.

Re: Dropbox telemetry can't be disabled

#182
post #39

Wouldn't get this with a FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem.

Or use an open source client without telemetry such as https://maestral.app ㋡

Why there's no similar alternative for ProtonDrive? Missing public API? Too secure?

Re: Dropbox telemetry can't be disabled

#183
post #28

Earlier quoted context omitted.

> I guess becausse someone made lots of money from it or it became popular or something. No, it’s because it was useful and simple in a way that non-techies could and would set up and use. That’s why Dropbox got popular.

Even as a techie, why would you put in the work to set up your own thing? Though, I moved away from Dropbox long ago when they introduced device limits. One phone, one laptop and one triple booting desktop -> over the device limit already.

To be fair, nowadays setting up syncthing is trivial for a techie and keeping it running isn't harder than keeping dropbox running on your computer.

At the time dropbox launched, there wasn't anything this convenient.

Re: Dropbox telemetry can't be disabled

#185
post #161

Earlier quoted context omitted.

Do you trust that the USB stick is just storage and not something additional? Do you trust that the USB "power port" is just power and not a host?

Regarding rogue client devices: Suppose it's not just storage and instead is something additional, like a device for which the host will decide (without autorun.ini in this case) to install drivers, or interact in some other capacity along those lines. Can this automatically cause arbitrary code execution? I would not consider code supplied through official OS channels ("let windows search for a driver online" type o…

The most obvious rogue client device exploit is to pretend to be a mouse and/or keyboard, which on most devices will allow you to execute arbitrary code trivially, though not completely stealthily. "USB rubber ducky" is one such device available to consumers now. As for exploiting drivers: while the software might be 'trusted', I highly doubt that it is all actually secure. Emulating a USB device with a low-quality driver and then exploiting that driver by violating its assumptions about the hardware its expected to be talking to is a rich field of potential exploits (even on linux, there's vast swaths of low-quality driver code which has nowhere near the hardening of the network stack).

Re: Dropbox telemetry can't be disabled

#187

Earlier quoted context omitted.

Putting in the work to setup your own thing is great. You learn a lot, if your doing it at an advanced level you start to understand some of the designs/tradeoffs that the commercial products made. Keeping that running and reliable and operating it for years or decades sounds like an absolute nightmare and I'd suggest avoiding that at all costs.

> Keeping that running and reliable and operating it for years or decades sounds like an absolute nightmare But it's not. I run many such services for myself, and keeping them running and reliable hasn't been a large burden.

I run a lot of my own things on my network. It is a nightmare, but I still do it. If I had more money, I would absolutely outsource this process.

Re: Dropbox telemetry can't be disabled

#188

Many times on HN, commenters have mocked those who questioned why someone would use Dropbox instead of a method controlled by the user. I guess becausse someone made lots of money from it or it became popular or something. I always found this perplexing because I look at solutions from the perspective of the user, namely, me, not from the perspective of a third party "tech" startup founder. It's insensitive to the pe…

> I confess I have never used it. I still rely on USB sticks Phew boy. You really should try dropbox or a competing service.* Picture this: 1. Double click a file 2. Type some words 3. Save the file That's it. There is no step 4. Your file is now synced to all your other computers and to any colleagues who also need that file. Seriously you shouldn't be using USB sticks these days. Also - I'm guessing you haven't sta…

> I'm guessing you haven't started the transition to USB-C yet? USB sticks are going to get really painful when you do

Those USB sticks that are A on one end, C on the other are excellent. They are also great fidget toys.

https://www.rubbermonkey.co.nz/SanDisk-128GB-Ultra-Dual-Driv...

Re: Dropbox telemetry can't be disabled

#189
post #161

Earlier quoted context omitted.

Do you trust that the USB stick is just storage and not something additional? Do you trust that the USB "power port" is just power and not a host?

Regarding rogue client devices: Suppose it's not just storage and instead is something additional, like a device for which the host will decide (without autorun.ini in this case) to install drivers, or interact in some other capacity along those lines. Can this automatically cause arbitrary code execution? I would not consider code supplied through official OS channels ("let windows search for a driver online" type o…

> Can this automatically cause arbitrary code execution?

USB has capability to launch any arbitrary code that the user itself could without inputting any secret.

On anything that isn't the best protected Linux GUI (better protected than the configurations that everybody use), this is enough to install a keylogger on your environment and sniff any secret that it's lacking (but root/administrator rights are overrated anyway).

There has been some work on restricting USB so that it can't initiate anything. But that brings extreme usability problems, so it's very rare for people to do it in practice.

Post reply on HN