Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Jens Reimann]

I didn't want to imply that either, the American or European way is better.
But let's have that beer and discussion anyway ;-)
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Ed Willink]

Thanks

Ed

On 05/06/2016 14:48, Ian Skerrett wrote:


Markus and everyone else,

I hear you and agree we need to remove the UUID in Neon. I will put a 
statement to this effect on the bug you opened. It is obvious there is 
a lot more discussion needed around this issue.


My apologies to Pascal and the Eclipse Platform project for requesting 
the change and for requiring a re-spin of Neon.


Ian




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Christian Campo]

thanks Ian... good move

Gruß

Christian

Am 05.06.2016 um 17:34 schrieb Markus Knauer 
mailto:mkna...@eclipsesource.com>>:

Thank you, Ian, that decision is very much appreciated!

Regards,
Markus


On 5 June 2016 at 15:48, Ian Skerrett 
mailto:ian.skerr...@eclipse.org>> wrote:
Markus and everyone else,

I hear you and agree we need to remove the UUID in Neon. I will put a statement 
to this effect on the bug you opened. It is obvious there is a lot more 
discussion needed around this issue.

My apologies to Pascal and the Eclipse Platform project for requesting the 
change and for requiring a re-spin of Neon.

Ian

From: 
cross-project-issues-dev-boun...@eclipse.org
 
[mailto:cross-project-issues-dev-boun...@eclipse.org]
 On Behalf Of Markus Knauer
Sent: Sunday, June 5, 2016 7:41 AM
To: Cross project issues 
mailto:cross-project-issues-dev@eclipse.org>>
Subject: Re: [cross-project-issues-dev] New UUID in Eclipse Platform

Ian,
you are right in your assumption that all this won't change my opinion in any 
way, in fact, the opposite is true.
The implementation of AERI (the error reporter) and the former EPP Usage Data 
Collector are both opt-in implementations. Both have been carefully designed to 
be as transparent as possible, no user is forced to send any data, there is no 
hidden feature or side-channel, the data is anonymised, and the mail address 
that you were referring to in your response is only optional. AERI has been 
implemented in an open way as it is appropriate for an Open Source community, 
integrated early enough in the release cycle, and based on feedback by and with 
review from the community.
This is clearly a major difference to the way the Eclipse Foundation introduced 
the implementation of the UUID and its use in Platform, p2, MPC, and as a last 
minute change in AERI. (I just want to point out that I am thankful that the 
AERI team pushed on making the UUID introduction public, otherwise some doubts 
are admissible that it would have been communicated at all.)

Yes, you are right, I could live with it if it was an opt-in instead of this 
hidden opt-out. I called it a 'theoretical' opt-out for a number of reasons:
- There is no user interface within Eclipse, no preference page it's just 
nothing. A void.
- The user isn't told about the existence or about the creation of the UUID.
- The user needs to leave the program ("Eclipse") that he or she is using to 
edit an external file.
- And it is an after-the-fact thing. Under normal circumstances the file can 
only be edited after its creation by Eclipse. Kind of a short-circuit.
Rethinking, no, that is not even something that can be called opt-out.

The introduction of such IDs is often justified by possible future 
improvements, but so far I have not seen any plan what to learn from this 
additional information. What is the concrete question that we hope to answer by 
introducing the UUID? If most (closed source) organisations are moving into the 
data-driven decision direction, this is no reason that the (open source) 
Eclipse organisation should move into the same direction. I think we can do 
better!

In Europe (I cannot speak for other areas), there are regulations in place 
regarding e.g. cookies ('devices') and IMO this per-user UUID is no different. 
The European Legislation is very clear about the usage of those IDs - you may 
read (24), (25) of [1]. I have serious doubts that the usage of the UUID which 
is bound to a single user is in accordance with European law, and I guess that 
there is no question that it has to be an opt-in. I hope that Eclipse Legal has 
been involved in its development, and that it did a thorough background check, 
but so far I haven't seen any indication that this has been done.

I strongly believe that this UUID is the worst thing that can happen in an Open 
Source community like Eclipse, and that the Eclipse Foundation looses a lot of 
trust and reputation with this.

