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
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 <ian.skerrett@xxxxxxxxxxx> 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. We couldn’t determine if one IP address was skewing out data or not. If the goal is to provide reports that show overall trends we need to find a better way. This is why we asked for the UUID. However, if the UUID is opt-in then we won’t improve on the existing IP address approach.


And all that from an Open Source organisation?

>> 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.



I believe our users downloading Eclipse deserve more respect. Silently introducing even more user tracking is nothing that I want to be identified with.



Markus

 

On 4 June 2016 at 10:31, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi

This hardly seems last minute at all. My ${user.home}/.eclipse/eclipse.uuid has a

#Tue May 03 08:41:32 BST 2016

timestamp indicating that it was almost certainly created by M7. Why the one month delay in notifying us?

Why no start up dialog in M7 onwards informing us that we are being default opted in?

    Regards

        Ed Willink

On 04/06/2016 06:50, Christian Campo wrote:

hi

 

is that a last minute idea that came up recently or why is it only revealed now that is pretty much too late for any change ?


Gruß

 

Christian


Am 03.06.2016 um 17:13 schrieb Ian Skerrett <ian.skerrett@xxxxxxxxxxx>:

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

-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-------------------------------------------------------------

_______________________________________________
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

 


_______________________________________________
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

 


_______________________________________________
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



Back to the top