Live data from Hacker News

Dropbox telemetry can't be disabled

dropboxforum.com

201–210 of 249 posts

Re: Dropbox telemetry can't be disabled

#201

Earlier quoted context omitted.

Interesting. I wonder why our experiences are so radically different?

Well... if you run owncloud (or any other alternative in fashion) you need off site backups and a plan for disaster recovery to match what an external service can offer. Backup machine or funds to get one at short notice. If you use a 3rd party service they'll handle that too. It's not the initial setup that's the problem.

> you need off site backups

Yes, but that's not technically difficult or time-consuming.

> a plan for disaster recovery to match what an external service can offer.

I'm not sure what you really mean by this. Isn't that what the backups are for?

Re: Dropbox telemetry can't be disabled

#202
post #39

Earlier quoted context omitted.

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

Eh. Just set up syncthing. Came back to it about a year ago, and it's worked flawlessly across 5+ devices with ~8 synced folders ever since.

SyncThing, while indeed amazing and my goto for personal file sharing, might not go well with your corporate policies. An alternate program, like InSync, allows you to disable telemetry on DropBox, OneDrive and Google Drive at the same time, and is easier to justify.

Re: Dropbox telemetry can't be disabled

#203
post #85

Fuck all telemetry (sharing any information which is not just "you have no control over" but anything which is not logically necessary for the app to do its primary job). Just don't use any apps you can block from doing this. IMHO this (sending redundant and untransparent information from a user's machine) should be outlawed.

Error reporting is far from being redundant though, it's literally 1 step away from being 'logically necessary'

I would gladly report all the bugs myself manually, with all the details, specifics and reproduction steps. The only problem is 85% of bugs I ever reported either got "won't fix" status (mostly in free software) or just been silently forgotten (mostly at work) or got a "pay first, then ask for fixes" response (when it was about shareware). So I lost enthusiasm. Free software bug reporting also often has a problem of requiring registration in a separate BugZilla for every project but this problem has mostly been resolved by the majority moving to GitHub.

By the way, although I don't want to participate in involuntary and non-transparent automatic error reporting, I find your response logically beautiful. "One step away" - a perfect and reasonable description for this.

Re: Dropbox telemetry can't be disabled

#204

Fuck all telemetry (sharing any information which is not just "you have no control over" but anything which is not logically necessary for the app to do its primary job). Just don't use any apps you can block from doing this. IMHO this (sending redundant and untransparent information from a user's machine) should be outlawed.

Typo fix: I meant "apps you can'T block from doing this" of course.

Addition:

I also hate apps and gadgets using "clouds" for jobs which can perfectly be done locally.

E.g. I want a vitals tracking device to record my heart and sleep data but I am not buying any because they send that data to their servers, I want them to only send it to my PC where I would do the data science myself (and/or to my smartphone to a purely local app). I would pay a lot (up to e.g. what a beefiest new MacBook costs) for such a device if it were purely local and well-made (wouldn't break soon).

I also want a vacuum robot which would build and use my apartment map without sending it to any cloud but there are no such models no matter how much I am willing to pay (I know a solution[1] for vacuum robots - some can be hacked to run the server part on themselves but I don't really have time for this). And there have recently been a leak of pictures made by vacuum robots which proves my paranoia is legitimate.

Some genius has even invented a WC which analyzes your pee and stores your hormonal changes log in their cloud which is a great gift to conservative maniacs (I don't mean all conservatives are maniacs, some are awesome, there are many flavours of conservatism) which have just banned abortions and can now subpoena the company to find out you if you have secretly undergone an abortion in another state.

Surely insurance companies and banks will also find a way to get your data and make your insurance and loans prohibitively expensive as soon as they find some clues you might have health risks.

I am almost sure the problem of privacy negligence, every serious actor spying on people hoarding data, is going to become more and more serious up to a catastrophic point and hope it will get more and more attention soon.

I used to be called a paranoid loon by fellow students for covering my laptop camera a decade ago, now almost everybody does this and my new laptops (HP EliteBook and ProBook) even came with built-in curtains on the cams.

[1] https://github.com/Hypfer/Valetudo

Re: Dropbox telemetry can't be disabled

#205
post #32

Earlier quoted context omitted.

For reference, it is referred to the first comment under announcement of Dropbox https://news.ycombinator.com/item?id=8863

This is the HN equivalent of “No wireless. Less space than the nomad. Lame” https://m.slashdot.org/story/21026

second comment:

> Plus, you can use it as a portable disk. No "content protection". Yay!

good times

Re: Dropbox telemetry can't be disabled

#206

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

BrandonM was right all along. Nowadays you'd probably use "rclone mount" or sshfs though.

(For anyone wondering the parent is channeling https://news.ycombinator.com/item?id=8863)

Re: Dropbox telemetry can't be disabled

#207
post #206

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

BrandonM was right all along. Nowadays you'd probably use "rclone mount" or sshfs though. (For anyone wondering the parent is channeling https://news.ycombinator.com/item?id=8863 )

[flagged]

Re: Dropbox telemetry can't be disabled

#208

Synching telemetry can be disabled. In fact, it's disabled by default.

Can it? The article says disabling telemetry had no effect. Maybe this has changed.

Your parent is talking about Syncthing, an open-source P2P alternative, not Dropbox.

Re: Dropbox telemetry can't be disabled

#209
post #71
post #41

Earlier quoted context omitted.

Oh I also have shared folders with other people. We used to use it for sharing audio files between podcast presenters, which worked well enough. I have half a dozen folders in my $HOME, shared with different groups of people. I also have Syncthing installed on my home server which gets backed up. So I have a copy of all my files backed up there, in the event a laptop goes missing or dies. The only use case I haven't…

A word of caution for anyone planning to use syncthing for backups. Syncthing is designed as a sync solution but not explicitly for backups. You need some extra setup on top of the defaults for building a reliable backup solution. If not setup correctly, any "mistakes" from one of the devices will automatically be synced to other devices and cannot be retrieved back. In the case of a lost/stolen device, make sure you…

Yeah, no, easier to block the telemetry domain than deal with such a huge risk of losing everything

Re: Dropbox telemetry can't be disabled

#210

I get that for some classes of "local-only" apps like compilers (famous from a recent discussion on the same topic), network communication can be surprising and therefore feel unnecessary. But for an app whose sole purpose is sending and receiving lots of sensitive private data to Dropbox servers, who has the energy to be outraged that there is also some other anonymous data sent such as program crash info? I mean Dr…

I'm wondering where the line is between acceptable and unacceptable logs. Obviously no one appreciates analytics used by marketing teams, but virtually every internet service has logs used by engineers (which seem to be what this post is about). A few factors that seem relevant:

- Is the service running locally?

- Do we trust/expect that the data is not used for marketing (i.e. would the user have complained if the domain was "error-reporting.dropbox.com")?

- Is the data anonymous (think twice, everyone who has IPs or user IDs in request logs)

- Did we agree to relevant ToS or privacy policies?

If we think carefully about this, I'd bet that most people here have used or even implemented some form of logging that has privacy problems.

Post reply on HN