Eclipse Neon cannot be released with the current implementations in Platform, 
p2, MPC, and AERI in Neon, there are too many open issues that need to be 
solved before introducing anything like that.

Markus



[1] http://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32002L0058




On 4 June 2016 at 17:11, Ian Skerrett 
mailto:ian.skerr...@eclipse.org>> wrote:
Markus

I think you have captured many of the key concerns so I would like to try to 
respond. I don’t expect to change your opinion but I do believe a response is 
due and hopefully I can express a point of view.

Btw, I am flying to Europe this afternoon so I apologize in advance if I don’t 
respond quickly to this thread.


So late in the release cycle?
>> The initial bug was opened in March and the initial code was available in 
>> M7. Unfortunately I only made cross-projects aware now.

Without any broader involvement of and verification by the Eclipse community

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Markus Knauer]

Thank you, Ian, that decision is very much appreciated!

Regards,
Markus


On 5 June 2016 at 15:48, Ian Skerrett  wrote:

> Markus and everyone else,
>
>
>
> I hear you and agree we need to remove the UUID in Neon. I will put a
> statement to this effect on the bug you opened. It is obvious there is a
> lot more discussion needed around this issue.
>
>
>
> My apologies to Pascal and the Eclipse Platform project for requesting the
> change and for requiring a re-spin of Neon.
>
>
>
> Ian
>
>
>
> *From:* cross-project-issues-dev-boun...@eclipse.org [mailto:
> cross-project-issues-dev-boun...@eclipse.org] *On Behalf Of *Markus Knauer
> *Sent:* Sunday, June 5, 2016 7:41 AM
> *To:* Cross project issues 
> *Subject:* Re: [cross-project-issues-dev] New UUID in Eclipse Platform
>
>
>
> Ian,
>
> you are right in your assumption that all this won't change my opinion in
> any way, in fact, the opposite is true.
>
> The implementation of AERI (the error reporter) and the former EPP Usage
> Data Collector are both opt-in implementations. Both have been carefully
> designed to be as transparent as possible, no user is forced to send any
> data, there is no hidden feature or side-channel, the data is anonymised,
> and the mail address that you were referring to in your response is only
> optional. AERI has been implemented in an open way as it is appropriate for
> an Open Source community, integrated early enough in the release cycle, and
> based on feedback by and with review from the community.
>
> This is clearly a major difference to the way the Eclipse Foundation
> introduced the implementation of the UUID and its use in Platform, p2, MPC,
> and as a last minute change in AERI. (I just want to point out that I am
> thankful that the AERI team pushed on making the UUID introduction public,
> otherwise some doubts are admissible that it would have been communicated
> at all.)
>
>
>
> Yes, you are right, I could live with it if it was an opt-in instead of
> this hidden opt-out. I called it a 'theoretical' opt-out for a number of
> reasons:
>
> - There is no user interface within Eclipse, no preference page it's
> just nothing. A void.
>
> - The user isn't told about the existence or about the creation of the
> UUID.
>
> - The user needs to leave the program ("Eclipse") that he or she is using
> to edit an external file.
>
> - And it is an after-the-fact thing. Under normal circumstances the file
> can only be edited after its creation by Eclipse. Kind of a short-circuit.
>
> Rethinking, no, that is not even something that can be called opt-out.
>
>
>
> The introduction of such IDs is often justified by possible future
> improvements, but so far I have not seen any plan what to learn from this
> additional information. What is the concrete question that we hope to
> answer by introducing the UUID? If most (closed source) organisations are
> moving into the data-driven decision direction, this is no reason that the
> (open source) Eclipse organisation should move into the same direction. I
> think we can do better!
>
>
>
> In Europe (I cannot speak for other areas), there are regulations in place
> regarding e.g. cookies ('devices') and IMO this per-user UUID is no
> different. The European Legislation is very clear about the usage of those
> IDs - you may read (24), (25) of [1]. I have serious doubts that the usage
> of the UUID which is bound to a single user is in accordance with European
> law, and I guess that there is no question that it has to be an opt-in. I
> hope that Eclipse Legal has been involved in its development, and that it
> did a thorough background check, but so far I haven't seen any indication
> that this has been done.
>
> I strongly believe that this UUID is the worst thing that can happen in an
> Open Source community like Eclipse, and that the Eclipse Foundation looses
> a lot of trust and reputation with this.
>
>
> Eclipse Neon cannot be released with the current implementations in
> Platform, p2, MPC, and AERI in Neon, there are too many open issues that
> need to be solved before introducing anything like that.
>
>
>
> Markus
>
>
>
>
> [1] http://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32002L0058
>
>
>
>
>
>
> On 4 June 2016 at 17:11, Ian Skerrett  wrote:
>
> Markus
>
>
>
> I think you have captured many of the key concerns so I would like to try
> to respond. I don’t expect to change your opinion but I do believe a
> response is due and hopefully I can express a point of view.
>
>
>
> Btw, I am flying to Europe this afternoon so I apologize in advance if I
> don’t respond quickly to this thread.
>
>
>
>
>
> So late in the release cycle?
>
> >> The initial bug was opened in March and the initial code was available
> in M7. Unfortunately I only made cross-projects aware now.
>
>
> Without any broader involvement of and verification by the Eclipse
> community? Just an announcement after Neon RC3 (or after Platform RC4)?
>
> >> Point taken.
>
>
> Not as an opt-in like in AERI?
>
>

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Ian Skerrett]

