It’s been a while since the Eclipse Foundation decided to stop the Usage Data Collector. The main reason for stopping this service was that, although thousands of users shared data, neither plug-in providers nor researchers took significant advantage of the data collected at that time. Since its shutdown, however, a new demand for collecting usage data evolved. But compared to the data collected by the UDC, today’s demands are different and vary quite a lot from project to project.
The JBoss Tools project, for instance, is very interested in collecting facts like which Java version and operating systems or which screen resolutions their users typically work with. The Eclipse M2E project likes to know which versions of their bundles are actually in use and wants to learn about the setup their tools are typically used in. The Eclipse Code Recommenders project likes to learn which APIs people use and in particular with which APIs developers struggle most (and why) to continue researching how to make development more effective. Last but not least, there is a new initiative to collect errors from the Eclipse logs and reporting them back to Eclipse to make committers aware of potential issues in Eclipse Mars milestones, and thus, help fixing issues more quickly.
I think it’s easy to see that all these plug-ins (i) request to access quite different data compared to what the UDC collected before and (ii) want to learn more about their communities because they want to improve the user experience.
However, collecting data from its users, no matter how noble the goals and motivation for collecting it may actually be, is a topic the Eclipse Foundation (for good reasons) is very sensitive about. While the discussions how to implement the „calling home policy“ are still going on, I’d like to share (in a short series of blog posts) our first approach to a common and reusable Privacy UI infrastructure at Eclipse.
The implementation was done by Yasser Aziza during his Google Summer of Code project and mentored by Andreas Sewe and myself. Many thanks go out to Google for supporting this project and, of course, Yasser who did quite a good job on implementing these ideas.
Note that this blog post does not represent the official position of the Eclipse Foundation on this topic. This post isn't anything else but my personal understanding of the requirements as of today.
Some Requirements for Plug-ins Calling Home
It makes sense to sum up the current requirements and rules an Eclipse project has to obey before sending any data to any server.
- First of all, it needs permission of the Eclipse Management Organization to collect data. A review takes place where the project has to explain which data it aims to collect, why, and how.
- Then, any project that want’s to send data must ask the user to explicitly opt-in. Without an opt-in, no usage data will be sent.
- All data an Eclipse projects want’s to collect has to be send to a server hosted at eclipse.org.
- All communication should be done using secure protocols like HTTPS (where appropriate).
- No data should be send that contains personal data (like user name, email address) or any other sensitive data – unless consented to by the user.
- All projects that want to collect and send usage data, should use a common user interface to allow users to manage and control their opt-ins in a centralized manner. This is what Wayne Beaton refers to as the „We mustn’t look goofy“ requirement.
Our First Approach to an Eclipse Privacy UI Framework
While the requirements 3-5 are quite specific for each project, managing a user’s opt-ins is something that could be centralized easily. This is where Yasser’s GSoC project comes in. The idea of his GSoC was to provide a central service that (i) allows to collect a user’s approvals about what usage data (s)he wants to share with Eclipse projects, (ii) allows users to easily manage his/her own opt-ins, and (iii) provide a set of common classes and extension points that allow other plug-ins to easily reuse and extend existing infrastructure and to provide a common look-and-feel.
In this first blog post, I’ll introduce you to the most important UI elements Yasser implemented so far. In a second blog post I’ll provide a lot more technical background, implementation details and guidelines on how to extend the plug-in for your own use.
Installing the prototype
Yasser’s latest prototype can be installed from the Code Recommenders Incubator update site hosted here. When you direct your Eclipse Update Manager to that site, you’ll get the following installation screen. Simply select „Code Recommenders Privacy Preferences“ as well as „Code Recommenders Privacy Preferences Example“ from the first category and click Next > Install.
After a restart, Eclipse welcomes you with new dialog introducing you to the Eclipse Privacy UI Framework:
After pressing Next, the dialog informs the user that a new plug-in has been installed (the example plug-in) which want’s to share some data:
When hovering over the „Heartbeat“ entry, the dialog shows a tooltip which briefly describes what exactly the plug-in intends to share. In addition to the brief description, the plug-in can also specify a policy URL where the user can find a more detailed description of what get’s collected and why et cetera:
At this point in time, the user can decide whether (s)he want’s to opt-in and share the requested information with the plug-in provider (by checking the Heartbeat box) or not to opt-in by simply pressing Finish without giving permission to any of the new requests.
Managing and Controlling existing Opt-Ins
Over time there may be more than one plug-in that requests permission to send data. And at some point in time, a user may want to review or change his previously made opt-ins. This can be done quickly in the Eclipse Privacy UI’s preference page located under General > Privacy:
The preference page lists all currently installed plug-ins, their requested usage data, and the user’s opt-ins or opt-outs. By enabling (or respectively disabling) permissions and clicking on the OK button, the settings are updated and stored.
One note on the implementation
There is one important point every reader should understand: The Privacy UI plug-in does not control which resources a plug-in actually accesses. It does not install any security manager. It merely provides a registry and a common UI with a set of reusable dialogs for managing user opt-ins. In addition it provides a few extension points allowing 3rd parties to register own extensions, lifecycle hooks and provides some APIs to simplify writing plug-ins which wish to collect information from their users. So, whether or not a plug-in honors the user’s opt-in preferences is up to the individual plug-in itself.
In the second blog post about the proposed Eclipse Privacy UI, I’ll detail how Eclipse projects (and third-parties as well) can contribute to the Eclipse Privacy UI by registering their own extensions and how they can customize the UI to their needs (like using their own opt-in dialogs et cetera). Stay tuned.
Accessing the Source
In case you’d like to take a deep dive into the source code right now, check out the project’s build notes on how to setup this project in Eclipse (with Eclipse Oomph) or build it from command line with Maven.