Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] New UUID in Eclipse Platform


I would like to throw in another argument for postponing the change for a next Eclipse version, giving it a better introduction.

Because I can already image the shitstorm against Eclipse when on "" or "slashdot" people begin to post that "all Eclipse users will be tracked by the NSA".

So from a North American perspective, this may be "not that bad", but from a European perspective this sounds like a nightmare. And it will probably scare away more people in the process than you will ever gain from it.


On Jun 5, 2016 11:43, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi Ian

Reading through the comments on [1], I am surprised. I see enthusiasm only from you, the originator. I see neutral comments from Wayne and scepticism from committers. I see no sign that this was an EF request or has any PMC / AC endorsement. Where is the text of the EF request? Who is the EF in this case? Where is the link to the Architecture Council / Planning Council minutes? Where is the change-barred version of the privacy policy?

The original use case for more accurate counting of installations seems to get confused with p2 / MPC / AERI. AERI already has anonymous ids with opt-in. I see only a very faint benefit in the UUID. What is interesting is the installation not the user; if a bug comes from a user's Mars CDT installation, I don't care whether he/she also has a Luna or BIRT-based installation. The referenced MPC use case[3] is an instruction from you; no motivating requirement.

You conceed that more accurate counting of installations is hard since you cannot avoid multi-counting machines. You ignore the major under-counting of shared zipped download installations behind corporate firewalls.

The specific goal of counting users and per-user installations could be achieved without a UUID at all. It is sufficient to send a registration message to the EF at startup (with a retry on up to ten subsequent starts) containing:-

- time
- stable accessible machine fields (name, MAC, ...)
- build-id, list of third/fourth org.eclipse package names (e.g. ui,core.resources,emf.core,...)
- additional random content

This registration message should be encrypted by a public / private key so that only the EF server application is able to decode it. The server application code could be publicly visible to demonstrate that it is unable to do more than aggregate the registrations. (The random content prevents anyone else using the message or cloning the message generation support code.)

The only persistent information needed is a count of the number of registration retries and success / opt-in preference. The opt-in should be on the initial "where is your workspace" start up dialog with a re-opt-in on the "you need to restart" dialog.

Of course this is all a waste of time because everyone knows that "product registration" just triggers junk communication, so who registers voluntarily? Therefore if you must go for mandatory registration, you must minimize the corrolaries of registration, which the above registration does. It is unconnected with other activities; it is encrypted; it has no re-useable persistent footprint.

What is the process for requesting a respin to have the UUID facility removed pending a more acceptable realization?


        Ed Willink

On 03/06/2016 16:13, Ian Skerrett wrote:


I wanted to make everyone aware that a UUID has been added to the Eclipse Platform [1] and is available in the current Neon RC.  This was done at the request of the Eclipse Foundation.


The UUID is automatically generated and stored in the ${user.home}/.eclipse/eclipse.uuid file. The UUID does not contain any personally identifiable information. If a user do not want to have this property set they are instructed to set eclipse.uuid=0. Information about the UUID has been included in the Eclipse Platform N&N [2].

The UUID will be automatically added to the user-agent of http requests to * servers. For Neon, the projects that make these types of requests include p2 [1], MPC [3] and AERI [4]. I would expect other projects will add a uuid in the future.


The immediate questions for many people are 1) why are we doing this, and 2) what about the privacy concerns.  Let me attempt to answer both of these questions.

Why are we doing this?

The Eclipse Foundation has started an program to better understand our user community. We are using a log file analysis service, Splunk, to analyze many of our log files to get a better idea of how people are using Eclipse. For instance, how many people actively use Eclipse, what version of Java is the most popular with the Eclipse user community, what version of Eclipse Platform is being used or what operating system is being used? In the past, this type of information was typically a ‘best guess’. We believe can do better by having the actual data of our user community. The UUID will allow us to get a more accurate answer to many of these questions.

What about the privacy concerns?

The UUID is anonymous and does not contain personably identifiable information. We only intend to use and analyze the UUID at an aggregate level. A user is able to opt-out of sending a UUID by setting eclipse.uuid=0. The Eclipse Foundation has a published Privacy Policy [5] that details our specific practices.

 Please let me know if you have any questions or concerns. I appreciate this might be a sensitive topic but I do believe it is the right thing to do for the Eclipse community.










cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top