Last week, I wrote about the creation of a “Call Home” policy for Eclipse projects. It’s been a busy week that’s seen a lot of discussion on Bug 413169 and the Cross Project Issues Dev mailing list.
“Hi honey, it’s me. There’s a double rainbow. It’s so beautiful.”
The discussion was initially intended to address things like having Eclipse project software send a “heartbeat”, or upload usage patterns, but the discussion expanded to include activities like checking for updates, or pulling news items to display on the Welcome page. It’s not really about “calling home”; it’s more of a policy regarding Eclipse software uploading or downloading information.
In my mind, there are four different scenarios.
User-initiated activity. In this scenario, the sort of communication that occurs is implied by the operation itself. There are no special considerations for this scenario.
For example:
- User clicks on a hyperlink;
- User selects “Check for Updates”; or
- User initiates a build that pulls data from a Maven repository.
An automated process initiating a download of information. The Eclipse software initiates the communication without the explicit knowledge of the user. No information is uploaded to any server beyond that which is transferred by the protocols involved (i.e. IP addresses). Again, there are no special considerations for this scenario.
For example:
- Pulling news items; or
- Updating a task list.
An automated process initiating an upload of very specific data. The Eclipse software initiates the communication without the explicit knowledge of the user. Some information is uploaded, but there is no potential for that data to be used to identify any individual or organization. This service is turned on by default, but there must be a means for the user to turn it off.
For example:
- Sending a “heartbeat” that identifies a specific bundle/version; or
- Uploading a list of all Eclipse Foundation-signed bundles;
An automated process initiating an upload of dynamic data. The Eclipse software initiates the communication without the explicit knowledge of the user. Non-trivial data is uploaded: there real potential for this data to be used to identify a specific individual or organization. This service must be turned off by default, and can provide the user with means to turn it on.
For example:
- List of all currently installed bundles (may include custom bundles);
- JVM version (may be a custom JVM); or
- Usage patterns
In all cases, the Eclipse Privacy Policy must be followed.
Eclipse project code must only upload to an Eclipse Foundation-managed server (adopters may extend Eclipse software to upload to alternate targets). Raw data that may include non-obvious potentially private information must be transferred and stored securely. Access to collected data must be strictly controlled; access is granted only to committers who have signed a non-disclosure agreement (NDA) with The Eclipse Foundation.
I am particularly concerned that the user experience be carefully managed. Requiring that a user hunt down preferences checkboxes to turn off dozens of different “heartbeat” services is a horror scenario. Coordination of this sort of service is an absolute requirement.
I’m a little behind with updates to the policy document being drafted on the wiki, I’ll address that shortly. One thing that’s clear is that we need a better name than “Call Home” Policy.
Note that this policy is not yet in effect. This post only reflects my current understanding. Your input may change the direction we ultimately take. Please weigh in on Bug 413169.