Markus and everyone else,

 

I hear you and agree we need to remove the UUID in Neon. I will put a statement 
to this effect on the bug you opened. It is obvious there is a lot more 
discussion needed around this issue.

 

My apologies to Pascal and the Eclipse Platform project for requesting the 
change and for requiring a re-spin of Neon.

 

Ian

 

From: cross-project-issues-dev-boun...@eclipse.org 
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Markus Knauer
Sent: Sunday, June 5, 2016 7:41 AM
To: Cross project issues 
Subject: Re: [cross-project-issues-dev] New UUID in Eclipse Platform

 

Ian,

you are right in your assumption that all this won't change my opinion in any 
way, in fact, the opposite is true.

The implementation of AERI (the error reporter) and the former EPP Usage Data 
Collector are both opt-in implementations. Both have been carefully designed to 
be as transparent as possible, no user is forced to send any data, there is no 
hidden feature or side-channel, the data is anonymised, and the mail address 
that you were referring to in your response is only optional. AERI has been 
implemented in an open way as it is appropriate for an Open Source community, 
integrated early enough in the release cycle, and based on feedback by and with 
review from the community.

This is clearly a major difference to the way the Eclipse Foundation introduced 
the implementation of the UUID and its use in Platform, p2, MPC, and as a last 
minute change in AERI. (I just want to point out that I am thankful that the 
AERI team pushed on making the UUID introduction public, otherwise some doubts 
are admissible that it would have been communicated at all.)

 

Yes, you are right, I could live with it if it was an opt-in instead of this 
hidden opt-out. I called it a 'theoretical' opt-out for a number of reasons:

- There is no user interface within Eclipse, no preference page it's just 
nothing. A void.

- The user isn't told about the existence or about the creation of the UUID.

- The user needs to leave the program ("Eclipse") that he or she is using to 
edit an external file.

- And it is an after-the-fact thing. Under normal circumstances the file can 
only be edited after its creation by Eclipse. Kind of a short-circuit.

Rethinking, no, that is not even something that can be called opt-out.

 

The introduction of such IDs is often justified by possible future 
improvements, but so far I have not seen any plan what to learn from this 
additional information. What is the concrete question that we hope to answer by 
introducing the UUID? If most (closed source) organisations are moving into the 
data-driven decision direction, this is no reason that the (open source) 
Eclipse organisation should move into the same direction. I think we can do 
better!

 

In Europe (I cannot speak for other areas), there are regulations in place 
regarding e.g. cookies ('devices') and IMO this per-user UUID is no different. 
The European Legislation is very clear about the usage of those IDs - you may 
read (24), (25) of [1]. I have serious doubts that the usage of the UUID which 
is bound to a single user is in accordance with European law, and I guess that 
there is no question that it has to be an opt-in. I hope that Eclipse Legal has 
been involved in its development, and that it did a thorough background check, 
but so far I haven't seen any indication that this has been done.

