3 ms·

>Git(hub) integration If I select a git command from a GUI, that's an explicit request by the user. >app updater, package manager If something legitimately r

by mrob 8y ago

>Git(hub) integration If I select a git command from a GUI, that's an explicit request by the user. >app updater, package manager If something legitimately requires background network activity, and security updates might qualify, it should go in Crontab. The system should have exactly one package manager, and apps should not re-implement their own. >telemetrics If I turn it on, I'll remember I turned it on.

arghwhat 8y ago
None of this makes any sense unless you're manually authorizing all connect()/write() calls, manually monitor network traffic and correlate it in real-time with user actions, or have some form of surveillance software to automatically do this for you. All of these seem extremely improbable. Otherwise, on the network, git fetch and telemetrics to github will be indistinguishable (except if you start doing opaque data pattern analysis). There's also no automatic correlation on the network. On the machine itself, the closes you could get is something like Little Snitch, which still won't be able to help at all, as permitting Atom to speak to Github on port 443 will permit everything while disallowing will block everything, and it's also designed to be a manually populated whitelist, rather than a constant authorization system. > If something legitimately requires background network activity, and security updates might qualify, it should go in Crontab. The system should have exactly one package manager, and apps should not re-implement their own. First of all, eww. Nothing is worse than updates running on a crontab, causing shit to break because it updated automatically. Also, welcome to 2018. Everything outside Linux bundle their own updater, and on Linux, flatpak and other newfangled things bypass most package managers (even with dnf's flatpak integration, it's still not going through any yum repos).

by mrob 8y ago

arghwhat 8y ago

None of this makes any sense unless you're manually authorizing all connect()/write() calls, manually monitor network traffic and correlate it in real-time with user actions, or have some form of surveillance software to automatically do this for you. All of these seem extremely improbable. Otherwise, on the network, git fetch and telemetrics to github will be indistinguishable (except if you start doing opaque data pattern analysis). There's also no automatic correlation on the network. On the machine itself, the closes you could get is something like Little Snitch, which still won't be able to help at all, as permitting Atom to speak to Github on port 443 will permit everything while disallowing will block everything, and it's also designed to be a manually populated whitelist, rather than a constant authorization system. > If something legitimately requires background network activity, and security updates might qualify, it should go in Crontab. The system should have exactly one package manager, and apps should not re-implement their own. First of all, eww. Nothing is worse than updates running on a crontab, causing shit to break because it updated automatically. Also, welcome to 2018. Everything outside Linux bundle their own updater, and on Linux, flatpak and other newfangled things bypass most package managers (even with dnf's flatpak integration, it's still not going through any yum repos).