Jump to: navigation, search

Difference between revisions of "Policies/Uploading and Downloading from Eclipse Software Policy"

(Opt-in)
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Warning|This is a work-in-progress; this policy is not in effect.}}
+
{{Warning|This is a work-in-progress; this policy is not currently in effect.}}
  
 
=Overview=
 
=Overview=
This policy is concerned with Eclipse Foundation project code "calling home" or otherwise connecting from software distributed by the Eclipse Foundation to remote services.
+
This policy is concerned with Eclipse Foundation project code uploading, downloading, or otherwise connecting from software distributed by the Eclipse Foundation to remote servers/services.
  
 
This policy applies for software that:
 
This policy applies for software that:
 
* checks for updates;
 
* checks for updates;
* pulls information from websites;
+
* pulls information from servers;
 
* provides a heartbeat;
 
* provides a heartbeat;
 
* gathers usage statistics;
 
* gathers usage statistics;
Line 12: Line 12:
 
* otherwise collects information from user installations.
 
* otherwise collects information from user installations.
  
=Modes==
+
=Private Information=
  
When it is clear from context that information will be sent and/or received, user initiated activity--for example, a user-initiated build downloads artifacts from Maven central, or a user-initiated file transfer sends a file to a remote server via SFTP--are acceptable without formal approval.
+
All uploaded information is subject to the terms of the [http://www.eclipse.org/legal/privacy.php Eclipse Privacy Policy].
  
Processes that fetch data only (i.e. no data is sent from the user's workstation) from Eclipse Foundation servers--for example, pulling items from a news feed--are acceptable without formal approval. PMC approval is required for a project to implement a process that fetches data from a third-party source.
+
Raw data, which may include non-obvious potentially private information, must be transferred securely.
  
Processes that upload data--for example, a list of all currently installed bundles and/or JVM version, or usage patterns--require PMC and EMO(ED) approval. The default configuration for software produced by a project must target Eclipse Foundation-managed servers only for uploads. Exceptions to this rule can only be granted by the EMO(ED). Projects can (and should) implement extensible frameworks that permit adopters to upload data to different targets.
+
Raw data must be stored securely and access to the data must be strictly controlled. To access the raw data stored on an Eclipse Foundation Server, an individual must be a committer. An individual must sign a non-disclosure agreement (NDA) with The Eclipse Foundation to get access to raw data that may include personally-identifiable information.
  
=Opt-in=
+
Obvious means of identifying a specific individual or organization (e.g. IP address) must not be persisted. Server logs that are accessible only by Eclipse Foundation Webmasters are exempt.
  
Any service that uploads data must be "opt-in". That is, a user must agree to participate (agreement may be implicit due to the nature of the service).
+
Reasonable effort must be taken to avoid persisting or disseminating information that can inadvertently be used to identify an individual or organization.
  
If the nature of the data being collected changes, the user must be informed of the changes and be given the opportunity to explicitly agree to continue participation.
+
=Dissemination=
  
The user must be able to review any data before it is uploaded.
+
Information that can be used to identify individuals or organizations must not be publicly accessible.
  
Services that get/pull data only do not require "opt-in". The server components for these services must not attempt to persist any information related to a get/pull data service (server logs, with access restricted to administration staff only, are exempted from this requirement).
+
Documentation, including a full description of the nature of all information transfered by an upload operation, must be publicly accessible.
  
=Private Information=
+
The retention policy for publicly accessible data must be documented.
  
All uploaded information is subject to the terms of the [http://www.eclipse.org/legal/privacy.php Eclipse Privacy Policy].
+
=Approval=
  
Raw data, which may include non-obvious potentially private information, must be transferred securely.
+
When it is clear from context that information will be sent and/or received, user- or adopter-initiated operations--for example, a user-initiated build that downloads artifacts from Maven central, or a user-initiated file transfer that sends a file to a remote server via SFTP--are acceptable without formal approval.
  
Raw data must be stored securely and access to the data needs to be strictly controlled. To access the raw data stored on an Eclipse Foundation Server, an individual must be a committer. Access to raw data that may include personally-identifiable information must sign a non-disclosure agreement (NDA) with The Eclipse Foundation.
+
Operations that fetch data only (i.e. no data is sent from the user's workstation) from Eclipse Foundation servers--for example, pulling items from a news feed--are acceptable without formal approval. PMC approval is required for a project to implement an operation that fetches data from a third-party source.
  
Obvious means of identifying a specific individual or organization (e.g. IP address) must not be persisted. Server logs that are accessible only by Eclipse Foundation Webmasters are exempt.
+
Operations that upload data--for example, a list of all currently installed bundles and/or JVM version, or usage patterns--require PMC and EMO(ED) approval. The default configuration must target Eclipse Foundation-managed servers only for uploads. Exceptions to this rule can only be granted by the EMO(ED). Projects can (and should) implement extensible frameworks that permit adopters to upload data to different targets.
  
Reasonable effort must be taken to avoid persisting or disseminating information that can inadvertently be used to identify an individual or organization.
+
=Opt-in=
  
=Storage=
+
Any operation that uploads data must be "opt-in". That is, the user/adopter must agree to participate (agreement may be implicit due to the nature of the service).
  
The target for data collected by content distributed from an Eclipse Foundation-managed server must also be an Eclipse Foundation-managed server (e.g. the Eclipse packages must be configured to send data to an eclipse.org server). This can be configurable by adopters to send to an alternate server.
+
If the nature of the data being collected changes, the user/adopter must be informed of the changes and be given the opportunity to explicitly agree to continue participation.
  
=Dissemination=
+
Services that get/pull data only do not require "opt-in". The server components for these services must not attempt to persist any information related to a get/pull data service (server logs, with access restricted to Eclipse Foundation staff only, are exempted from this requirement).
  
Information that may be used to identify individuals or organizations must not be made publicly available.
+
=Common Mechanism=
  
The retention policy for publicly accessible data must be documented.
+
Reasonable effort must be undertaken to leverage existing mechanisms rather than create new ones.
  
=Auditing and Approval=
+
=FAQ=
  
Documentation, including a full description of the nature of all information captured by a call-home service, must be publicly accessible.
+
'''Does this policy apply to headless software?'''
  
The implementation of a service that uploads data must be reviewed and approved by the implementing project's Project Management Committee (PMC).
+
Yes.
  
The implementation of a service that uploads potentially private data must be reviewed and approved by the EMO(ED).
+
'''Do we have to present the user with a dialog box to request "opt-in"?'''
  
=Common Mechanism=
+
There are many different means of opting in:
 +
* A dialog box may be appropriate;
 +
* opt-in may take the form of a option in a configuration file; or
 +
* opt-in may be granted by the very nature of the operation (e.g. a menu item that initiates an artifact upload).
  
Reasonable effort must be undertaken to leverage existing mechanisms rather than create new ones.
+
The nature of the software itself may imply opt-in. It might, for example, be expected behaviour for machine-to-machine (m2m) component to attempt to discover peers. Simply running this software may be considered opt-in (though this starts to get into gray area and PMC involvement is recommended).

Latest revision as of 16:29, 22 October 2013

Warning2.png
This is a work-in-progress; this policy is not currently in effect.


Overview

This policy is concerned with Eclipse Foundation project code uploading, downloading, or otherwise connecting from software distributed by the Eclipse Foundation to remote servers/services.

This policy applies for software that:

  • checks for updates;
  • pulls information from servers;
  • provides a heartbeat;
  • gathers usage statistics;
  • gathers data from a user's workstation; or
  • otherwise collects information from user installations.

Private Information

All uploaded information is subject to the terms of the Eclipse Privacy Policy.

Raw data, which may include non-obvious potentially private information, must be transferred securely.

Raw data must be stored securely and access to the data must be strictly controlled. To access the raw data stored on an Eclipse Foundation Server, an individual must be a committer. An individual must sign a non-disclosure agreement (NDA) with The Eclipse Foundation to get access to raw data that may include personally-identifiable information.

Obvious means of identifying a specific individual or organization (e.g. IP address) must not be persisted. Server logs that are accessible only by Eclipse Foundation Webmasters are exempt.

Reasonable effort must be taken to avoid persisting or disseminating information that can inadvertently be used to identify an individual or organization.

Dissemination

Information that can be used to identify individuals or organizations must not be publicly accessible.

Documentation, including a full description of the nature of all information transfered by an upload operation, must be publicly accessible.

The retention policy for publicly accessible data must be documented.

Approval

When it is clear from context that information will be sent and/or received, user- or adopter-initiated operations--for example, a user-initiated build that downloads artifacts from Maven central, or a user-initiated file transfer that sends a file to a remote server via SFTP--are acceptable without formal approval.

Operations that fetch data only (i.e. no data is sent from the user's workstation) from Eclipse Foundation servers--for example, pulling items from a news feed--are acceptable without formal approval. PMC approval is required for a project to implement an operation that fetches data from a third-party source.

Operations that upload data--for example, a list of all currently installed bundles and/or JVM version, or usage patterns--require PMC and EMO(ED) approval. The default configuration must target Eclipse Foundation-managed servers only for uploads. Exceptions to this rule can only be granted by the EMO(ED). Projects can (and should) implement extensible frameworks that permit adopters to upload data to different targets.

Opt-in

Any operation that uploads data must be "opt-in". That is, the user/adopter must agree to participate (agreement may be implicit due to the nature of the service).

If the nature of the data being collected changes, the user/adopter must be informed of the changes and be given the opportunity to explicitly agree to continue participation.

Services that get/pull data only do not require "opt-in". The server components for these services must not attempt to persist any information related to a get/pull data service (server logs, with access restricted to Eclipse Foundation staff only, are exempted from this requirement).

Common Mechanism

Reasonable effort must be undertaken to leverage existing mechanisms rather than create new ones.

FAQ

Does this policy apply to headless software?

Yes.

Do we have to present the user with a dialog box to request "opt-in"?

There are many different means of opting in:

  • A dialog box may be appropriate;
  • opt-in may take the form of a option in a configuration file; or
  • opt-in may be granted by the very nature of the operation (e.g. a menu item that initiates an artifact upload).

The nature of the software itself may imply opt-in. It might, for example, be expected behaviour for machine-to-machine (m2m) component to attempt to discover peers. Simply running this software may be considered opt-in (though this starts to get into gray area and PMC involvement is recommended).