I strongly believe that this UUID is the worst thing that can happen in an Open 
Source community like Eclipse, and that the Eclipse Foundation looses a lot of 
trust and reputation with this.


Eclipse Neon cannot be released with the current implementations in Platform, 
p2, MPC, and AERI in Neon, there are too many open issues that need to be 
solved before introducing anything like that.

 

Markus




[1] http://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32002L0058






 

On 4 June 2016 at 17:11, Ian Skerrett mailto:ian.skerr...@eclipse.org> > wrote:

Markus

 

I think you have captured many of the key concerns so I would like to try to 
respond. I don’t expect to change your opinion but I do believe a response is 
due and hopefully I can express a point of view.

 

Btw, I am flying to Europe this afternoon so I apologize in advance if I don’t 
respond quickly to this thread.

 

 

So late in the release cycle?

>> The initial bug was opened in March and the initial code was available in 
>> M7. Unfortunately I only made cross-projects aware now. 


Without any broader involvement of and verification by the Eclipse community? 
Just an announcement after Neon RC3 (or after Platform RC4)?

>> Point taken. 


Not as an opt-in like in AERI?

>> If I understand correctly AERI collects email addresses. UUID is not 
>> associated with personable identifiable information.


Without any further notice to the user at all?

>> A notice is in the 4.6 N&N. I can also broadcast to wider channels.


WITHOUT an

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Markus Knauer]

On 5 June 2016 at 11:43, Ed Willink  wrote:

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


I've opend bug 495484

  *Bug 495484*  - Remove
unique user tracking id in Neon
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=495484

to officially ask for removal and re-spin of RC4.


On 5 June 2016 at 13:43, Stephan Herrmann 
wrote:

> Technical question: is disabling UUID s.t. which EPP can do?
>

As far as I can see: No.


Thanks,
Markus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Stephan Herrmann]

This thread is an awesome proof that the Eclipse community is
alive and kicking.

I appreciate Ian taking steps to help the Eclipse community to
stay relevant. And I appreciate most of the concerns expressed
regarding UUID-based data collection. Little to add.

Just looking at this statement:

On 06/04/2016 05:11 PM, Ian Skerrett wrote:

The starting point has been we can use this data to improve the Eclipse 
community.
I hope that if we can start using real facts based on data, not guesses,
this will be a service for the entire community. Most organization are now 
moving
towards data-driven decision making. I think Eclipse should be moving in this 
direction too.


Let me take a radical position for a second: it's not just privacy
in the traditional sense ("spying out my secrets") that's at stake.
People are starting to be concerned also about big business turning
people into data collection devices. Put bluntly: big organizations
decide how they utilize people for producing the information from
which they will generate their profits.

I'd see it as a big loss, if public perception regards Eclipse
as moving towards the big Big Data Business (speaking only of
perception, not intention).
I personally don't think Eclipse should be moving towards
data-driven decision making (which decisions, btw.?).

What are the risks:

- If Neon is rolled out with UUID enabled this will definitely
  send some message to our user community, which certainly is
  not backed by a consensus and will be hard / impossible to
  retract later.

- If UUID is disabled for Neon, our download statistics will
  remain vague (for now).

To me this sounds like a no-brainer: to pull the plug for Neon,
reschedule for Neon.1 under the precondition we achieve some
kind of consensus by then.

Technical question: is disabling UUID s.t. which EPP can do?

cheers,
Stephan

PS: There is this slight hunch about Europeans being more than
average concerned about a lot of things. I don't have the data
to back this observation :) - sounds like a great topic over
more than one beer. But for this thread "Europe vs. America"
is probably not a helpful question, right?

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Markus Knauer]

Ian,

you are right in your assumption that all this won't change my opinion in
any way, in fact, the opposite is true.

The implementation of AERI (the error reporter) and the former EPP Usage
Data Collector are both opt-in implementations. Both have been carefully
designed to be as transparent as possible, no user is forced to send any
data, there is no hidden feature or side-channel, the data is anonymised,
and the mail address that you were referring to in your response is only
optional. AERI has been implemented in an open way as it is appropriate for
an Open Source community, integrated early enough in the release cycle, and
based on feedback by and with review from the community.

