Sublime Forum

**wbond** · August 2, 2017, 2:03am

So far around 40k installs of SideBarEnhancements have been upgraded to the version without tracking.

**Nicd** · August 2, 2017, 7:29am

Hello, I am the developer of Code::Stats and its ST3 plugin. I’ve been reading this thread and haven’t found any conclusions yet. Here are my concerns (that may not be answerable yet, but are here for consideration):

The only point of my plugin is to collect usage data (amount of typed chars per language) and send them to the service. Will this be considered under an opt-in system? Will there be an API to accomplish the opt-in? Is “add your API key to the settings” enough of an opt-in?
The user needs to register to my service, which has its own privacy policy (I would link here but new users can only add 2 links so click on the “Legal” link in the footer of the site). Will the plugin need an additional policy if it only communicates with the service?
Will plugin authors be notified when a conclusion is made regarding policy changes in PC?

Thanks for all your efforts regarding ST/PC development.

**afinzel** · August 2, 2017, 11:38am

Maybe Apple has it right? As a long term solution, make the package request access to that data. When it requests the user is prompted and then confirms if they agree for that to be given to the plugin. Otherwise the plugin has no access to the data. The same could be done for editing documents etc.

In the short term 1 and 2 sounds good.

**wbond** · August 2, 2017, 12:28pm

There won’t be a reasonable way to enforce such a solution without effectively maintaining a heavily-modified fork of the Python programming language, which isn’t going to be possible with our current development team, and likely won’t be practical even with a much larger team.

I think it would be possible to create a notice when installing a package with Python code, and warning a user if an upgrade adds Python where none existed before. But then again, the number of packages with Python would probably desensitize most users to the point where it would likely be effectively ignored.

**dingo-d** · August 2, 2017, 2:11pm

What I’m now interested in, is to see what other packages I have installed have kite tracking code in them… At least be honest and notify a user about the change in a readme or somewhere…

**gj1118** · August 3, 2017, 7:09am

Hi , I am rather curious now. Can somebody confirm if Anaconda is also collecting telemetry just like this wretched plugin (sidebarenhancements) ?

Thanks.

**r-stein** · August 3, 2017, 7:19am

As I already stated Anaconda does not collect data, but you can disable certain features if you use Kite. It also does not add commands to open Kite home pages (like Minimap) and uses jedi as local json server and did not switch to Kite (which was the critism with autocomplete-python).

**gj1118** · August 3, 2017, 7:30am

I uninstalled kite from my machine, and the plugin as well. I removed SidebarEnhancements as well . Is there anything else that I should be doing to protect myself ?

Also I wonder when an apology from Tito is going to come for having fooled the community? If he wanted to make a few quick bucks for his plugin (and there is no harm in doing that ) he could have easily followed what other plugins are doing to raise money for their work -

Thanks

**r-stein** · August 3, 2017, 7:32am

SideBarEnchancement does not track anymore, but I would also stop using it. I am not aware of an other tracking plugin, but I don’t think it there is one, because SideBarEnchancement is so common that it would not be necessary. Nonetheless it would be good to review popular packages.

**wbond** · August 3, 2017, 2:40pm

Just as a follow-up, I wanted to say thank you to @adam314 for getting the tracking server shutdown so no more data is being sent, even if users haven’t been upgraded to the latest version of SideBarEnhancements.

**gerry** · August 3, 2017, 11:25pm

The Anaconda* packages are not based on Kite and do not send the full contents of files to Kite. That is not an accurate representation of the packages. I projected my own sensitivities around this issue onto the Anaconda packages. And as far as I understand, no, it does not send Telemetry data home or anywhere, or contain any Telemetry like SideBarEnhancements.

I updated my post above with the correction.

**bix** · August 3, 2017, 11:16pm

So here’s an example of something absolutely terrifying: https://twitter.com/o_cee/status/892306836199800836

Here’s the deal, and I’m sure I’m not alone…

Regardless of the outcome of this particular discussion, if I ever get burned by a package like the above twitter I’ve installed through the package manager, I will likely pick up Pycharm and drop Sublime extremely quickly.

There really needs to be a super harsh and very clearly drawn line. Banning seems mild, imo, compared with unknown access to data, servers, ssh keys, postgres instance information, etc. – whatever is in an environment variable on your development system. Arguably, maybe there’s some way of reducing the attack vector and relying less upon environment settings and more upon some other security mechanism, but my infrastructure team is loathe to add more infra to manage and I still have deadlines…

Honestly, telemetry data is relatively mild, but the fact is that this is a huge security hole and it really needs to be plugged as best as possible.

**gj1118** · August 3, 2017, 11:19pm

I am sorry but I think that this statement does imply intrinsically that it sends some telemetry data to home base (although the full contents might not be sent). Is my understanding correct or am I being too paranoid?

**gerry** · August 3, 2017, 11:23pm

As far I understand, no it does not send any Telemetry data home or anywhere, or contain any Telemetry like SideBarEnhancements.

**gj1118** · August 3, 2017, 11:24pm

@gerry thank your Sir for confirming that.

**FichteFoll** · August 4, 2017, 2:06am

What is this security hole you’re talking about? That Python plugins are not executed in a sandbox? I do not believe it is feasible to add a sandbox like a web browser around an application like ST for multiple reasons. If you’re concerned about the code that may be running on your machine, you should start reviewing all that code.

Besides, there isn’t a whole lot we can do besides banning someone from publishing packages through our channel. You may potentially sue the person for damage they may or may not have inflicted on you, but unless we are also affected by that we can’t.

