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?
Regards
Ed Willink
On 03/06/2016 16:13, Ian Skerrett
wrote:
All,
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 *.eclipse.org 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.
Regards
Ian
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=490112
[2] https://www.eclipse.org/eclipse/news/4.6/platform.php
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=492916
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=492917
[4] https://eclipse.org/legal/privacy.php
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