This is clearly a major difference to the way the Eclipse Foundation
introduced the implementation of the UUID and its use in Platform, p2, MPC,
and as a last minute change in AERI. (I just want to point out that I am
thankful that the AERI team pushed on making the UUID introduction public,
otherwise some doubts are admissible that it would have been communicated
at all.)

Yes, you are right, I could live with it if it was an opt-in instead of
this hidden opt-out. I called it a 'theoretical' opt-out for a number of
reasons:
- There is no user interface within Eclipse, no preference page it's
just nothing. A void.
- The user isn't told about the existence or about the creation of the UUID.
- The user needs to leave the program ("Eclipse") that he or she is using
to edit an external file.
- And it is an after-the-fact thing. Under normal circumstances the file
can only be edited after its creation by Eclipse. Kind of a short-circuit.
Rethinking, no, that is not even something that can be called opt-out.

The introduction of such IDs is often justified by possible future
improvements, but so far I have not seen any plan what to learn from this
additional information. What is the concrete question that we hope to
answer by introducing the UUID? If most (closed source) organisations are
moving into the data-driven decision direction, this is no reason that the
(open source) Eclipse organisation should move into the same direction. I
think we can do better!

In Europe (I cannot speak for other areas), there are regulations in place
regarding e.g. cookies ('devices') and IMO this per-user UUID is no
different. The European Legislation is very clear about the usage of those
IDs - you may read (24), (25) of [1]. I have serious doubts that the usage
of the UUID which is bound to a single user is in accordance with European
law, and I guess that there is no question that it has to be an opt-in. I
hope that Eclipse Legal has been involved in its development, and that it
did a thorough background check, but so far I haven't seen any indication
that this has been done.

I strongly believe that this UUID is the worst thing that can happen in an
Open Source community like Eclipse, and that the Eclipse Foundation looses
a lot of trust and reputation with this.

Eclipse Neon cannot be released with the current implementations in
Platform, p2, MPC, and AERI in Neon, there are too many open issues that
need to be solved before introducing anything like that.

Markus



[1] http://eur-lex.europa.eu/legal-content/EN/LSU/?uri=CELEX:32002L0058





On 4 June 2016 at 17:11, Ian Skerrett  wrote:

> Markus
>
>
>
> I think you have captured many of the key concerns so I would like to try
> to respond. I don’t expect to change your opinion but I do believe a
> response is due and hopefully I can express a point of view.
>
>
>
> Btw, I am flying to Europe this afternoon so I apologize in advance if I
> don’t respond quickly to this thread.
>
>
>
>
>
> So late in the release cycle?
>
> >> The initial bug was opened in March and the initial code was available
> in M7. Unfortunately I only made cross-projects aware now.
>
>
> Without any broader involvement of and verification by the Eclipse
> community? Just an announcement after Neon RC3 (or after Platform RC4)?
>
> >> Point taken.
>
>
> Not as an opt-in like in AERI?
>
> >> If I understand correctly AERI collects email addresses. UUID is not
> associated with personable identifiable information.
>
>
> Without any further notice to the user at all?
>
> >> A notice is in the 4.6 N&N. I can also broadcast to wider channels.
>
>
> WITHOUT any working opt-out mechanism? Giving the user the theoretical
> chance to edit a file and set a property to '0' cannot be called a valid
> opt-out option.
>
> >> Not sure why you say this is theoretical. We could look at a UI in the
> preferences but my guess is the real concern is the opt-in vs opt-out.
>
> Let me try to explain the opt-out reasoning. Again, I don’t expect to
> change your opinion.
>
> We have been analyzing the log files for p2, mpc and download servers
> using IP addresses. Unfortunately, it is difficult to equate one IP with
> one developer. Some IP addresses represent many developers, some seem to be
> spamming our servers with repetitive calls

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Jens Reimann]

Hi,
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 "heise.de" 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.
Jens 
On Jun 5, 2016 11:43, Ed Willink  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?

    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 

Re: [cross-project-issues-dev] New UUID in Eclipse Platform

[Ed Willink]

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