3 Important Things You Should Know About Vendor Telemetry

At a time in our industry’s history where sharing any kind of personal data inappropriately can put a company out of business, the thought of automatically sending data to a vendor can understandably raise a few red flags. And yet, at the same time, the idea of being able to collect data around usage, issues, and feedback is easily achieved and is highly desirable by vendors. Often referred to as telemetry data, this information can be invaluable to a vendor to get key insights into their products in an effort to make them better.

So, where exactly should you stand on the topic of sending telemetry data?

On the one hand, you definitely want the products you use to rectify issues you’re having and to improve overall. But on the other, there’s a necessary concern around what kind of data is being sent and how is it being used.

Depending on the product in question, each vendor may implement a vendor telemetry program a bit differently. In general, you may be surprised that most large vendors have a hard time getting enough meaningful telemetry, and a lack thereof will make it difficult for that vendor to make improvements and fix bugs for certain use-cases. In this article, I’m going to use Microsoft’s telemetry program as an example, but keep in mind that, before you turn on the sending of any telemetry data, you should do your due diligence around what’s being sent and to whom by the vendor in question.

1. Telemetry data is (generally) non-identifiable – Because the goal of most vendors is to get information about their product, the data is usually focused squarely on their product, it’s current state, errors, issues, etc. In the case of Microsoft (who uses 4 telemetry levels), they specifically attempt to avoid collecting personally-identifying data. Think about it; it becomes a legal nightmare should that data be breached.
2. Telemetry data can include personal data – In certain circumstances, additional data is necessary to provide proper context. Take the case of an application crashing. If you were to want the vendor to understand the nature of the crash, they may need a copy of the data file you were working on. In Microsoft’s case, the use of the Full telemetry setting gives them permission to collect “extra” data as part of the investigation (which can include personal documents, according to their documentation).
3. You should look for ways to control the process – The simplest way to control telemetry is to decide whether to participate or not. It doesn’t affect your use of the product, nor your support; it’s merely a way for vendors to better understand how their product acts in the field. If possible, look for ways to specify what kind of data is allowed to be sent. Microsoft provides some Group Policy settings to manage this so that security and privacy can be maintained as necessary within your organization

Remember: Pay Special Attention to Compliance – While most big vendors like Microsoft will try to fashion their telemetry gathering in a way that doesn’t violate privacy laws like HIPPA, the onus is on you to verify that is actually the case for each and every vendor that you or one of your customers uses. If there are any questions whatsoever on this bullet point, it would be safest to just turn off telemetry gathering.

Telemetry: Helpful or Dangerous?

In concept, the idea of sending telemetry data is rather benign and even helpful in the long run. But it’s up to you to review each vendor’s stance on telemetry privacy looking specifically at 6 aspects of their program:

• What specific kinds of data are being sent?
• Is there ever a scenario where personal data or documents are sent?
• Can you limit/control the process?
• What vendor teams have access to the data?
• How is it being used?
• Are there compliance concerns?

Telemetry programs are designed to be helpful, so it’s good to at least consider participating. But, be certain to ask questions about the nature of the data collection and its use. Based on the answers to these questions, you can quickly determine whether you wish to participate and to what degree.

Resources

To aid you in finding relevant information regarding telemetry, I’ve placed a few useful links in the section below. These links will either explain how a given vendor handles telemetry data, or how to configure it for yourself or your customers.

• Microsoft Diagnostic Data in Your Organization
• Information Contained within VMware Diagnostic Data
• HP Privacy Statement
• Dell Country-Specific Privacy Policies
• IBM Privacy Statement
• Cisco Privacy Statement

Wrap-Up

While the gist of today’s article may give you the sense that vendor telemetry is bad, it really isn’t when monitored and review properly. Again, without proper telemetry, your core vendors have a much harder time improving the products and services you sell and use, so it makes sense to provide telemetry where applicable.

How about you? What are your thoughts on vendor telemetry? Does your MSP have a stance on this issue? Let us know in the comments section below!

Thanks for reading!