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, there are three levels:

  1. We include a standardized data processing agreement (DPA) to formalize the data-controller (you) and data-processor (us) relationship as part of our General Terms of Service. It describes all data processing and the third party services we share which data with. Profiling, Monitoring and Exception Tracking data collected from your application(s) is only ever processed with our hosting company SysEleven GmbH. See the Data Filtering section on the active mechanisms that purge, anonymize and filter data so that no personal data reaches our servers.

  2. You can make sure that you do not transmit personal data of your users, 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. Do not use these APIs to transmit emails, user names, and other data.

  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. GDPR Lockdown can be enabled in the General Settings of your organization.

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].

Data Filtering

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.

Lockdown mode

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]