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
