Sublime Forum

RFC: Default Package Control Channel and Package Telemetry

#38

@wbond

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.

4 Likes

#39

Just to be clear on the SublimeLinter topic: the sublime linter “channel” is actually a “repository” and included in the default channel. This is mostly a relic from old times and, as far as I’m aware, the different types of specifying packages could be unified (and the terminology is kind of confusing), but it is not of matter for this topic. I believe that I created an issue about this on the PC repo a while ago.

I will comment on the actual topic of this thread later with more time at hand.

2 Likes

#40

Okay, back onto the topic at hand:

I am very much in favor of strictly requiring telemitry and other user data to be sent only when the user opted in. This may occur via a popup on first installation asking whether data should be collected or by having to specify an API key in some settings file, which should be enough user action to determine that the user is indeed inclined to have his data shared to some remote. Of course, Package Control would be excluded from this with the privacy policy mentioned in OP.
This should be the first step.

Any package found violating this rule will be purged from the channel immediately, probably with a one strike system and re-adding it once when the violation is removed. Since there is no reporting system on the site (yet), I suggest contacting me or Will directly when you find a package like this. You can find us on the discord server, for example (just mention us/me in the #general channel with a url to the offending package). Not that we will only review package on their initial submission and when specifically reported to us, as we can’t possibly review each and every update.

In a similar matter, packages doing other malicious things to the system (Python doesn’t run in a sandbox) should be removed immediately as well with all the author’s other packages purged as well. No strikes here.


Now, onto whether data collection should be banned entirely: I believe this is not possible. There are a couple packages that specifically send stuff to some remote as their designated feature, such as time-tracking packages like Wakatime or packages that upload snippets to pastebin sites. These would be affected by this policy, too, even though they are certainly useful for some. A privacy policy statement from these packagesabout what data is collected and how it is used would certainly be appreciated, though I don’t currently see how this can be implemented reasonably. For now, I say the readme is enough and we require this to be present (for new packages).


@braver suggested to also only permit user data being sent if it exists in the package from the beginning and was not added later. I don’t support this stance, because there may very well be scenarios where you add an additional feature that is related to your package but does not need to be in its own package for architectural or topical reasons. I don’t want to force too many restrictions on developers when there don’t need to be. The feature must be opt-in either way, so it doesn’t matter whether the user explicitly installs the “new separate package” with that feature or enables it manually through some action.

From a review standpoint, this doesn’t matter either, except that it would be easier on us as we don’t have to try and track down the state in which the package was submitted. In order to find out whether a package is violating policies, it has to reviewed either way.

7 Likes

#41

Fair enough and plenty good arguments all around.

Besides these recent transgressions related to Kite, the threat level isn’t even that severe. So, as long as there is an agreement and a way to act on violations, we should be good. Requirements can always be tightened if the need arises.

2 Likes

#42

Here is a very practical question from a ST3 and SidebarEnhancements user:

  1. Can I just disable to SidebarEnhancements to avoid further data collection?
  2. SidebarEnhancements is very useful and I reply on the functionality pretty much every day. Is there an easy way to keep using SidebarEnhancements without the data collection in the background? E.g. can I block it or would it be possible to republish SidebarEnhancements without the data collection if the license allows it?
0 Likes

#43

Yes, disabling the package should stop the code from executing at all.

SidebarEnhancements is very useful and I reply on the functionality pretty much every day. Is there an easy way to keep using SidebarEnhancements without the data collection in the background? E.g. can I block it or would it be possible to republish SidebarEnhancements without the data collection if the license allows it?

There are options:

0 Likes

#44

I’ve just re-added SideBarEnhancements to the default channel since Tito removed the stats code and cut a new release. The package should be back in the channel shortly once the crawler picks it up, after that everyone should be updated to the new version the next time their install checks for updates.

2 Likes

#45

Seems like Kite has been doing this all over. Some of the people on the other thread were leaving Atom to come to Sublime, which after reading this thread, appears to have had the same Kite infection.

1 Like

#46

My 2 cents…

Kite in particular is attempting to subvert popular packages and doesn’t have the developer’s interest at heart. They’re entirely motivated by greed. As such, I think their packages should be given a 30 day revert or ban across the entire development ecosystem.


If there’s any policy at all, I think it should never be opt-out. Opt-in is the only policy that should be acceptable. Any time there is an opt-in, a privacy statement must be provided. Any time that privacy statement changes, there must be an update.

Additionally, I would argue that the penalty should be a permanent ban of that package from the package installation.

But I do think we need/should allow for code intelligence and possibly static analysis (e.g. Black Duck), so I don’t think a no-tolerance is acceptable.

0 Likes

#47

That might be a bit rough, there wasn’t a clear policy before and you must also assume that no harm was intended. Kite seems like nasty bunch, but you can’t assume that.

There has already been a little bit of outrage with regards to SidebarEnhancements, but lacking guidelines it never got anywhere. And I think we also didn’t understand the extent of the transgression. It’s also much worse than the Atom cases, at least there was an opt-in there. I definitely really really applaud @wbond’s strong and clear position and his handling of this situation.

1 Like

#48

That might be a bit rough,

I think a stiff penalty (with a 30-day window of opportunity prior as noted), is far better than a soft stance. It’s a clear line not to cross and the penalty is very clear.

you must also assume that no harm was intended.

I have no idea why you would make that assumption. Anyone that puts tracking information on my code base is definitely NOT harmless. More importantly, some of the code I work on is proprietary to my company. Now I’ve got another vector of attack for a security breach. No thank you.

Additionally, and I didn’t think of this until now, I hope that package control can be updated to alert people and ask if they want to have the package removed locally.

3 Likes

#49

I’m just moving on from SidebarEnhancements[quote=“bix, post:46, topic:30157”]
Opt-in is the only policy that should be acceptable.
[/quote]

I feel this should definitely be the case for these open source plugins. You can’t tell how diligent maintainers are with ensuring what gets merged in. And you can easily have 3rd parties push their own self interest without strong maintainers.

I had no idea SidebarEnhancements was collecting data. Users weren’t notified, there were no terms to agree to. Maybe they added a blurb in their documents well after I had already installed it, but I was never notified that it was added after the fact and turned on by default. I’ve moved on as I don’t trust the developer’s judgment. There are other plugins that can bridge the gap.

It’s a menu plugin, there was no need to collect data. I don’t even want to hear how it helped them better prioritize features. Seriously, a menu plugin. Let’s not pretend it was doing anything super complicated. What kind of data mining could it possibly need?

6 Likes

#50

I vote for an opt-in policy.

I do see value in plugins communicating home for various reasons (Kite actually looks fairly cool all things being equal) so a blanket no-tolerance policy is too far.

First violation: immediate and public removal from directory until the policy violation is corrected.
Second violation: removal from directory for a 30 day chill out period
Third violation: permanent removal.

1 Like

#51

as long as PC itself still keeps it’s super-useful opt-out telemetry, then I’m happy - I don’t use many packages, and the ones I do, I watch carefully or commit to myself, or thoroughly trust the authors so I’m not too worried about what decision is made about the packages in the default channel :wink:

0 Likes

#52

I’m in a similar position with proprietary code and the entire concept of uploading it anywhere freaks me out. I mean, I did create an alternative package. But banning someone is pretty severe. Example: I have interacted with abe33 from Atom’s Minimap previously when working on Atom packages and he is a super friendly and helpful guy. His involvement with Kite was clearly a misjudgement he really regrets. Gotta assume he just didn’t think it through, and give him the chance to correct himself. Tito is quite a different case of course, but still, I don’t believe a permaban is the way to go. The community will be extra alert for anything he creates any way. Better to let him retain his account, rather than being forced to create a new one.

0 Likes

#53

If I understand it correct Minimap added some commands to open Kite related homepages, but did not violate the users privacy by collecting some statistics. Hence this whole discussion wouldn’t affect the behavior of that package.
In general adding a way to quickly open homepages can be very useful. E.g. a python package with a command to open the PEP8 homepage or the documentation. I also added something like this to the LaTeXTools package. IMO the problem starts if you get money to add the links/commands, because then your are advertising instead of providing useful stuff for the user.

2 Likes

#54

Thank you for taking this seriously wbond. I also vote for solution #1. Thanks for bringing this to the attention of the community. Packages should not track users in any shape or form without prior consent.

0 Likes

#55

The blanket invitation to re-add addons if they get caught is far too soft and probably even encourages bad behavior.

There should be some sort of soft grace period for existing packages to get changed, but blatant abuses like SideBarEnhancements absolutely warrant a much harsher response. Maintainers essentially accepting bribes to inject malicious code is not something that can be allowed to stand if anyone expects the ecosystem to survive.

1 Like

#56

So you put some crappy tracking code in your package and then forgot about it for over a year? If I were one of the people who just invested $4M in your start-up, I’d be pretty concerned about my money right now.

1 Like

#57

The primary reason I added SideBarEnhancements back so quickly is so that all users get upgraded to a version with no tracking. Otherwise, no one would be able to install it fresh, but all current users would keep being tracked.

4 Likes