GDPR Compliance

Tideways is a European company, and as such is very aware of the GDPR data privacy regulation which came into effect on the 25th May, 2018. In fact, we have always built Tideways from the ground up to not store personal data from our customers by default, when our software collects error or performance data from your application.

What’s more, Tideways provides you with flexible customization APIs and configuration options to allow correlation of collected errors or performance data with any of the data inside your application, if you so wish to transmit it, including personal data. While our Terms Of Use explicitly state that using instrumentation APIs to transmit personal data for correlation is prohibited, the flexibility of the API makes it nearly impossible to automatically filter with 100% certainty.

Being GDPR Compliant

To be GDPR compliant when using Tideways, you have three options:

  1. If you consciously decide to transmit personal data to Tideways — or just in case you want to make sure you are compliant in case data is accidentally sent as part of Error or Performance data — we offer to enter a standardized data processing agreement (DPA) to formalize the data-controller (you) and data-processor (us) relationship. Go to the Legal page inside Tideways to start the DPA process.

    In addition to using a well-known template by the German Bitkom association to make the language familiar and easy to review, the DPA can be agreed to electronically (as per § 28 (9)) by a legal representative of your company. We provide you with a form on the Tideways Legal Compliance page that you can fill out to generate the DPA contract as a PDF and get a copy via e-mail.

    image

  2. You can make sure that you do not transmit personal data, by carefully using the manual instrumentation APIs not to include personal data. See the custom instrumentation docs and specifically your use of  \Tideways\Profiler::setCustomVariable.

  3. You can enable "lockdown mode" to enable aggressive filtering of any trace or error payload information that could potentially include anything personal. This prevents accidental leaks of information to us, but also reduces the visibility into a lot of non personal data as a precaution, and should therefore be the last resort. Please send us an e-mail to [email protected] to enter lockdown mode.

Personal Data

With regard to your own personal data, such as names, e-mail addresses, and billing information, our Privacy Policy includes details about how we handle your personal information and what third party sub-processors we use for what task.

If you have questions about Tideways GDPR Compliance, send an e-mail to [email protected].

What Does Tideways Technically Do to Prevent Accidental Transmission of Personal or Sensitive Data as Part of Regular Error / Performance Data?

In general, our collection of error and performance data is built in a way such that it never collects personal data, such as IP addresses, user agents, email addresses, usernames, or cookies. We believe that this approach, of being defensive about personal data, is important. Therefore, we made it a central feature of our product.

Tideways has a software agent called "tideways-daemon" that will be running on your infrastructure and is responsible for filtering data to be anonymous and free of personal data. It acts as a firewall that makes sure outgoing data is free of personal data. Since the data is already filtered on your servers, its not leaving your control and Tideways is not the processor as per GDPR.

Technically, we implement the following (as well as additional) steps to make sure data is filtered before it is sent to our servers:

  • SQL statements from your application that don’t use prepared statements can potentially include personal information in string quotes. For this reason the tideways-daemon parses every SQL statement and removes all literal strings that are included in the SQL. It has support for many different SQL dialects and idioms to detect such literal strings, and if unsure about its findings or when it cannot parse the statement, then it defaults to throwing away the statement and doesn’t pass it on to our backend.

  • URLs can potentially include personal data, but since they also appear in logfiles and referrers, it is good practice to keep them free from personal data. When transmitting URLs for visited pages in performance traces, we remove sensitive parameters from the query string entirely such as "email", "ip", "name", "username", "firstname", "lastname", "access_token", "api_key" and many more. A set of regular expressions are used to remove potentially sensitive or personal parts from the URL path.

  • When you use the custom variable functionality to correlate your application data with performance and error data in Tideways, we run various filters on all data and blacklist a few variable names that probably contain personal data.

  • In contrast to other tools, we never store cookie, IP address or user agent information from your users in case they trigger exceptions or errors. This reduces the time to fix a problem if you need this information for debugging, but conforms to Datensparsamkeit, by not storing too much information.

  • We review custom variables transmitted by you explicitly to Tideways based on their names and may decide to send configuration to the daemon to delete them on the daemon already, if we think they contain personal data unless you sign a data processing agreement with us. We will inform you about the steps we take.

If Lockdown Mode is Enabled, What Data is Going to be Filtered?

In case your account is in lockdown mode, then in addition to our filtering of potential personal data, Tideways will:

  • Remove all annotations from the root application span, except some Tideways related information and the "title", which in the case of an URL is stripped down to only the method and host. For example, if you use \Tideways\Profiler::setCustomVariable('user', $userId); on a URL, for example GET http://myexample.com/foo/bar/1234, then the "user" annotation is deleted completely and the URL is stripped to GET http://myexample.com.

  • Outgoing SQL and HTTP spans are stripped, from any details and only a summary is provided, based on a whitelist of controlled information pieces. In case of SQL, the type of statement such as SELECT, UPDATE, INSERT, DELETE and the name of the involved tables. In case of HTTP spans the host and method.

  • The error message from exceptions and fatal errors is removed entirely, unless we know from a whitelist that the exception/errors don’t contain personal data.

Still need help? Email [email protected]