On Telemetry and Other Data Collected by SQL Server

Aaron Bertrand

Published On: April 4, 2016

Categories: SQL Server 2016, SQL Server, telemetry 0

tin_foil_hatThere have been some minor changes to the privacy statement for SQL Server 2016 compared to prior versions (for reference, here is the current version, which is subject to further changes before RTM, and here is the SQL Server 2014 version). I viewed the source, saved the HTML files, replaced <span with \r\n<span, and ran a diff, to make sure I wasn't missing anything crucial about telemetry, privacy, and information disclosure.

They describe what they're collecting in a little more detail, what's turned on by default, and how to turn them off. These changes will be immaterial to most users, but there is almost certainly a measurable number of folks who will be quite concerned by this change. Let me just break down quickly what the changes mean at a high level.

The bad news

In SQL Server 2016, feature usage and error reporting have gone from an opt-in model to an opt-out model, meaning you are opted in by default. You can see how these items were opt-in checkboxes (unchecked by default) during the setup of previous versions. Here are two different places during SQL Server setup where you could control this behavior in SQL Server 2012:

telemetry in 2012

error reporting in 2012Sorry about the quality; 2012 setup doesn't get to this point in HiDPI mode

In SQL Server 2014, the wording on the screen changed slightly, and the Error Reporting dialog disappeared altogether:

telemetry in 2014

In SQL Server 2016, the feature usage checkbox has been removed, and the wording has changed again, with an additional very loud disclaimer in the EULA:

telemetry in 2016

In the current RCs, this means that in order to fully opt out, you need to perform one or both of the following actions:

  1. Use the Error and Usage Reporting tool (just like you could in previous versions to change your selected option during setup), and uncheck all the boxes:

    Error and Usage Reporting

  2. Perform two registry changes (one is similar to the registry change you could implement via Group Policy in prior versions):
    HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\130\CustomerFeedback
    (DWORD; 0 = opt out)

    HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\130\EnableErrorReporting
    (DWORD; 0 = opt out)

    (On older versions, you may find these keys under HKEY_CURRENT_USER. Also, the current privacy statement indicates that you can turn "CustomerFeedback" off in Management Studio, but in the latest Visual Studio 2015-based builds, the menu option indicated no longer exists.)

Between now and RTM, the privacy statement should be updated to indicate any other steps that need to be taken. Note that, other than not being on any network at all, you can't opt out of the step during setup that reports back to indicate whether installation was successful.

The good news

The data they're collecting is generic, anonymous feature usage data. They want to know things like, just as an example, how many people are using Clustered Columnstore indexes, how big they are, how long rebuilds and compression take, and so on. They use that data in aggregate to see where there may be room for code improvements. They're not looking at the data inside your tables, transmitting usernames and passwords, performing static code analysis, critiquing your coding conventions, or any of that. But you can still turn it off, if you really want to. And for all I know, some of these defaults may well only be turned on for the duration of the release candidate phase, to be turned off by RTM.

My plan

They're collecting this data to improve the product. Period. They're not spying on you, or collecting inside knowledge about your baseball card collection, or auditing your compliance. So, I am going to leave this collection enabled, until they give me a good reason to deny them the benefit of the doubt.

And I will admit to having a bit of bias here - we are looking at ways to collect better telemetry about our software, too. We have no interest in looking at your data or stealing your identity, and certainly not without your consent or without an easy and obvious way to turn it off, but we are always very interested to know which features you use and how, where you have challenges, etc. so that we can make our products better and have some level of confidence in how to prioritize investments.

If you still have concerns, I recommend that you go over the EULA, load up the current privacy statement, click Expand All, and grab a large coffee. There is a ton of information there, and only you can decide if you need to be concerned about any of the data collection that could happen. If you have read the EULA and the privacy statement, and are still concerned, please contact Microsoft directly.

Aaron (@AaronBertrand) is a Product Manager at SentryOne, with industry experience dating back to Classic ASP and SQL Server 6.5. He is editor-in-chief of the performance-related blog, SQLPerformance.com, and serves as a community moderator for the Database Administrators Stack Exchange. Aaron's blog focuses on T-SQL bad habits and best practices, as well as coverage of updates and new features in Plan Explorer, SentryOne, and SQL Server.


Comments

SentryOne Monitor Ad