Before I begin, this is simply an idea I have been thinking about for a little while now, especially in recent years with the dominance of privacy eroding techniques being implemented by the big three (G/FB/MS). I also believe this technique would advance user privacy and control. Criticisms welcome.
Telemetry (n): The process of recording and transmitting the readings of an instrument.
Any software project of sufficient complexity likely performs some form of telemetry. The most common form of telemetry is logging. Crash logs are essential for finding the root cause of difficult to reproduce bugs and maintaining one or more machines remotely will likely also require some form of telemetry. Even a survey that is accompanied by software versions could be considered a form of telemetry.
The largest issue with telemetry right now appears to be fragmentation and misunderstanding of the data being transmitted. The misunderstandings accompanied with lack of controls has led many to, rightfully, be wary of their privacy and the data that is being collected. Each application on a computer has the ability to arbitrarily transmit some kind of telemetry and it’s currently up to the developers to integrate the switches. Perhaps the only control we do have is over the logging system on a computer, and even that is suspect at times.
With all that in mind, I believe it should be an imperative to create a standard telemetry subsystem as part of the core operating system. This system would provide an extendable, standard interface where developers can specify the information the application can collect, as well as various options. This configuration could then be overridden by other system or user configuration files to limit, expand, or further configure telemetry settings.
The benefits to creating this system would extend far beyond personal privacy and into better remote management and better bug reporting.
I believe it’s inevitable that just about every large software project, especially one’s with commercial interests, will eventually include telemetry. Better to get ahead of it rather than trying to find work arounds after the fact. Just look at Chrome, Windows, VS Code, Adobe products, and even Firefox and Ubuntu. Whether you love 'em or hate 'em, there’s no denying that each of the one’s listed has advanced their field and has a non insignificant mindshare.
What are some use cases for a central telemetry system?
- You don’t want to transmit any telemetry data to third parties. Simply deny remote access.
- You want to monitor employee workstations, checking on system health, etc. Add an intranet server to a list of telemetry providers to send all the data and enable more verbose logging on each workstation.
- You have a server hosting an application and you want to remotely monitor the health of said server. Do the same as before, sending the information to some remote monitoring provider (or your own).
How would it be done?
I’ve been thinking of a couple ways this could be done, each with their respective tradeoffs. I believe in order for such a system to be truly effective, it would need a client and server type of system. Each client having configurations and a server where said information can be collected, viewed, and monitored. The server would probably be some kind of daemon running in the background monitoring itself and, if configured, other servers.
Below are two high level possibilities for implementing client configurations. Nothing too in depth, just gauging interest.
Option 1: TOML config files
This is probably the easiest and most straightforward method of keeping track of everything. It’s limited in customization, but robust in the limited features it would offer. The limitations would likely be a turn off to the big players who want more sophisticated controls. The config would have the ability to override them with other files (like customizing your code editor configs).
Option 2: Guile style declaration files
A much more sophisticated method for configurations, but also much more customizable. It would take the burden off the OS developers to implement every possible option and enable developers to create fully dynamic configurations with all kinds of knobs, switches, and buttons. As with the TOML files above, they could be overridden. Since every file is also a program, endless possibilities open up for both the application developer and anyone who wants to track systems.