On another note: We’re already mitigating the typo-squatting attack vector by hand-reviewing all package additions. See also this very relevant HN discussion about a very relevant bachelor thesis: https://news.ycombinator.com/item?id=11862217

**bix** · August 4, 2017, 3:25am

Suing is a ridiculous comment as is suggesting every developer to parse through all plugin code.

Typosquatting is completely orthogonal to parsing my environment variables (but thank you for alleviating any concern there). Please don’t obfuscate my previous post or redirect to some non-problem.

And yes, I really do think ST could do a better job in sandboxing the python running the plugins. Disregarding a problem doesn’t make it go away.

**wbond** · August 4, 2017, 4:17am

We have a manual review process (of which @FichteFoll is the most significant contributor in the history of Package Control) to help prevent typo squatting and review the package as a whole.
We have automated tests that check for all sorts of common errors and issues.
We require that all packages part of the default channel are served over HTTPS

None of that will prevent a malicious actor from stealing your code. Fundamentally you need to trust the author of the package you are installing.

If someone wants to steal a whole bunch of code, the process involves building a useful package (with a fair bit of complexity) and maintaining it for a while, and then injecting a small bit of code to make outgoing connections in the middle of a big refactor or other large change.

This could happen on any platform that allows community-written plugins, doesn’t have a locked-down environment where all changes to plugins are reviewed, and allows socket connections.

Ultimately, if you really care about the security of your environment:

don’t install any packages that aren’t shipped with Sublime Text
or: install only packages that you’ve reviewed the source code of, and disable automatic updates

You could also use a tool like Little Snitch.

In general, these safety guidelines are probably applicable to just about any editor where you are installing third-party packages onto.

Google still hasn’t managed to get their custom sandboxed version of Python (on the App Engine Standard Environment) ported to Python 3. I don’t think it would be a wise use of the Sublime HQ engineering resources to go down that rabbit hole.

Some reading about Python sandboxes:

pysandbox – failure – https://lwn.net/Articles/574215/
PyPy sandbox – no stable PyPy3, no sandbox for PyPy3, interaction with sandbox unimplemented – http://doc.pypy.org/en/latest/sandbox.html

Since the Sublime Text Python environment needs access to your code to do much of anything useful, the real target would be locking down network access. This is a non-trivial amount of work, fraught with issues no matter what the approach. In the end, are you going to trust that the sandbox implementation is secure enough?

The alternative is that you err on the side of caution and not run third-party packages if you have sensitive code you are working on. Disregarding a problem doesn’t make it go away, but not introducing the problem to your environment is a valid solution.

The real crux of this topic is how the Sublime Text community is going to deal with issues related to behavior of packages in the default channel. So far pretty much all responders want some rules.

At the very least everyone wants telemetry it to be opt-in. Many want all telemetry banned. Some don’t even want Package Control to default to reporting package stats.

For violations of the rules, some want grace periods. Others want immediate bans of all packages by an author (although with anonymous contributors, this doesn’t stop someone from creating a new persona).

No matter what rules or penalties we come up with, there are going to be users who think it is too little or too much. I’m sure some people will decide to leave the community based on principle. It won’t be possible to make everyone happy, but we do need to come up with some sort of way of handling these situations.

At least we made it 6 years without having to deal with such rules!

**gerry** · August 4, 2017, 5:36am

I’ll be disappointed if one of the outcomes of this is to continue to allow the general case of data collecting.

What is the “general case”?

Data collection, which features of a package are not dependent on, should not be allowed.

Let’s be clear about at least one thing: you will be hard pushed to find people who are going to argue that the features of SideBarEnhancements are dependent on the data collecting it was doing.

Examples of what are not acceptable arguments, include, but are not limited to:

collecting data to “improve a product”, “understand usage because/to …”, etc.
collecting data to sell it to pay to develop the package

It’s frustrating when proponents of data collecting attempt to blur the lines of what should and shouldn’t apply, and then inevitability throw their hands in the air and claim that we might as-well just allow it, because you know, it’s too complicated, when it isn’t complicated at all.

Let’s look at a concrete example. We’ll use SideBarEnhancements (SE) as a starting point.

I think there is consensus that data collecting similar to SE is not allowed, but what does that actually mean? Are we saying a package must be “up-front” about who it’s collecting for? They can easily flout that rule and there’s nothing anybody can do about it, unless you catch them of course.

Let’s imagine that SE and Kite were upfront about it. Let’s go further, let’s assume due diligence, for example, let’s imagine they had a privacy policy, and that the readme clearly explained the data collecting. Are we good? No, we’re not good. Let’s go further.

Let’s imagine that the data collecting is opt-in (not even opt-out), opt-in. Let’s imagine that when the package is upgraded the user is prompted and asked, very clearly and above board, no shenanigans, they are asked to opt-in. Are we going to allow this? I hope not. To reiterate, I think the new rules should at least include:

Data collection, which features of a package are not dependent on, is not allowed.

@braver’ rule, which I think is a good rule and should also be part of the new rules, would also rule-out the above, because, the data collecting is being added after the fact.

Let’s go one further. Let’s imagine the SE package, which in our example, now has a clear privacy policy, clearly informs about the data collecting, is opt-in and prompts the user for permission and is clear and straight and up front about it all. Let’s imagine it’s new, not an upgrade. Will it be allowed?

No.

Data collection, which features of a package are not dependent on, is not allowed.

**Nicd** · August 4, 2017, 5:45am

Just wanted to note that as far as I know, JetBrains does not have any package review. In addition, the plugins are binary JARs instead of just source files like many ST plugins. So I would apply the same care to JetBrains plugins as to ST plugins.

RFC: Default Package Control Channel and Package Telemetry