Our goal is to provide you with the fastest and most reliable open source services. To achieve this goal, we collect metrics on endpoint performance and send a fully anonymized telemetry report ("anonymous usage statistics") to our servers. This data helps us understand how changes impact performance and stability of our open source service and identify potential issues.
We are committed to full transparency on what data we transmit why and how. The source code of the telemetry package is completely open source and located here. If you do not wish to help us improve our projects by sharing telemetry data, it is possible to opt out of this feature.
We want to give you a thorough understanding why we collect this data, how we collect it, and what we do with it, as well as real-world examples of how this data improved a project.
The data processing pipeline has the following steps:
- Telemetry data is collected at each service.
- Periodically this data is sent to the segment.com API.
- Segment forwards this data to a private AWS S3 Bucket owned by the Ory organization. The data is not shared with any other party.
- The AWS S3 Bucket(s) are periodically downloaded onto on of our on-premise servers.
- The downloaded data is extracted, filtered, processed, and analyzed. The output is a CSV report which we analyze using Open Office.
We built this pipeline with the following goals in mind:
- Be able to say how many production deployments exist.
- Understand which features are used and how.
- Understand how much throughput deployments handle.
- Evaluate how frequently specific features are used.
- Detect issues introduced by new features (e.g. buggy releases).
- Identify problems at scale (e.g. slow endpoints).
- Understand which versions are deployed.
The following real-world outcomes have been achieved using this data (excerpt):
- We were able to identify that Ory Hydra's Warden and Policy API were heavily underused and decided to move these APIs to a different project (Ory Keto) which has been received very well by the community.
- A v1.0.0 beta released caused a heavy increase in response times for certain environments at one Consent API endpoint. We identified that a missing database index caused this issue and resolved it in the next patch.
- We learned that many developers still run old versions, sometimes with critical security vulnerabilities. To resolve this, we improved the release process and introduced a release newsletter. Use of vulnerable versions has dropped by 20% since then.
- A heavy uptake in usage of Ory Keto showed us that we need to provide certain migration tools for an update that introduces breaking changes. We were under the impression that the service was only used in test environments.
You can opt out of software quality assurance features (telemetry)
- by providing the
- by setting environment variable
- by setting the yaml configuration key (if supported)
Disabling telemetry does not have any downsides, except for us not being able to improve the project. Note that Ory always sends minimal ping with version information once on start up.
To protect your privacy, we filter out any data that could identify you or your users. We are taking the following measures to protect your privacy:
- We only transmit information on how often endpoints are requested, how fast they respond and what HTTP status code was sent.
- We filter out any query parameters, headers, response and request bodies and path parameters. A full list of transmitted URL paths is listed in section Request telemetry.
- We are unable to see or store the IP address of your host, as the
IP is set to
0.0.0.0when transmitting data to our metrics aggregator.
- We do not transmit any environment information from the host, except:
- Operating system id (windows, linux, osx)
- The target architecture (amd64, darwin, ...)
- Number of CPUs available
- Binary build time, git hash, git tag
- Memory consumption of the process
The information is stored in an aggregated format without any personally identifiable information.
To identify an installation and group together clusters, we create a SHA-256 hash of unique information (e.g. host, port) for identification. Additionally, each running instance is identified using an unique identifier which is set every time the service starts. The identifier is a Universally Unique Identifier (V4) and is thus a cryptographically safe random string. Identification is triggered when we are confident that the instance is not a test instance (e.g. one of the tutorials or a local installation).
We collect the following system metrics:
goarch: The target architecture of the service binary.
goos: The target system of the service binary.
numCpu: The number of CPUs available.
runtimeVersion: The go version used to create the binary.
version: The version of this binary.
hash: The git hash of this binary.
buildTime: The build time of this binary.
The IP addresses of both host and client are anonymized to
identifiable information in the URL path and query is hashed with SHA-256 using
a randomly assigned UUID v4 salt:
The full code-base is open source.
The following code snippet represents two raw event types (
identify) collected by a real Ory Hydra instance: