Thank you, Ian, that decision is very much appreciated! Regards, Markus
On 5 June 2016 at 15:48, Ian Skerrett <[email protected]> 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:* [email protected] [mailto: > [email protected]] *On Behalf Of *Markus Knauer > *Sent:* Sunday, June 5, 2016 7:41 AM > *To:* Cross project issues <[email protected]> > *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 <[email protected]> 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 <[email protected]> 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 <[email protected]>: > > 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 > [email protected] > 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 > > [email protected] > > 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 > [email protected] > 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 > [email protected] > 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
