Hacker News Reader

Comment by cdransf | Hacker News Reader

This doesn't seem any worse than Chrome continually updating itself.

Both of them doing that in mandatory fashion is unacceptable.

I might be OK with running this bit of their code on my computer, but it's not an open bar for dropping anything executable onto my machine at will.

> Both of them doing that in mandatory fashion is unacceptable.

Don't install their apps then. There are lots of alternatives out there.

So, what is a good alternative to Dropbox that supports LAN sync, block-level uploads [1], revisions, and that most of my colleagues, friends and friends have or can set up?

If you actually look at the competition, most of them do not have LAN sync or block sync (OneDrive, Google Drive), they do not have proper support for revisions (Resilio Sync), or are hard to set up for most people (Syncthing).

[1] So that if I change a small piece of a large file, it does not upload the complete file again.

There is probably no product with the exact feature set of Dropbox. But if you want to take the principled stand, you'll have to live with that. You can't be all "refuse closed-source autoupdating software, it is evil! Richard Stallman was right all along!" and then complain about you not getting the features that those products offer. That's the price you pay for your principles.

Seafile works pretty well, they install a client a lot like the Dropbox client and sync away. And it is even mostly open source

seafile.com

https://github.com/haiwen/seafile

Why only "mostly"?

I believe that some of the `pro` or their custom hosted offering's features aren't necessary in the open source code base. But the majority of the functionality is

If it's unacceptable, why would you use the Google Chrome browser?

It's open-source (Chromium project) - just compile it yourself?

Once you've run somebody else's binary, you're already conferring significant trust on them. And I might be biased, but the Chrome team has shown themselves to be very vigilant with security, and generally on-the-ball on all of these things. (Memory issues aside...although I'm not going to get into that...lol).

Many newer projects do this - e.g. Atom from Github auto-updates.

VS Code from Microsoft does this - I think it's awesome! =)

>Once you've run somebody else's binary, you're already conferring significant trust on them.

This is the "you agreed to a date, that means you agreed to go all the way" argument.

Even when a someone extends trust or tentative trust, that doesn't mean they should be expected to give up the right to maintain control of that choice at each successive moment in time.

EFF strongly discourages auto updates that can't be turned off, because they can be used for enabling DRM and curtailing freedom.

Chrome updates can be turned off. Easily.

Exactly. Dropbox should afford users the same respect.

All you can do is gently request that the google updater deamon (keystone agent) please not update. It is still running. And the way to disable it is very obscure, and no user would be able to discover how to disable it on their own.

If you remove it, and then try to run any Google Software, it will first lie to you and say that it needs you to authenticate so it can "function" properly. If you refuse, it will try to install it's code in ~/Library instead. If you intercept that, it will stop asking and work properly.

Google software does not depend on its updater in any way. There is no technical reason to keep asking you to install it. They just don't respect your agency. And if you say no to root installation, they will settle for just a user installation.

A lot of software that asks for authentication on first run is doing it solely to install it's helpers.

Not just is it creepy asf and wrong, but sometimes features will be removed or changed without my consent.

Software that was free when you downloaded it just got "upgraded" to shareware. Or maybe it just irreversibly converted all of its saved data to the new format that isn't backwards compatible.

You would never have agreed to install that update if you actually knew what it was going to do. That makes it dishonest.

> VS Code from Microsoft does this - I think it's awesome! =)

My impression was that at least in Debian based systems (Ubuntu and others), it updates with apt now?

Yes. It uses apt but do you realise that you didn't install it using APT? You used plain dpkg but it now registers itself with APT (I think using something similar to a PPA) so that you can autoupdate.

EDIT: Sorry if this sounded accusative. Wasn't meant that way.

Would be fun trying to autoupdate deb packages though.

VSCode, Atom, Firefox etc. do this but they all provide sane and easy methods to disable the behaviour. It's as simple as unchecking a box (or toggling a string in VSCode). It's not mandatory in those products unlike Chrome and Dropbox (AFAIK) now.

It is pretty easy to prevent chrome auto-updates with a firewall rule and by configuration (https://www.chromium.org/administrators/turning-off-auto-upd...).

But unless you audited the chrome code (with a team of 1000 experts) you have already trusted them, both to write quality code and to prevent malicious code sneaking in. Why not trust them to patch your browser against malware?

Feel free to contribute to ungoogled chromium: https://github.com/Eloston/ungoogled-chromium

In chrome you have the option to disable the auto update feature - an option that is noticeably missing here.

Chrome is a program that has standalone functionality where the program would still do useful work without updating.

The Dropbox sync service, on the other hand, is literally just the client half of Dropbox's own proprietary backend. If Dropbox makes an ABI-incompatible change to their sync protocol on the server side, the non-updated client will just break until you update.

Wanting to disable updates to such a service, would be like wanting to load the old version of a webapp SPA whenever you visit the site. What's the point? It's not going to (have been designed to) work that way.

Auto-updates != No updates

Websites are sandboxed sufficiently that they aren't supposed to be able to do anything crazy to my computer or access any of my data as new versions come out: the same is not true of Dropbox. I don't want some system automatically upgrading the code running on my computer. I want to be able to download new code for my computer and choose to install it. This means that if there's a bug introduced by the new software in my workflow, I have at least some chance in hell of knowing what caused the issue: "oh yeah, I just upgraded Dropbox"; when Dropbox just upgrades itself, one day my computer just starts being unstable, and I'm essentially screwed. This is markedly different (and worse) than Chrome updating itself, as Chrome doesn't inject itself into other random processes or extend the functionality of other parts of my computer: if Chrome upgrades itself into something broken, I will almost certainly be able to notice when I start by closing everything that I'm running, one by one. Software that automatically upgrades itself is also subject to targeted attacks: maybe one day I, and only I, get targeted with a new version of Dropbox, maybe not even being sent to me by Dropbox (due to some MITM-able flaw in their upgrade system) that is actually spyware. When I manually download new software on my schedule, particularly if I'm downloading it manually with a web browser, especially so if I download it once "anonymously" and reuse the download on all of my computers, I can feel a lot safer that I'm not being targetted. This is just so so so fundamentally different than a new version of a web site :/.

The source code is available and GPLed. Patch it if you want.

https://www.dropbox.com/help/247

I think your trust in browser sandboxing of websites has been, and is continually being, disproved. Browser vulnerabilities are the most consistent way of compromising a remote system.

Webapps don't install kernel extensions.

> If Dropbox makes an ABI-incompatible change to their sync protocol on the server side, the non-updated client will just break until you update.

So... don't break ABI compatibility?

Well, that's pretty bad already, and one of the reasons I'm not interested in using Chrome, but no, it doesn't seem any worse.

Or Office, Creative Suite or dozens of other major applications.

Microsoft Office does not autoupdate. It notifies you of an update, but you have to confirm the transfer and installation. At least that's how it works on my Mac.

On Windows, it updates through Windows Update (which you can moderately control) or through their own App-V/Click-To-Run thing, that updates transparently

That's because they don't have a robust self-update feature for the Microsoft Updater app. They added an automatic update mode and it appears to be on by default now, which is probably good given the number of exploits Office has had over the years.

Adobe software is a notorious offender for intrusive background updater processes. It's not exactly something to aspire to.

Reply on news.ycombinator.com