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.
Here is a very practical question from a ST3 and SidebarEnhancements user:
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:
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.
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.
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.
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.
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.
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?
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.
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 
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.
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.
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.
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.
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.
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.
Users here are being too kind.
I have developed a trust with sublime text over the course of years.
This company saw fit to violate that trust and now acts like they made a simple mistake, forgot about the spyware they wrote and unwittingly distributed to users.
I say ban them immediately. Show the community this is unacceptable and that sublime text stands by its users. Anything less is disrespectful to us and an insufficient punishment to the liars who spied on us.
This is a really good reason to re-add it back, but at the same time it still gives a lot of power back to the maintainer – which has clearly acted out of selfish interests already. I don’t think a plugin or plugins maintained by this maintainer should remain on package control for this. It sounds harsh, and maybe Tito could chime in as to what led to this, but it seems silly to let him get off for a decision that’s just as much his fault as it is Kite’s.
Maybe money. I can see no benefit that sending data to kiteco would bring to SidebarEnhancements. I have no proof of this. I know tito was also getting aggressive for donations by putting a menu entry in the sidebar to give dontations.
Kiteco sounds pretty shady in their practices: http://www.techrepublic.com/article/how-startup-kite-tried-to-ruin-two-open-source-communities/.
Edit: again I’m not saying any money changed hands, and I am not trying to smear anyone’s name, but I would love to hear the motivation here as I can only guess.