I would agree with a policy that does not permit data collection as described without an explicit opt-in on the default channel would be the most preferable solution.
The opt-in should include what information is being collected, and for what purpose, to allow an informed decision.
I took a short look at the code and it seems to disable some features if the settings is activated and Kite is installed. It seems not to interact with Kite except to check whether it is installed and running or not
It may be worth to monitor it for the future, but currently I don’t see a privacy violation problem.
I think the kind of data Package Control collects is kind of to be expected for such a feature. As long as communication about it is clear it’s fine, so to me part 2 of the proposal is fine.
What’s happening with SidebarEnhancements (and Minimap for Atom), is that the telemetry has no relation at all with the functionality of the package. It’s just a way to sneak in on as many developers as possible.
I feel there should be a clear value-add for the user of the package, and it should be there in the very first version that’s submitted to the default channel. If the telemetry is essential, it doesn’t make sense to add it on later. If it’s not essential and the package maintainer is simply curious, that’s too weak a use case to allow the telemetry. There should be zero tolerance for packages that add, after submission, anything that takes any kind of information from the end user and uploads it elsewhere. Sublime has a large user base so of course it’s enticing, but Package Control should not be treated as a commercial opportunity. It originated from the community and it exists so that the community can share, not as an entry point for Kite et al. to mine data.
Therefore, I would add the following to point 1 of the proposal:
If a new package is submitted that uses telemetry, it should be opt-in and clearly, very explicitly explained to end users. The pull request that adds the package to the default channel should clearly mention the telemetry, how it relates to the core functionality of the package, and the efforts undertaken to explain this to end users. If there is no strong relation between the telemetry and the features of the package, it will not be allowed. Any package that is found to add telemetry after being added to the default channel will be pulled immediately and only restored after the telemetry code is removed.
This still allows anyone to create a new version of an existing package with telemetry, but challenges them to create a new entry in Package Control and convince the user base to migrate based on the value-add of the telemetry. If SidebarEnhancements-with-Kite is much better than the old one there should be no problem with this approach.
I would consider adding similar rules about advertising: it’s only a matter of time Kite hijacks something else (the linter seems like a tasty target, I bet they’ve already been approached) to add links to their services like it did with Minimap for Atom. Any advertising that’s not a donation button or a link to a repository should follow the same rules: add value, improve the core functionality, add it on day one, don’t be sneaky.
Edit: When in doubt about the value-add, default to “no”. Something like Package Control cannot flourish if people don’t feel safe about it, but I doubt we’d miss out much if a package or two is rejected. Plus, you can always create a new channel.
I would prefer a hard line against any data collection personally. While it could be useful for a developer to know how the tool is used, there are channels that can be used if the user so chooses to utilize them. If the user does not utilize them, I think we can easily say the user did not wish to utilize them.
Hi everyone, member of Kite here. The SideBarEnhancements telemetry was originally added to gather data around what programming languages we should support next. We will ask Tito, the maintainer, to remove it.
We fully support a standardized telemetry consent mechanism for Sublime packages. An option for “Allow plugin authors to collect anonymous usage statistics” similar to Atom’s could be helpful.
Oh, so it’s fine then 
. You needed to mine some data without people knowing, you got what you needed and now that you’re caught you just have to try to make it to the exit swiftly and silently before it blows up any further. Bravo.
You do understand that this discussion isn’t about this particular situation, but about preventing it from ever happening again.
An option for “Allow plugin authors to collect anonymous usage statistics” similar to Atom’s could be helpful.
A blanket opt-in is useless. Users should know exactly which package requests telemetry and should be able to opt-in on a per package basis.
Plugins should make very clear that they are collecting information and be very clear about what they are collecting. I think it should never default to collecting without consent. It should also be per plugin. Just because I give consent to one, I may not want to give consent to all.
Spoiler alert, I don’t want to give consent to any plugin. I frankly don’t trust plugins to this kind of information.
The question is, why did you try to hide who the data was being sent to? And why did you ask to capture activeNonBundledPackageNames? That bit of data seems like a very non-anonymous collection of information. You could be capturing internal package names and consequently exfiltrating the existence of development of competitors products.
I’m having a really hard time understanding why you’ve been so careful about being anonymous about capturing data from the users of (at least) two popular text editors. Do you have you fingers in VS Code, VIM or Emacs packages also?
With the realization of the massive privacy leak that SideBarEnhancements has been perpetrating (sending a list of every installed package to a commercial entity that has been hiding its involvement), I’ve made a judgement to remove it in an attempt at preventing further damage. It can be added back if/when we see a concern for the privacy of users.
Also, why does it take exposure via a thread like this for you to take action? You say you’re staying open, but why didn’t you pull your involvement from SidebarEnhancements when you got caught on the Atom packages last week?
It’s plainly obvious you fail to understand the extent to which you abused and continue to abuse your target audience. So please don’t try to spin this or “engage with the community”, it’s insulting.
@braver the truth is we didn’t remember. This was done the better part of a year ago and we haven’t looked at it in a while.
(We also didn’t remember this telemetry was in the kite-installer package linked to in OP. That will be removed later today.)
@wbond I believe we did not capture internal package names, or that we filtered them out in the code.
I don’t see any filtering happening here: https://github.com/SideBarEnhancements-org/SideBarEnhancements/blob/1858330b71b682ec1f3265bd280dde65465bdf18/Stats.py#L86.
@wbond I have some internal packages installed manually into ST3 but when I run sublime.load_settings('Package Control.sublime-settings').get('installed_packages') I don’t see them listed. (?)
It depends on how you install them. If you git cloned or manually installed, they won’t be in the installed list. If you installed from a private channel file, or by pasting the git repo as a Package Control repository and used Package Control to install/update then they will be in the list.
If you wanted info about popularity of packages. https://packagecontrol.io/browse/popular.json is probably what you should have used.
Actually, the same concern is also applicable to commercial packages and Package Control binary dependencies. A package developer can ship their packages with binary dependencies which somehow collect user information.
One of my packages requires PyWIn32, and it seems that there is no good way to prove that the binary files are from a credible source.
You make a good point. It seems like something along the lines of Little Snitch would be required to tell if binary packages are making web requests.
Honestly, that’s probably the only feasible way to tell anyway, since it won’t be possible to review the source of every package.
I think we’ll probably have to have a rule and consequences for breaking the rule, but rely on the community for identification.
I’d be interested to see something like the manifest.json format in Chrome Applications.
It’d be hard to limit actual behavior, but as different permissions are brought up like “collect file data” or “collect other package data” packages can explicitly tell the user what they are doing.
Ideally you’d also be able to deny new permissions from this manifest and those particular features are turned off.
If a package doesn’t list tracking/network traffic or it ignores the user’s choice when asking for permissions, I see that as a 1 strike offense. The package is removed and any other packages associated with that author and/or corporation are reviewed.
This will be harder since unlike iOS, Chrome, or Android ST and package control don’t have as much of a sandbox around plugins.
But, keeping things to an honor system with clear consequences I think should keep the channel fairly clear.
This would not prevent authors from creating their own PC channel
Just so I understand correctly, this means something like SublimeLinter’s separate channel for all its plugins? If so, this would be a huge cut into how we currently operate our reviewal process, and I’m sure would increase the burden on Package Control maintainers to work around our approval system.
To make a statement about this issue: SublimeLinter cares about your privacy and does not tolerate data collection as shown by Kite or other parties. We do not, and will never, give away or sell your information without prior approval as long as I am involved. That being said, our contributor plugins are not fully under the SublimeLinter Community jurisdiction and we can not promise that same level of service. We will work with users to help remedy the issue if one of our contributors is found collecting information.