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?
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.
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.
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.
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.
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.
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
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