3 ms·

I know a lot of people don’t like things like this, but also remember not all data collection is malicious. If you look at what they actually collect it’s not p

I know a lot of people don’t like things like this, but also remember not all data collection is malicious. If you look at what they actually collect it’s not pulling a bunch of personal info. They collect usage, perf and errors. As a product manager (not for vsc or MS) I use this type of telemetry all the time to make priorization decisions. It’s a balance, but my hunch is the team at MS uses this info exclusively to make the product better. Of course, you should always be able to disable this sort of collection.

TheAceOfHearts 8y ago
No, you should ALWAYS explicitly ask for user consent. You should explain exactly what kind of data is being collected and how it's used and ask them if they are fine with that. Anything else is unethical. I'll happily enable certain kinds of data collection when a tool is transparent and it makes its data collection opt-in.
- arghwhat 8y ago
  I'm a privacy advocate, but I'm 100% okay with on-by-default error collection, as long as the logging is scrubbed of personal data. Usage analysis is different, and should be opt-in.
  - mrob 8y ago
    Even if we accept that scrubbing of personal data is possible, which is far from certain, that theoretically non-malicious traffic still provides camouflage for malicious traffic. If we insist on opt-in, then we can apply a very simple and fail-safe heuristic: any traffic the user didn't explicitly request is malicious. There's no need for slow and error-prone analysis.
    - arghwhat 8y ago
      And how in the world do you intend to distinguish traffic? How do you intend to tell the difference between Atom's and VSCode's Git(hub) integration, app updater, package manager, telemetrics or an exploitation? The difference between a Signal, WhatsApp or Telegrams' messages and their telemetrics? Your proposed heuristic only works for applications that would not otherwise have any network traffic, and even then, only if you do on-machine per-process network monitoring. Once it has any valid traffic what-so-ever (which is the case for basically any modern GUI application), then you quickly descend into needing to disassemble binaries locate the cause. Opt-in vs. opt-out is about privacy and rights, not about security. Malicious companies whose traffic are a security breach and things down those lines are problems that belong in an entirely different discussion, whose root-cause is much deeper than opt-in vs. opt-out. Also, regarding scrubbing: A stack-trace and error message is far from private identifying information. No harm done in sharing it.
      - 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).
jjeaff 8y ago
I agree. Most telemetry gathering is not malicious. But I always disable it simply because I use a lot of software. Telemetry from all of it would just be a big outgoing stream of data all the time.
makecheck 8y ago
Internet access is still pretty variable throughout the world (or even within countries that can have good speeds, like the US). Anything randomly uploading megabytes is going to cost somebody an unreasonable amount of money so there should be consent.

TheAceOfHearts 8y ago

No, you should ALWAYS explicitly ask for user consent. You should explain exactly what kind of data is being collected and how it's used and ask them if they are fine with that. Anything else is unethical. I'll happily enable certain kinds of data collection when a tool is transparent and it makes its data collection opt-in.

arghwhat 8y ago
I'm a privacy advocate, but I'm 100% okay with on-by-default error collection, as long as the logging is scrubbed of personal data. Usage analysis is different, and should be opt-in.
- mrob 8y ago
  Even if we accept that scrubbing of personal data is possible, which is far from certain, that theoretically non-malicious traffic still provides camouflage for malicious traffic. If we insist on opt-in, then we can apply a very simple and fail-safe heuristic: any traffic the user didn't explicitly request is malicious. There's no need for slow and error-prone analysis.
  - arghwhat 8y ago
    And how in the world do you intend to distinguish traffic? How do you intend to tell the difference between Atom's and VSCode's Git(hub) integration, app updater, package manager, telemetrics or an exploitation? The difference between a Signal, WhatsApp or Telegrams' messages and their telemetrics? Your proposed heuristic only works for applications that would not otherwise have any network traffic, and even then, only if you do on-machine per-process network monitoring. Once it has any valid traffic what-so-ever (which is the case for basically any modern GUI application), then you quickly descend into needing to disassemble binaries locate the cause. Opt-in vs. opt-out is about privacy and rights, not about security. Malicious companies whose traffic are a security breach and things down those lines are problems that belong in an entirely different discussion, whose root-cause is much deeper than opt-in vs. opt-out. Also, regarding scrubbing: A stack-trace and error message is far from private identifying information. No harm done in sharing it.
    - 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).

jjeaff 8y ago

I agree. Most telemetry gathering is not malicious. But I always disable it simply because I use a lot of software. Telemetry from all of it would just be a big outgoing stream of data all the time.

makecheck 8y ago

Internet access is still pretty variable throughout the world (or even within countries that can have good speeds, like the US). Anything randomly uploading megabytes is going to cost somebody an unreasonable amount of money so there should be consent.