ImageJ 2.0.0-rc-11 released
Locked
12
12
 
|
Hi everyone,
Today the ImageJ team is proud to announce a new public release candidate for ImageJ2: version 2.0.0-rc-11. This release contains several critical bug-fixes as well as new features, including tracking of anonymous usage statistics, as well as Groovy scripting support. For details, see the News post on the ImageJ web site at: http://imagej.net/2014-08-08_-_ImageJ_2.0.0-rc-11_released Cheers, Curtis -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: ImageJ 2.0.0-rc-11 released
|
On Friday 08 Aug 2014 16:47:33 you wrote:
> Today the ImageJ team is proud to announce a new public release candidate > for ImageJ2: version 2.0.0-rc-11. Great to hear the IJ2 has reached rc11. Looking at the New Features page, I think the collection of usage data should be made an OPT IN option and so be set OFF by default. Users might like to exercise some privacy by not being tracked, specially about the "etc." mentioned in that page (?!). Cheers Gabriel -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Hi Gabriel,
> specially about the "etc." mentioned in that page (?!). I wrote this section and left it vague at the time because Curtis Rueden was in the process of refining the database schema and setting up exactly what was tracked. I realize that I should certainly not have used vague language when discussing user privacy though, and apologize for that! The release wiki page is updated to specify exactly what metadata is stored: country, java version, language, operating system, time zone, update site. >I think the collection of usage data should be made an OPT IN option and so be set OFF by default. This was a tough decision for us. We certainly don't want anyone to feel uncomfortable using ImageJ. But we are committed to keeping these statistics anonymous, and this is extremely important information for an open source project. This data will certainly be used to strengthen future funding requests to continue the support of Fiji/ImageJ and its collaborations. So we decided to make it opt out to get as realistic a view of usage as we can, while still allowing anyone who is uncomfortable to disable this functionality. Of course, any further discussion or objections to this feature are welcome... I, personally, would like to better understand any specific concerns people may have. Thanks for the feedback, Mark On Sat, Aug 9, 2014 at 12:44 PM, Gabriel Landini <[hidden email]> wrote: > On Friday 08 Aug 2014 16:47:33 you wrote: > > Today the ImageJ team is proud to announce a new public release candidate > > for ImageJ2: version 2.0.0-rc-11. > > Great to hear the IJ2 has reached rc11. > > Looking at the New Features page, I think the collection of usage data > should > be made an OPT IN option and so be set OFF by default. > > Users might like to exercise some privacy by not being tracked, specially > about the "etc." mentioned in that page (?!). > > Cheers > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by ctrueden
Hi Curtis- I tried to run the update today from within ImageJ2 and got into a loop in the updater where it seemed to be going around in circles for a long time doing the same files over and over. I canceled and downloaded from the web site instead. This was on a Mac running latest Lion. Old version was 2.0.0-rc-2. Dave
On Aug 8, 2014, at 5:47 PM, Curtis Rueden <[hidden email]> wrote: > Hi everyone, > > Today the ImageJ team is proud to announce a new public release candidate > for ImageJ2: version 2.0.0-rc-11. > > This release contains several critical bug-fixes as well as new features, > including tracking of anonymous usage statistics, as well as Groovy > scripting support. > > For details, see the News post on the ImageJ web site at: > http://imagej.net/2014-08-08_-_ImageJ_2.0.0-rc-11_released > > Cheers, > Curtis > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html Dr. David Knecht Professor of Molecular and Cell Biology Core Microscopy Facility Director University of Connecticut Storrs, CT 06269 860-486-2200 -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Mark Hiner-2
Sorry Mark,
but > This data will certainly be used to strengthen future > funding requests to continue the support of Fiji/ImageJ and its > collaborations. this is an unacceptable reason for gathering user data and I fear there is no honest reason at all to do so. > "keeping these statistics anonymous" Well, I'm convinced that you and your co-workers will but... Storing user data is a no no! Some members of the ImageJ-2 Team are criticizing Google an other data collecting organizations since long and now... If user data is gathered/transmitted by IJ-2, I shall, if possible, comment out this portion of code. An OFF-option is insufficient. Just my opinion because you were asking for further comments Herbie :::::::::::::::::::::::::::::::::::: On 11.08.14 16:11, Mark Hiner wrote: > Hi Gabriel, > >> specially about the "etc." mentioned in that page (?!). > > I wrote this section and left it vague at the time because Curtis Rueden > was in the process of refining the database schema and setting up exactly > what was tracked. I realize that I should certainly not have used vague > language when discussing user privacy though, and apologize for that! > > The release wiki page is updated to specify exactly what metadata is > stored: country, java version, language, operating system, time zone, > update site. > >> I think the collection of usage data should be made an OPT IN option and > so be set OFF by default. > > This was a tough decision for us. We certainly don't want anyone to feel > uncomfortable using ImageJ. But we are committed to keeping these > statistics anonymous, and this is extremely important information for an > open source project. This data will certainly be used to strengthen future > funding requests to continue the support of Fiji/ImageJ and its > collaborations. > > So we decided to make it opt out to get as realistic a view of usage as we > can, while still allowing anyone who is uncomfortable to disable this > functionality. > > Of course, any further discussion or objections to this feature are > welcome... I, personally, would like to better understand any specific > concerns people may have. > > Thanks for the feedback, > Mark > > On Sat, Aug 9, 2014 at 12:44 PM, Gabriel Landini <[hidden email]> > wrote: > >> On Friday 08 Aug 2014 16:47:33 you wrote: >>> Today the ImageJ team is proud to announce a new public release candidate >>> for ImageJ2: version 2.0.0-rc-11. >> >> Great to hear the IJ2 has reached rc11. >> >> Looking at the New Features page, I think the collection of usage data >> should >> be made an OPT IN option and so be set OFF by default. >> >> Users might like to exercise some privacy by not being tracked, specially >> about the "etc." mentioned in that page (?!). >> >> Cheers >> >> Gabriel >> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >> > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: ImageJ 2.0.0-rc-11 released
|
|
In reply to this post by Mark Hiner-2
On Monday 11 Aug 2014 09:11:37 Mark Hiner wrote:
> I wrote: > >I think the collection of usage data should be made an OPT IN option and > > so be set OFF by default. > This was a tough decision for us. We certainly don't want anyone to feel > uncomfortable using ImageJ. Good, so please use this as an opportunity to change the way the program gets user permission to do it. If this happens to be something people want to adhere to, then there is nothing to worry about as there will be lots of users opting in when given the chance. But at the moment this is essentially forcing everybody to tell what they are doing with IJ in their machines without asking. > But we are committed to keeping these statistics anonymous, and this > is extremely important information for an open source project. > This data will certainly be used to strengthen future > funding requests to continue the support of Fiji/ImageJ and its > collaborations. Logging updates and downloads is one thing that could be quoted when applying for funding (after all you need to contact the server to do that), but logging plugin usage statistics in individual computers (i.e. what you do with the software?) without user agreeing seems intrusive and over the top. > So we decided to make it opt out to get as realistic a view of usage as we > can, while still allowing anyone who is uncomfortable to disable this > functionality. SCIFIO was opt in, but usage tracking is opt out? It does not make sense. Given privacy (or the lack of...) is such a hot topic at the moment it would seem appropriate to do things right. Regards Gabriel PS: Incidentally I also found that there seems to be no way of recording in the macro language the Privacy Opt Out option. Can this be added too so it can be included in the StartupMacros file? That way I can have the same setup everywhere by transferring that file. Thanks. -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Herbie-4
Hi Herbie,
>If user data is gathered/transmitted by IJ-2, I shall, if possible, comment out this portion of code. An OFF-option is insufficient. Can you explain why an OFF option is insufficient..? Anyway, like everything in the ImageJ-2 framework, usage uploads come from a Service <https://github.com/scijava/scijava-common/blob/master/src/main/java/org/scijava/service/Service.java> plugin providing the indicated functionality - in this case, the UsageUploadService <https://github.com/imagej/imagej-usage/blob/master/src/main/java/net/imagej/usage/UsageUploadService.java> . All services can be overridden by creating another implementation with a higher priority - for usage statistics, you can use the default implementation <https://github.com/imagej/imagej-usage/blob/master/src/main/java/net/imagej/usage/DefaultUsageUploadService.java> as a guide. You could even distribute your disabled usage service on an update site <http://fiji.sc/How_to_set_up_and_populate_an_update_site>, to share with other users. > this is an unacceptable reason for gathering user data and I fear there is no honest reason at all to do so. I personally do not write grants, but I am funded by them (along with the rest of my coworkers). It is not enough to say "hey we're going to make the next generation ImageJ framework... thanks for the money bye!" We need the ability to measure and report our successes and failures, and use that information to guide future funding and development priorities. Please consider that some level of usage statistics for Fiji have been collected for nearly 5 years already <http://imagej.net/Fiji_Usage>. These latest changes are just more granular, allowing us to track individual plugins and update site use. >Storing user data is a no no! Agreed completely. I would not call what we are tracking "user data." We are tracking "plugin data", and we are really just tracking plugin use counts for a given environment. So, I don't understand how honesty comes into the picture... perhaps you could explain your feelings here? How do you think this data could be misused? Thanks for the response, Mark On Mon, Aug 11, 2014 at 11:00 AM, Herbie <[hidden email]> wrote: > Sorry Mark, > > but > > > > This data will certainly be used to strengthen future > > funding requests to continue the support of Fiji/ImageJ and its > > collaborations. > > this is an unacceptable reason for gathering user data and I fear there is > no honest reason at all to do so. > > > "keeping these statistics anonymous" > > Well, I'm convinced that you and your co-workers will but... > > Storing user data is a no no! > Some members of the ImageJ-2 Team are criticizing Google an other data > collecting organizations since long and now... > > If user data is gathered/transmitted by IJ-2, I shall, if possible, > comment out this portion of code. An OFF-option is insufficient. > > Just my opinion because you were asking for further comments > > Herbie > > :::::::::::::::::::::::::::::::::::: > > On 11.08.14 16:11, Mark Hiner wrote: > >> Hi Gabriel, >> >> specially about the "etc." mentioned in that page (?!). >>> >> >> I wrote this section and left it vague at the time because Curtis Rueden >> was in the process of refining the database schema and setting up exactly >> what was tracked. I realize that I should certainly not have used vague >> language when discussing user privacy though, and apologize for that! >> >> The release wiki page is updated to specify exactly what metadata is >> stored: country, java version, language, operating system, time zone, >> update site. >> >> I think the collection of usage data should be made an OPT IN option and >>> >> so be set OFF by default. >> >> This was a tough decision for us. We certainly don't want anyone to feel >> uncomfortable using ImageJ. But we are committed to keeping these >> statistics anonymous, and this is extremely important information for an >> open source project. This data will certainly be used to strengthen future >> funding requests to continue the support of Fiji/ImageJ and its >> collaborations. >> >> So we decided to make it opt out to get as realistic a view of usage as we >> can, while still allowing anyone who is uncomfortable to disable this >> functionality. >> >> Of course, any further discussion or objections to this feature are >> welcome... I, personally, would like to better understand any specific >> concerns people may have. >> >> Thanks for the feedback, >> Mark >> >> On Sat, Aug 9, 2014 at 12:44 PM, Gabriel Landini <[hidden email]> >> wrote: >> >> On Friday 08 Aug 2014 16:47:33 you wrote: >>> >>>> Today the ImageJ team is proud to announce a new public release >>>> candidate >>>> for ImageJ2: version 2.0.0-rc-11. >>>> >>> >>> Great to hear the IJ2 has reached rc11. >>> >>> Looking at the New Features page, I think the collection of usage data >>> should >>> be made an OPT IN option and so be set OFF by default. >>> >>> Users might like to exercise some privacy by not being tracked, specially >>> about the "etc." mentioned in that page (?!). >>> >>> Cheers >>> >>> Gabriel >>> >>> -- >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >>> >>> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html >> >> > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
Good day Mark,
and thanks for your message! On 11.08.14 18:51, Mark Hiner wrote: > Hi Herbie, > > If user data is gathered/transmitted by IJ-2, I shall, if possible, > comment out this portion of code. An OFF-option is insufficient. > > Can you explain why an OFF option is insufficient..? It can _easily_ be manipulated. We are dealing with Open Source and who can prevent someone to compile and distribute an IJ-2 version where the options are just reversed. This is one possible scenario. In fact you can always distribute manipulated IJ-2 versions but the described method is extremely easy to realize... > Anyway, like everything in the ImageJ-2 framework, usage uploads come > from a Service > <https://github.com/scijava/scijava-common/blob/master/src/main/java/org/scijava/service/Service.java> > plugin providing the indicated functionality - in this case, the > UsageUploadService > <https://github.com/imagej/imagej-usage/blob/master/src/main/java/net/imagej/usage/UsageUploadService.java>. Are you sure users check the exact sever? Here in Germany we are presently confronted with sophisticated SPAM (with attachments) from highjacked official servers (Courts, State administrations etc.) > All services can be overridden by creating another implementation with a > higher priority - for usage statistics, you can use the default > implementation < > https://github.com/imagej/imagej-usage/blob/master/src/main/java/net/imagej/usage/DefaultUsageUploadService.java> > as a guide. You could even distribute your disabled usage service on an > update site <http://fiji.sc/How_to_set_up_and_populate_an_update_site>, > to share with other users. One should do that in general. An individual code change means the last resort (for me). > this is an unacceptable reason for gathering user data and I fear > there is no honest reason at all to do so. > > I personally do not write grants, but I am funded by them (along with > the rest of my coworkers). It is not enough to say "hey we're going to > make the next generation ImageJ framework... thanks for the money bye!" > We need the ability to measure and report our successes and failures, > and use that information to guide future funding and development priorities. I've been 40 years in science and research and I had never to provide comparable information and if somebody had asked me to, I had refused the request or the project. How comes that Wayne was funded? Why not use the number of members on the IJ-list? It gives an estimate about a factor of 2...5 below the real number of IJ-users. > Please consider that some level of usage statistics for Fiji have been > collected for nearly 5 years already <http://imagej.net/Fiji_Usage>. > These latest changes are just more granular, allowing us to track > individual plugins and update site use. This is one of many reasons that I don't use Fiji. > >Storing user data is a no no! > > Agreed completely. I would not call what we are tracking "user data." We > are tracking "plugin data", and we are really just tracking plugin use > counts for a given environment. Oh well, the kind of computers, software, or whatever I use, is my private affair. > So, I don't understand how honesty comes into the picture... perhaps you > could explain your feelings here? How do you think this data could be > misused? I wrote with respect to gathering user data: "there is no honest reason at all to do so" The reason for this is that my data (including my computer platform, the software I use etc.) is private, except I decide to make it available for someone or a group. Collecting information from my personal computer isn't honest. If others do it is no reason to do it too. > Thanks for the response, > Mark Thank you for asking and have a good day Herbie :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > On Mon, Aug 11, 2014 at 11:00 AM, Herbie <[hidden email] > <mailto:[hidden email]>> wrote: > > Sorry Mark, > > but > > > > This data will certainly be used to strengthen future > > funding requests to continue the support of Fiji/ImageJ and its > > collaborations. > > this is an unacceptable reason for gathering user data and I fear > there is no honest reason at all to do so. > > > "keeping these statistics anonymous" > > Well, I'm convinced that you and your co-workers will but... > > Storing user data is a no no! > Some members of the ImageJ-2 Team are criticizing Google an other > data collecting organizations since long and now... > > If user data is gathered/transmitted by IJ-2, I shall, if possible, > comment out this portion of code. An OFF-option is insufficient. > > Just my opinion because you were asking for further comments > > Herbie > > ::::::::::::::::::::::::::::::__:::::: > > On 11.08.14 16:11, Mark Hiner wrote: > > Hi Gabriel, > > specially about the "etc." mentioned in that page (?!). > > > I wrote this section and left it vague at the time because > Curtis Rueden > was in the process of refining the database schema and setting > up exactly > what was tracked. I realize that I should certainly not have > used vague > language when discussing user privacy though, and apologize for > that! > > The release wiki page is updated to specify exactly what metadata is > stored: country, java version, language, operating system, time > zone, > update site. > > I think the collection of usage data should be made an OPT > IN option and > > so be set OFF by default. > > This was a tough decision for us. We certainly don't want anyone > to feel > uncomfortable using ImageJ. But we are committed to keeping these > statistics anonymous, and this is extremely important > information for an > open source project. This data will certainly be used to > strengthen future > funding requests to continue the support of Fiji/ImageJ and its > collaborations. > > So we decided to make it opt out to get as realistic a view of > usage as we > can, while still allowing anyone who is uncomfortable to disable > this > functionality. > > Of course, any further discussion or objections to this feature are > welcome... I, personally, would like to better understand any > specific > concerns people may have. > > Thanks for the feedback, > Mark > > On Sat, Aug 9, 2014 at 12:44 PM, Gabriel Landini > <[hidden email] <mailto:[hidden email]>> > wrote: > > On Friday 08 Aug 2014 16:47:33 you wrote: > > Today the ImageJ team is proud to announce a new public > release candidate > for ImageJ2: version 2.0.0-rc-11. > > > Great to hear the IJ2 has reached rc11. > > Looking at the New Features page, I think the collection of > usage data > should > be made an OPT IN option and so be set OFF by default. > > Users might like to exercise some privacy by not being > tracked, specially > about the "etc." mentioned in that page (?!). > > Cheers > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.__html > <http://imagej.nih.gov/ij/list.html> > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.__html > <http://imagej.nih.gov/ij/list.html> > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.__html > <http://imagej.nih.gov/ij/list.html> > > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Gabriel Landini
> SCIFIO was opt in, but usage tracking is opt out? It does not make sense.
> To be clear, SCIFIO is enabled by default.. you have to uncheck a box to disable SCIFIO, so it is opt out. We publicized the SCIFIO toggle from within the ImageJ UI because it can affect the actual operation of ImageJ by producing different (and/or incorrect) results (and it's a beta product which is being consumed by a complicated compatibility layer to interact with ImageJ 1.x classes). >but logging plugin usage statistics in individual computers (i.e. what you do with the software?) without user agreeing seems intrusive and over the top. I think there is a difference in the questions "what do you do with the software" and "what do users do with the software". I don't believe we will ever ask the former question. With the way our database was designed, literally just storing plugin execution counts (and not parameters) we can ask: "How many times was Bio-Formats used with Java 7"? we *can not* ask: "how many times did Gabriel Landini run Bio-Formats?" >Logging updates and downloads is one thing that could be quoted when applying for funding This value of this information is questionable. If this was just the core imagej.jar that's probably sufficient. But we're talking about a significant number of components that make up Fiji, made potentially endless via update sites and plugins. Downloads and updates just don't tell you the whole picture. Using Bio-Formats as an example: Bio-Formats 5.0.2 currently ships with Fiji. But I can't say that the number of downloads of Fiji represent use of Bio-Formats by the scientific imaging community. I can't say the number of times a Bio-Formats .jar is updated via the Fiji updater is representative of use either. Those numbers aren't bad, but they don't really mean anything. But now, with usage statistics, we can look at the number of times the Bio-Formats importer was used, or File > Open with SCIFIO and the Bio-Formats plugin was used. This at least gives us an approximate picture of how our software is being used. >If this happens to be something people want to adhere to, then there is nothing to worry about as there will be lots of users opting in when given the chance. I believe this is actually hard to predict. We put in what we thought was an appropriate system of warnings and explanations for when and how to disable SCIFIO, for example, and failed miserably - resulting in a frustration and confusion for users and a wonderful spike in bug reporting. If usage statistics were presented similarly - with a pop up on launch and an options menu - my expectations for opt-in numbers would be very low. Not because people don't want to contribute but because we created a barrier to the process. A more successful alternative might be, when statistics are actually being uploaded, to display a dialog asking to proceed or not - with yes/no/don't ask me again options. That sounds promising, but also potentially annoying or confusing to get that pop up, and we can still expect statistics reporting to drop. So since we are not sending or storing use-specific data, and provided and publicized the opt-out mechanism, we decided to go with the option that was un-disruptive at the workflow level and maximized data collection. Especially given, as you mentioned, that users ultimately need to agree to communicate with an external server to download these applications and updates. >Good, so please use this as an opportunity to change the way the program gets user permission to do it. I hope it's clear that I am not saying we are unwilling to change how permissions are exposed.. but if we can circumvent that need via discussion it would certainly be my preference. And if we do end up making any changes, I would like them to be as minimally damaging to the quality of the data gathering as possible. >Given privacy (or the lack of...) is such a hot topic at the moment it would seem appropriate to do things right. From what I know of privacy issues, these are primarily concerning the leaking of things like e-mails, passwords, usernames or credit card numbers. As we are only storing numeric counts tied to plugin names and the previously-mentioned information, there is nothing to leak. To me, there has to be actual user data being exposed to be a matter of privacy. Can you clarify what you believe to be the concern here? >Incidentally I also found that there seems to be no way of recording in the macro language the Privacy Opt Out option. Can this be added too so it can be included in the StartupMacros file? Would you mind opening an issue on the imagej-usage github page: https://github.com/imagej/imagej-usage/issues ? I hope this helped clarify our thought process and reasoning a bit. Thanks, Mark -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Knecht, David
Hi David,
> it seemed to be going around in circles for a long time doing the same files over and over There was a breaking point in the updater some time ago where this was happening. I think the instructions for fixing it are in comment 10 if this bug report: http://fiji.sc/bugzilla/show_bug.cgi?id=763#c10 You should be able to resolve this from the command line by reading through those comments and following the steps. If you're not attached to anything in your local install, you can also download a fresh version from http://fiji.sc/Downloads, as the bug was eventually resolved. Let us know if you have any trouble though! - Mark On Mon, Aug 11, 2014 at 10:42 AM, Knecht, David <[hidden email]> wrote: > Hi Curtis- I tried to run the update today from within ImageJ2 and got > into a loop in the updater where it seemed to be going around in circles > for a long time doing the same files over and over. I canceled and > downloaded from the web site instead. This was on a Mac running latest > Lion. Old version was 2.0.0-rc-2. Dave > > On Aug 8, 2014, at 5:47 PM, Curtis Rueden <[hidden email]> wrote: > > > Hi everyone, > > > > Today the ImageJ team is proud to announce a new public release candidate > > for ImageJ2: version 2.0.0-rc-11. > > > > This release contains several critical bug-fixes as well as new features, > > including tracking of anonymous usage statistics, as well as Groovy > > scripting support. > > > > For details, see the News post on the ImageJ web site at: > > http://imagej.net/2014-08-08_-_ImageJ_2.0.0-rc-11_released > > > > Cheers, > > Curtis > > > > -- > > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > Dr. David Knecht > Professor of Molecular and Cell Biology > Core Microscopy Facility Director > University of Connecticut > Storrs, CT 06269 > 860-486-2200 > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Herbie-4
>
> It can _easily_ be manipulated. > We are dealing with Open Source and who can prevent someone to compile and > distribute an IJ-2 version where the options are just reversed > I agree completely but do not see that as an argument against this functionality. In the scenario you describe, a user needs to choose to download some malicious code - correct? But there is already the window for that by nature of having a plugin mechanism in ImageJ. >Are you sure users check the exact sever? I'm sorry, I'm not sure what you mean... >How comes that Wayne was funded? I know nothing about the details of ImageJ 1.x funding. Info about ImageJ2 funding is on the wiki <http://imagej.net/ImageJ2#Funding>, but I apologize if I conflated the issue by mentioning our funding. To be clear, this is a framework that automatically is useful for any plugin developer - not just the ImageJ2 team. I was using the ImageJ2 grant as an example to illustrate that funding is a non-trivial area where it is useful to be able to report usage statistics like those we are gathering... so there was genuine purpose behind our actions. >Why not use the number of members on the IJ-list? Answered this question in my response to Gabriel's last message - numbers like this aren't really granular enough to be meaningful to plugin developers. Also, these numbers are important for considering future development - e.g. if a plugin hasn't been used in over 2 years, should we really put time and effort into converting it to a new format? IJ subscriber data just can't inform a decision like that.... >Oh well, the kind of computers, software, or whatever I use, is my private affair. If you download an application or plugin from a server, it seems reasonable to expect that there would be some record of that event: "there exists a person who downloaded an application from this server." The usage statistics being uploaded are no more detailed than this, saying "there exists a person who ran this plugin 10 times using Java 7 on Windows". To me, that seems less personal than sending an e-mail to this list. I do believe that the information "Herbie ran plugin X" is your private affair, as is "A person ran plugin X on dataset_243.tif". But the information "someone ran plugin X" does not seem like it's violating anyone's privacy to me. If you feel differently, please help me to understand why. If you will indulge a metaphor, from my point of view, our usage statistics are like having data that says "A person wore a t-shirt and glasses on August 11th." That data is meaningless unless you are curious about t-shirt and glasses annual trends - and even then, you have no way to trace back the actions of a specific individual. I believe a violation of privacy would be "Mark Hiner is wearing a t-shirt and glasses on August 11th" - and we will not transmit or store that data. Thanks, Mark On Mon, Aug 11, 2014 at 1:22 PM, Herbie <[hidden email]> wrote: > Good day Mark, > > and thanks for your message! > > On 11.08.14 18:51, Mark Hiner wrote: > >> Hi Herbie, >> >> If user data is gathered/transmitted by IJ-2, I shall, if possible, >> comment out this portion of code. An OFF-option is insufficient. >> >> Can you explain why an OFF option is insufficient..? >> > > It can _easily_ be manipulated. > We are dealing with Open Source and who can prevent someone to compile and > distribute an IJ-2 version where the options are just reversed. This is one > possible scenario. > In fact you can always distribute manipulated IJ-2 versions but the > described method is extremely easy to realize... > > Anyway, like everything in the ImageJ-2 framework, usage uploads come >> from a Service >> <https://github.com/scijava/scijava-common/blob/master/ >> src/main/java/org/scijava/service/Service.java> >> >> plugin providing the indicated functionality - in this case, the >> UsageUploadService >> <https://github.com/imagej/imagej-usage/blob/master/src/ >> main/java/net/imagej/usage/UsageUploadService.java>. >> > > Are you sure users check the exact sever? > Here in Germany we are presently confronted with sophisticated SPAM (with > attachments) from highjacked official servers (Courts, State > administrations etc.) > > All services can be overridden by creating another implementation with a >> higher priority - for usage statistics, you can use the default >> implementation < >> https://github.com/imagej/imagej-usage/blob/master/src/ >> main/java/net/imagej/usage/DefaultUsageUploadService.java> >> >> as a guide. You could even distribute your disabled usage service on an >> update site <http://fiji.sc/How_to_set_up_and_populate_an_update_site>, >> >> to share with other users. >> > > One should do that in general. > An individual code change means the last resort (for me). > > this is an unacceptable reason for gathering user data and I fear >> there is no honest reason at all to do so. >> >> I personally do not write grants, but I am funded by them (along with >> the rest of my coworkers). It is not enough to say "hey we're going to >> make the next generation ImageJ framework... thanks for the money bye!" >> We need the ability to measure and report our successes and failures, >> and use that information to guide future funding and development >> priorities. >> > > I've been 40 years in science and research and I had never to provide > comparable information and if somebody had asked me to, I had refused the > request or the project. > > How comes that Wayne was funded? > > Why not use the number of members on the IJ-list? > It gives an estimate about a factor of 2...5 below the real number of > IJ-users. > > Please consider that some level of usage statistics for Fiji have been >> collected for nearly 5 years already <http://imagej.net/Fiji_Usage>. >> >> These latest changes are just more granular, allowing us to track >> individual plugins and update site use. >> > > This is one of many reasons that I don't use Fiji. > > >Storing user data is a no no! >> >> Agreed completely. I would not call what we are tracking "user data." We >> are tracking "plugin data", and we are really just tracking plugin use >> counts for a given environment. >> > > Oh well, the kind of computers, software, or whatever I use, is my private > affair. > > So, I don't understand how honesty comes into the picture... perhaps you >> could explain your feelings here? How do you think this data could be >> misused? >> > > I wrote with respect to gathering user data: > "there is no honest reason at all to do so" > > The reason for this is that my data (including my computer platform, the > software I use etc.) is private, except I decide to make it available for > someone or a group. > > Collecting information from my personal computer isn't honest. > If others do it is no reason to do it too. > > Thanks for the response, >> Mark >> > > Thank you for asking and have a good day > > Herbie > > :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: > >> On Mon, Aug 11, 2014 at 11:00 AM, Herbie <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> Sorry Mark, >> >> but >> >> >> > This data will certainly be used to strengthen future >> > funding requests to continue the support of Fiji/ImageJ and its >> > collaborations. >> >> this is an unacceptable reason for gathering user data and I fear >> there is no honest reason at all to do so. >> >> > "keeping these statistics anonymous" >> >> Well, I'm convinced that you and your co-workers will but... >> >> Storing user data is a no no! >> Some members of the ImageJ-2 Team are criticizing Google an other >> data collecting organizations since long and now... >> >> If user data is gathered/transmitted by IJ-2, I shall, if possible, >> comment out this portion of code. An OFF-option is insufficient. >> >> Just my opinion because you were asking for further comments >> >> Herbie >> >> ::::::::::::::::::::::::::::::__:::::: >> >> >> On 11.08.14 16:11, Mark Hiner wrote: >> >> Hi Gabriel, >> >> specially about the "etc." mentioned in that page (?!). >> >> >> I wrote this section and left it vague at the time because >> Curtis Rueden >> was in the process of refining the database schema and setting >> up exactly >> what was tracked. I realize that I should certainly not have >> used vague >> language when discussing user privacy though, and apologize for >> that! >> >> The release wiki page is updated to specify exactly what metadata >> is >> stored: country, java version, language, operating system, time >> zone, >> update site. >> >> I think the collection of usage data should be made an OPT >> IN option and >> >> so be set OFF by default. >> >> This was a tough decision for us. We certainly don't want anyone >> to feel >> uncomfortable using ImageJ. But we are committed to keeping these >> statistics anonymous, and this is extremely important >> information for an >> open source project. This data will certainly be used to >> strengthen future >> funding requests to continue the support of Fiji/ImageJ and its >> collaborations. >> >> So we decided to make it opt out to get as realistic a view of >> usage as we >> can, while still allowing anyone who is uncomfortable to disable >> this >> functionality. >> >> Of course, any further discussion or objections to this feature >> are >> welcome... I, personally, would like to better understand any >> specific >> concerns people may have. >> >> Thanks for the feedback, >> Mark >> >> On Sat, Aug 9, 2014 at 12:44 PM, Gabriel Landini >> <[hidden email] <mailto:[hidden email]>> >> >> wrote: >> >> On Friday 08 Aug 2014 16:47:33 you wrote: >> >> Today the ImageJ team is proud to announce a new public >> release candidate >> for ImageJ2: version 2.0.0-rc-11. >> >> >> Great to hear the IJ2 has reached rc11. >> >> Looking at the New Features page, I think the collection of >> usage data >> should >> be made an OPT IN option and so be set OFF by default. >> >> Users might like to exercise some privacy by not being >> tracked, specially >> about the "etc." mentioned in that page (?!). >> >> Cheers >> >> Gabriel >> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.__html >> <http://imagej.nih.gov/ij/list.html> >> >> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.__html >> <http://imagej.nih.gov/ij/list.html> >> >> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.__html >> <http://imagej.nih.gov/ij/list.html> >> >> >> > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: ImageJ 2.0.0-rc-11 released
|
|
In reply to this post by Mark Hiner-2
On Monday 11 Aug 2014 14:18:11 Mark Hiner wrote:
> > SCIFIO was opt in, but usage tracking is opt out? It does not make sense. > > To be clear, SCIFIO is enabled by default.. you have to uncheck a box to > disable SCIFIO, so it is opt out. Right, but it was impossible to miss as I had to answer the SCIFIO dialog when the update came. What is the problem in showing a similar dialog and let people know what will be going on? > I think there is a difference in the questions "what do you do with the > software" and "what do users do with the software". I don't believe we will > ever ask the former question. Mark, what you or me personally *believe* somebody will ask in the future does not matter. It is the process of getting informed consent on the data collection; IJ2 is assuming and makes it less obvious than it could be. > we can ask: > "How many times was Bio-Formats used with Java 7"? > we *can not* ask: > "how many times did Gabriel Landini run Bio-Formats?" Even with my poor knowledge of network traffic I can imagine that it might trivial to script something using time stamps and ip addresses of the uploading machine as well as plenty of emails also ip addresses from users. Not that I remotely think that the devel team would have the time or inclination to do this, but if we are talking about what is impossible, I suspect it is not. So whether that is potentially identifiable information is probably debatable. If there is then you would be effectively logging in a database their location every hour (!) IJ2 runs. Doesn't that sound a bit creepy? My issue was (and remains) that data collection needs to be fully informed before it takes place, not to be On by default. > >If this happens to be something people want to adhere to, then there is > > nothing to worry about as there will be lots of users opting in when given > > the chance. > I believe this is actually hard to predict. Ask the users in a similar way SCIFIO was done and you will have the answer. Then we would not be having this conversation. > If usage statistics were presented similarly - with a pop up on launch and > an options menu - my expectations for opt-in numbers would be very low. Not > because people don't want to contribute but because we created a barrier to > the process. The issue that does not seem to stick after all this typing is that IJ2 should not make that decision for the users. IJ2 is not the owner of the processes happening in a user's computer. You need to ask, not assume, that people will be happy for their computers to contact a database every hour and letting it know they are there and doing this or that. > A more successful alternative might be, when statistics are actually being > uploaded, to display a dialog asking to proceed or not - with yes/no/don't > ask me again options. That sounds promising, but also potentially annoying > or confusing to get that pop up, and we can still expect statistics > reporting to drop. But if the reporting statistics drop, that would have to do. Make estimates instead of collecting all possible data. > So since we are not sending or storing use-specific data, and provided and > publicized the opt-out mechanism, we decided to go with the option that was > un-disruptive at the workflow level and maximized data collection. Yes, you said that before, and I am sure I am not alone thinking it is not the desirable way of doing it. > Especially given, as you mentioned, that users ultimately need to agree to > communicate with an external server to download these applications and > updates. But there is an obvious difference between the two situations. One is requesting an update. The other is broadcasting to a database. > I hope it's clear that I am not saying we are unwilling to change how > permissions are exposed.. but if we can circumvent that need via discussion > it would certainly be my preference. And if we do end up making any > changes, I would like them to be as minimally damaging to the quality of > the data gathering as possible. I sounds like it is preferable not to ask people about the data collection. That is in my view an error of judgement that can be resolved easily. > To me, there has to be actual user data being exposed to be a matter of > privacy. Can you clarify what you believe to be the concern here? Sure: that the process of collecting usage data is not made clear from the beginning and it should have informed consent before the collection starts. If there are no privacy issues, why is the function to switch it Off called "Privacy"? Regards Gabriel -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: ImageJ 2.0.0-rc-11 released
|
|
In reply to this post by Mark Hiner-2
Mark,
In order to win and retain users of Image2, you have to earn their confidence. Spying on them and arguing with them are not ways to do that. The features of the program have to be designed to meet their needs, not yours. One of the many beauties of ImageJ is the it does not come with strings attached. No cost. No usage restrictions. No bizarre copyleft. And certainly no spying. Bob Sent from my iPhone On Aug 11, 2014, at 4:25 PM, Mark Hiner <[hidden email]> wrote: >> >> It can _easily_ be manipulated. >> We are dealing with Open Source and who can prevent someone to compile and >> distribute an IJ-2 version where the options are just reversed > > I agree completely but do not see that as an argument against this > functionality. In the scenario you describe, a user needs to choose to > download some malicious code - correct? But there is already the window for > that by nature of having a plugin mechanism in ImageJ. > >> Are you sure users check the exact sever? > > I'm sorry, I'm not sure what you mean... > >> How comes that Wayne was funded? > > I know nothing about the details of ImageJ 1.x funding. Info about ImageJ2 > funding is on the wiki <http://imagej.net/ImageJ2#Funding>, but I apologize > if I conflated the issue by mentioning our funding. To be clear, this is a > framework that automatically is useful for any plugin developer - not just > the ImageJ2 team. I was using the ImageJ2 grant as an example to illustrate > that funding is a non-trivial area where it is useful to be able to report > usage statistics like those we are gathering... so there was genuine > purpose behind our actions. > >> Why not use the number of members on the IJ-list? > > Answered this question in my response to Gabriel's last message - numbers > like this aren't really granular enough to be meaningful to plugin > developers. Also, these numbers are important for considering future > development - e.g. if a plugin hasn't been used in over 2 years, should we > really put time and effort into converting it to a new format? IJ > subscriber data just can't inform a decision like that.... > >> Oh well, the kind of computers, software, or whatever I use, is my private > affair. > > If you download an application or plugin from a server, it seems reasonable > to expect that there would be some record of that event: "there exists a > person who downloaded an application from this server." The usage > statistics being uploaded are no more detailed than this, saying "there > exists a person who ran this plugin 10 times using Java 7 on Windows". To > me, that seems less personal than sending an e-mail to this list. > > I do believe that the information "Herbie ran plugin X" is your private > affair, as is "A person ran plugin X on dataset_243.tif". But the > information "someone ran plugin X" does not seem like it's violating > anyone's privacy to me. If you feel differently, please help me to > understand why. > > If you will indulge a metaphor, from my point of view, our usage statistics > are like having data that says "A person wore a t-shirt and glasses on > August 11th." That data is meaningless unless you are curious about t-shirt > and glasses annual trends - and even then, you have no way to trace back > the actions of a specific individual. > > I believe a violation of privacy would be "Mark Hiner is wearing a t-shirt > and glasses on August 11th" - and we will not transmit or store that data. > > Thanks, > Mark > > >> On Mon, Aug 11, 2014 at 1:22 PM, Herbie <[hidden email]> wrote: >> >> Good day Mark, >> >> and thanks for your message! >> >>> On 11.08.14 18:51, Mark Hiner wrote: >>> >>> Hi Herbie, >>> >>> If user data is gathered/transmitted by IJ-2, I shall, if possible, >>> comment out this portion of code. An OFF-option is insufficient. >>> >>> Can you explain why an OFF option is insufficient..? >> >> It can _easily_ be manipulated. >> We are dealing with Open Source and who can prevent someone to compile and >> distribute an IJ-2 version where the options are just reversed. This is one >> possible scenario. >> In fact you can always distribute manipulated IJ-2 versions but the >> described method is extremely easy to realize... >> >> Anyway, like everything in the ImageJ-2 framework, usage uploads come >>> from a Service >>> <https://github.com/scijava/scijava-common/blob/master/ >>> src/main/java/org/scijava/service/Service.java> >>> >>> plugin providing the indicated functionality - in this case, the >>> UsageUploadService >>> <https://github.com/imagej/imagej-usage/blob/master/src/ >>> main/java/net/imagej/usage/UsageUploadService.java>. >> >> Are you sure users check the exact sever? >> Here in Germany we are presently confronted with sophisticated SPAM (with >> attachments) from highjacked official servers (Courts, State >> administrations etc.) >> >> All services can be overridden by creating another implementation with a >>> higher priority - for usage statistics, you can use the default >>> implementation < >>> https://github.com/imagej/imagej-usage/blob/master/src/ >>> main/java/net/imagej/usage/DefaultUsageUploadService.java> >>> >>> as a guide. You could even distribute your disabled usage service on an >>> update site <http://fiji.sc/How_to_set_up_and_populate_an_update_site>, >>> >>> to share with other users. >> >> One should do that in general. >> An individual code change means the last resort (for me). >> >> this is an unacceptable reason for gathering user data and I fear >>> there is no honest reason at all to do so. >>> >>> I personally do not write grants, but I am funded by them (along with >>> the rest of my coworkers). It is not enough to say "hey we're going to >>> make the next generation ImageJ framework... thanks for the money bye!" >>> We need the ability to measure and report our successes and failures, >>> and use that information to guide future funding and development >>> priorities. >> >> I've been 40 years in science and research and I had never to provide >> comparable information and if somebody had asked me to, I had refused the >> request or the project. >> >> How comes that Wayne was funded? >> >> Why not use the number of members on the IJ-list? >> It gives an estimate about a factor of 2...5 below the real number of >> IJ-users. >> >> Please consider that some level of usage statistics for Fiji have been >>> collected for nearly 5 years already <http://imagej.net/Fiji_Usage>. >>> >>> These latest changes are just more granular, allowing us to track >>> individual plugins and update site use. >> >> This is one of many reasons that I don't use Fiji. >> >>> Storing user data is a no no! >>> >>> Agreed completely. I would not call what we are tracking "user data." We >>> are tracking "plugin data", and we are really just tracking plugin use >>> counts for a given environment. >> >> Oh well, the kind of computers, software, or whatever I use, is my private >> affair. >> >> So, I don't understand how honesty comes into the picture... perhaps you >>> could explain your feelings here? How do you think this data could be >>> misused? >> >> I wrote with respect to gathering user data: >> "there is no honest reason at all to do so" >> >> The reason for this is that my data (including my computer platform, the >> software I use etc.) is private, except I decide to make it available for >> someone or a group. >> >> Collecting information from my personal computer isn't honest. >> If others do it is no reason to do it too. >> >> Thanks for the response, >>> Mark >> >> Thank you for asking and have a good day >> >> Herbie >> >> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >> >>> On Mon, Aug 11, 2014 at 11:00 AM, Herbie <[hidden email] >>> <mailto:[hidden email]>> wrote: >>> >>> Sorry Mark, >>> >>> but >>> >>> >>>> This data will certainly be used to strengthen future >>>> funding requests to continue the support of Fiji/ImageJ and its >>>> collaborations. >>> >>> this is an unacceptable reason for gathering user data and I fear >>> there is no honest reason at all to do so. >>> >>>> "keeping these statistics anonymous" >>> >>> Well, I'm convinced that you and your co-workers will but... >>> >>> Storing user data is a no no! >>> Some members of the ImageJ-2 Team are criticizing Google an other >>> data collecting organizations since long and now... >>> >>> If user data is gathered/transmitted by IJ-2, I shall, if possible, >>> comment out this portion of code. An OFF-option is insufficient. >>> >>> Just my opinion because you were asking for further comments >>> >>> Herbie >>> >>> ::::::::::::::::::::::::::::::__:::::: >>> >>> >>> On 11.08.14 16:11, Mark Hiner wrote: >>> >>> Hi Gabriel, >>> >>> specially about the "etc." mentioned in that page (?!). >>> >>> >>> I wrote this section and left it vague at the time because >>> Curtis Rueden >>> was in the process of refining the database schema and setting >>> up exactly >>> what was tracked. I realize that I should certainly not have >>> used vague >>> language when discussing user privacy though, and apologize for >>> that! >>> >>> The release wiki page is updated to specify exactly what metadata >>> is >>> stored: country, java version, language, operating system, time >>> zone, >>> update site. >>> >>> I think the collection of usage data should be made an OPT >>> IN option and >>> >>> so be set OFF by default. >>> >>> This was a tough decision for us. We certainly don't want anyone >>> to feel >>> uncomfortable using ImageJ. But we are committed to keeping these >>> statistics anonymous, and this is extremely important >>> information for an >>> open source project. This data will certainly be used to >>> strengthen future >>> funding requests to continue the support of Fiji/ImageJ and its >>> collaborations. >>> >>> So we decided to make it opt out to get as realistic a view of >>> usage as we >>> can, while still allowing anyone who is uncomfortable to disable >>> this >>> functionality. >>> >>> Of course, any further discussion or objections to this feature >>> are >>> welcome... I, personally, would like to better understand any >>> specific >>> concerns people may have. >>> >>> Thanks for the feedback, >>> Mark >>> >>> On Sat, Aug 9, 2014 at 12:44 PM, Gabriel Landini >>> <[hidden email] <mailto:[hidden email]>> >>> >>> wrote: >>> >>> On Friday 08 Aug 2014 16:47:33 you wrote: >>> >>> Today the ImageJ team is proud to announce a new public >>> release candidate >>> for ImageJ2: version 2.0.0-rc-11. >>> >>> >>> Great to hear the IJ2 has reached rc11. >>> >>> Looking at the New Features page, I think the collection of >>> usage data >>> should >>> be made an OPT IN option and so be set OFF by default. >>> >>> Users might like to exercise some privacy by not being >>> tracked, specially >>> about the "etc." mentioned in that page (?!). >>> >>> Cheers >>> >>> Gabriel >>> >>> -- >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.__html >>> <http://imagej.nih.gov/ij/list.html> >>> >>> >>> -- >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.__html >>> <http://imagej.nih.gov/ij/list.html> >>> >>> >>> -- >>> ImageJ mailing list: http://imagej.nih.gov/ij/list.__html >>> <http://imagej.nih.gov/ij/list.html> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Usage data collection (was: Re: ImageJ 2.0.0-rc-11 released)
|
|
In reply to this post by Gabriel Landini
I fully support Gabriel and Herbie in their strong rejection of this
sort of data collection and, in particular, the way it aims to dupe the clueless, introducing it default on. Nobody questions that this kind of data is extremely interesting and useful. I strongly believe that every plugin developer drools over knowing how much their plugins got used, and when, and where. This lust, however, does by now means justify to actually do it. I am also pretty sure that your intentions about this procedure are perfectly honorable and that you're not planning any evil. However, that does not mean that everybody else does at any time in the future and the data will be there, exposed to those hacking into your servers. Please ask yourself whether you would feel comfortable about your operating system reporting back which applications you've used when, where and how often. I would feel spied on. It would be great if you could consider switching that functionality off by default and offer interested users the choice to contribute consciously and voluntarily. That way, you would consciously make the decision to gather significantly less data but in the most honorable way, withstanding the (understandable) desire to get more faster. In addition to that, I would ask you to, in spirit of full Open Source and Open Policy make the collected data (the data, not the derived statistics) read-accessible to everybody in full and license it under an Open Data license, e.g. http://opendatacommons.org/licenses/odbl/ or one of the CCs http://creativecommons.org/licenses/ Everybody can then test whether the data is truly harmless, but I actually believe that we may find interesting ways to identify individuals by their ImageJ usage patterns. If you would change the usage data collection policy in this spirit, I would consider switching it on, for a while. I am very sorry to be so negative in this particular aspect. I appreciate a lot the immense amount of work you are spending to make ImageJ2 a better analysis tool freely available to the community. Best regards, Stephan On Mon, 2014-08-11 at 22:53 +0100, Gabriel Landini wrote: > On Monday 11 Aug 2014 14:18:11 Mark Hiner wrote: > > > SCIFIO was opt in, but usage tracking is opt out? It does not make sense. > > > > To be clear, SCIFIO is enabled by default.. you have to uncheck a box to > > disable SCIFIO, so it is opt out. > > Right, but it was impossible to miss as I had to answer the SCIFIO dialog when > the update came. > What is the problem in showing a similar dialog and let people know what will > be going on? > > > I think there is a difference in the questions "what do you do with the > > software" and "what do users do with the software". I don't believe we will > > ever ask the former question. > > Mark, what you or me personally *believe* somebody will ask in the future does > not matter. It is the process of getting informed consent on the data > collection; IJ2 is assuming and makes it less obvious than it could be. > > > we can ask: > > "How many times was Bio-Formats used with Java 7"? > > we *can not* ask: > > "how many times did Gabriel Landini run Bio-Formats?" > > Even with my poor knowledge of network traffic I can imagine that it might > trivial to script something using time stamps and ip addresses of the > uploading machine as well as plenty of emails also ip addresses from users. > Not that I remotely think that the devel team would have the time or > inclination to do this, but if we are talking about what is impossible, I > suspect it is not. So whether that is potentially identifiable information is > probably debatable. If there is then you would be effectively logging in a > database their location every hour (!) IJ2 runs. Doesn't that sound a bit > creepy? > > My issue was (and remains) that data collection needs to be fully informed > before it takes place, not to be On by default. > > > >If this happens to be something people want to adhere to, then there is > > > nothing to worry about as there will be lots of users opting in when given > > > the chance. > > > I believe this is actually hard to predict. > > Ask the users in a similar way SCIFIO was done and you will have the answer. > Then we would not be having this conversation. > > > If usage statistics were presented similarly - with a pop up on launch and > > an options menu - my expectations for opt-in numbers would be very low. Not > > because people don't want to contribute but because we created a barrier to > > the process. > > The issue that does not seem to stick after all this typing is that IJ2 should > not make that decision for the users. IJ2 is not the owner of the processes > happening in a user's computer. You need to ask, not assume, that people will > be happy for their computers to contact a database every hour and letting it > know they are there and doing this or that. > > > A more successful alternative might be, when statistics are actually being > > uploaded, to display a dialog asking to proceed or not - with yes/no/don't > > ask me again options. That sounds promising, but also potentially annoying > > or confusing to get that pop up, and we can still expect statistics > > reporting to drop. > > But if the reporting statistics drop, that would have to do. Make estimates > instead of collecting all possible data. > > > So since we are not sending or storing use-specific data, and provided and > > publicized the opt-out mechanism, we decided to go with the option that was > > un-disruptive at the workflow level and maximized data collection. > > Yes, you said that before, and I am sure I am not alone thinking it is not the > desirable way of doing it. > > > Especially given, as you mentioned, that users ultimately need to agree to > > communicate with an external server to download these applications and > > updates. > > But there is an obvious difference between the two situations. One is > requesting an update. The other is broadcasting to a database. > > > I hope it's clear that I am not saying we are unwilling to change how > > permissions are exposed.. but if we can circumvent that need via discussion > > it would certainly be my preference. And if we do end up making any > > changes, I would like them to be as minimally damaging to the quality of > > the data gathering as possible. > > I sounds like it is preferable not to ask people about the data collection. > That is in my view an error of judgement that can be resolved easily. > > > To me, there has to be actual user data being exposed to be a matter of > > privacy. Can you clarify what you believe to be the concern here? > > Sure: that the process of collecting usage data is not made clear from the > beginning and it should have informed consent before the collection starts. > > If there are no privacy issues, why is the function to switch it Off called > "Privacy"? > > Regards > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Usage data collection (was: Re: ImageJ 2.0.0-rc-11 released)
|
|
Hi everyone,
after reading through the email-thread I agree with Herbie, Gabriel and Stephan being myself very skeptical of any kind of data collection that I do not explicitly agree on and was not given the chance to opt out. But I feel that at the same time everyone agrees that this is extremely helpful and many users are not that concerned about useage statistics - right dear gmail users? ;) Therefore, why not show a Scifio-like dialog in the beginning as suggested by Gabriel. As a privacy-aware person I would enjoy the following options: a) Please collect my data, I love to help this Open-Source project as much as possible as it has helped me a lot as well. b) Please do not collect my data, but still let the project know that I opted out (no other data sent). c) Please do not send any data about me at all. Note: This choice can be changed under Options > Privacy. I would even add some hint like: "If you choose (c) you might not want to use the updater but instead use anonymization tools like TOR or JAP to download the current Fiji build from the website." OK - (do a,b,c) CANCEL (or default) - c I highly appreciate as well all the work that went into this project and I hope that this will be a constructive discussion that resolves existing doubts and helps the developers as good as possible at the same time. Have a great day and thanks to everyone, Stephan --- Dr. Stephan Preibisch HFSP Fellow Robert H. Singer / Eugene Myers lab Albert Einstein College of Medicine / HHMI Janelia Farm / MPI-CBG email: [hidden email] / [hidden email] / [hidden email] web: http://www.preibisch.net/ On Aug 11, 2014, at 18:54 , Stephan Saalfeld <[hidden email]> wrote: > I fully support Gabriel and Herbie in their strong rejection of this > sort of data collection and, in particular, the way it aims to dupe the > clueless, introducing it default on. > > Nobody questions that this kind of data is extremely interesting and > useful. I strongly believe that every plugin developer drools over > knowing how much their plugins got used, and when, and where. This > lust, however, does by now means justify to actually do it. > > I am also pretty sure that your intentions about this procedure are > perfectly honorable and that you're not planning any evil. However, > that does not mean that everybody else does at any time in the future > and the data will be there, exposed to those hacking into your servers. > > Please ask yourself whether you would feel comfortable about your > operating system reporting back which applications you've used when, > where and how often. I would feel spied on. > > It would be great if you could consider switching that functionality off > by default and offer interested users the choice to contribute > consciously and voluntarily. That way, you would consciously make the > decision to gather significantly less data but in the most honorable > way, withstanding the (understandable) desire to get more faster. In > addition to that, I would ask you to, in spirit of full Open Source and > Open Policy make the collected data (the data, not the derived > statistics) read-accessible to everybody in full and license it under an > Open Data license, e.g. > > http://opendatacommons.org/licenses/odbl/ > > or one of the CCs > > http://creativecommons.org/licenses/ > > Everybody can then test whether the data is truly harmless, but I > actually believe that we may find interesting ways to identify > individuals by their ImageJ usage patterns. > > If you would change the usage data collection policy in this spirit, I > would consider switching it on, for a while. > > I am very sorry to be so negative in this particular aspect. I > appreciate a lot the immense amount of work you are spending to make > ImageJ2 a better analysis tool freely available to the community. > > Best regards, > Stephan > > > > > > On Mon, 2014-08-11 at 22:53 +0100, Gabriel Landini wrote: >> On Monday 11 Aug 2014 14:18:11 Mark Hiner wrote: >>>> SCIFIO was opt in, but usage tracking is opt out? It does not make sense. >>> >>> To be clear, SCIFIO is enabled by default.. you have to uncheck a box to >>> disable SCIFIO, so it is opt out. >> >> Right, but it was impossible to miss as I had to answer the SCIFIO dialog when >> the update came. >> What is the problem in showing a similar dialog and let people know what will >> be going on? >> >>> I think there is a difference in the questions "what do you do with the >>> software" and "what do users do with the software". I don't believe we will >>> ever ask the former question. >> >> Mark, what you or me personally *believe* somebody will ask in the future does >> not matter. It is the process of getting informed consent on the data >> collection; IJ2 is assuming and makes it less obvious than it could be. >> >>> we can ask: >>> "How many times was Bio-Formats used with Java 7"? >>> we *can not* ask: >>> "how many times did Gabriel Landini run Bio-Formats?" >> >> Even with my poor knowledge of network traffic I can imagine that it might >> trivial to script something using time stamps and ip addresses of the >> uploading machine as well as plenty of emails also ip addresses from users. >> Not that I remotely think that the devel team would have the time or >> inclination to do this, but if we are talking about what is impossible, I >> suspect it is not. So whether that is potentially identifiable information is >> probably debatable. If there is then you would be effectively logging in a >> database their location every hour (!) IJ2 runs. Doesn't that sound a bit >> creepy? >> >> My issue was (and remains) that data collection needs to be fully informed >> before it takes place, not to be On by default. >> >>>> If this happens to be something people want to adhere to, then there is >>>> nothing to worry about as there will be lots of users opting in when given >>>> the chance. >> >>> I believe this is actually hard to predict. >> >> Ask the users in a similar way SCIFIO was done and you will have the answer. >> Then we would not be having this conversation. >> >>> If usage statistics were presented similarly - with a pop up on launch and >>> an options menu - my expectations for opt-in numbers would be very low. Not >>> because people don't want to contribute but because we created a barrier to >>> the process. >> >> The issue that does not seem to stick after all this typing is that IJ2 should >> not make that decision for the users. IJ2 is not the owner of the processes >> happening in a user's computer. You need to ask, not assume, that people will >> be happy for their computers to contact a database every hour and letting it >> know they are there and doing this or that. >> >>> A more successful alternative might be, when statistics are actually being >>> uploaded, to display a dialog asking to proceed or not - with yes/no/don't >>> ask me again options. That sounds promising, but also potentially annoying >>> or confusing to get that pop up, and we can still expect statistics >>> reporting to drop. >> >> But if the reporting statistics drop, that would have to do. Make estimates >> instead of collecting all possible data. >> >>> So since we are not sending or storing use-specific data, and provided and >>> publicized the opt-out mechanism, we decided to go with the option that was >>> un-disruptive at the workflow level and maximized data collection. >> >> Yes, you said that before, and I am sure I am not alone thinking it is not the >> desirable way of doing it. >> >>> Especially given, as you mentioned, that users ultimately need to agree to >>> communicate with an external server to download these applications and >>> updates. >> >> But there is an obvious difference between the two situations. One is >> requesting an update. The other is broadcasting to a database. >> >>> I hope it's clear that I am not saying we are unwilling to change how >>> permissions are exposed.. but if we can circumvent that need via discussion >>> it would certainly be my preference. And if we do end up making any >>> changes, I would like them to be as minimally damaging to the quality of >>> the data gathering as possible. >> >> I sounds like it is preferable not to ask people about the data collection. >> That is in my view an error of judgement that can be resolved easily. >> >>> To me, there has to be actual user data being exposed to be a matter of >>> privacy. Can you clarify what you believe to be the concern here? >> >> Sure: that the process of collecting usage data is not made clear from the >> beginning and it should have informed consent before the collection starts. >> >> If there are no privacy issues, why is the function to switch it Off called >> "Privacy"? >> >> Regards >> >> Gabriel >> >> -- >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Usage data collection (was: Re: ImageJ 2.0.0-rc-11 released)
|
|
In reply to this post by Saalfeld, Stephan
Stephan:
> In addition to that, I would ask you to, in spirit of full Open Source and Open Policy make the collected data (the data, not the derived statistics) read-accessible to everybody in full and license it under an Open Data license This is a fantastic idea and I wish we had come up with it earlier... issue'd here: https://github.com/imagej/imagej-usage/issues/2 >I am very sorry to be so negative in this particular aspect. No need to be sorry for being honest. If we release something it's because we' think it's a good idea, but we are extremely lucky to have this community already installed and willing to provide feedback. >Please ask yourself whether you would feel comfortable about your operating system reporting back which applications you've used when, where and how often Because you asked... I'm starting to feel that after 4 years of open source software development as a public employee, I may be the wrong person to answer this question. All of my work is open to the public <http://fiji.sc/User:Hinerm>, my salary is public record <http://host.madison.com/data/uw_salaries/>, and my GitHub profile is basically my work schedule <https://github.com/Hinerm>. I shop on Amazon.com and use google a lot, so I'm fairly certain I've contributed counts to at least a few database entries, somewhere, and every software tool I've worked on has been to facilitate the sharing of data between scientists. So my honest answer is no, I would only feel spied upon if there was actually personally identifying data that was being stored. But of course, those are my personal feelings. I appreciate that others do not feel that way; I would love it if I could both fully understand those reservations and put them at ease... but those are not necessary prerequisites for me to see that something should probably change. I do appreciate the concerns for the database being hacked, and I hope I made it clear that we do not put identifying data in the database. So even if the database was hacked, there should not be a way to abuse this data (another reason why I think making it open source is a cool idea). Gabriel: >What is the problem in showing a similar dialog and let people know what will >be going on? So, this is embarrassing, but I completely forgot about my own commit <https://github.com/imagej/imagej/commit/49d6bc1f8491a4fe41101f88588895dc851041ad> describing the usage statistics addition to the ImageJ welcome message that gets displayed any time a new ImageJ2 is uploaded. I know it's not the same as a dedicated dialog, but I put that text there because I did want to have something pop up to inform people of what was going on. I had mixed feelings about whether the dialog should look like a static document or a changelog, and it was "easier" to just insert the update at the time. Now I feel like that was a mistake and it should be a revision log, with the relevant changes separated out by version with most recent at the top. I was also thinking the welcome message should be modal, <https://github.com/scijava/scijava-common/issues/115> to ensure users have to see it... but I don't know if that's too annoying? Anyway, my hope is that this would be a general solution to raise the visibility of all the changes we make. (I have been seriously distressed at how many bug reports we received where people didn't realize they should disable SCIFIO to restore some lost behavior) Gabriel / Preibisch : You both mention asking for the upload permission at startup because that's how we did it with SCIFIO, but I just wanted to clarify - would it matter if permission was requested at upload time instead? I like the idea that the dialog would be saying "this is happening right now" instead of asking for an ambiguous pass to upload in the future.. but I wasn't sure if I was missing something that makes on startup more desirable? See this issue for permissions refactoring discussion: https://github.com/imagej/imagej-usage/issues/3 Thanks to all for baring with us/me during this feedback period! - Mark P.S. Fun fact: last Friday, my biggest concern for our release was that the statistics uploading would make quitting too slow... ;) On Mon, Aug 11, 2014 at 5:54 PM, Stephan Saalfeld < [hidden email]> wrote: > I fully support Gabriel and Herbie in their strong rejection of this > sort of data collection and, in particular, the way it aims to dupe the > clueless, introducing it default on. > > Nobody questions that this kind of data is extremely interesting and > useful. I strongly believe that every plugin developer drools over > knowing how much their plugins got used, and when, and where. This > lust, however, does by now means justify to actually do it. > > I am also pretty sure that your intentions about this procedure are > perfectly honorable and that you're not planning any evil. However, > that does not mean that everybody else does at any time in the future > and the data will be there, exposed to those hacking into your servers. > > Please ask yourself whether you would feel comfortable about your > operating system reporting back which applications you've used when, > where and how often. I would feel spied on. > > It would be great if you could consider switching that functionality off > by default and offer interested users the choice to contribute > consciously and voluntarily. That way, you would consciously make the > decision to gather significantly less data but in the most honorable > way, withstanding the (understandable) desire to get more faster. In > addition to that, I would ask you to, in spirit of full Open Source and > Open Policy make the collected data (the data, not the derived > statistics) read-accessible to everybody in full and license it under an > Open Data license, e.g. > > http://opendatacommons.org/licenses/odbl/ > > or one of the CCs > > http://creativecommons.org/licenses/ > > Everybody can then test whether the data is truly harmless, but I > actually believe that we may find interesting ways to identify > individuals by their ImageJ usage patterns. > > If you would change the usage data collection policy in this spirit, I > would consider switching it on, for a while. > > I am very sorry to be so negative in this particular aspect. I > appreciate a lot the immense amount of work you are spending to make > ImageJ2 a better analysis tool freely available to the community. > > Best regards, > Stephan > > > > > > On Mon, 2014-08-11 at 22:53 +0100, Gabriel Landini wrote: > > On Monday 11 Aug 2014 14:18:11 Mark Hiner wrote: > > > > SCIFIO was opt in, but usage tracking is opt out? It does not make > sense. > > > > > > To be clear, SCIFIO is enabled by default.. you have to uncheck a box > to > > > disable SCIFIO, so it is opt out. > > > > Right, but it was impossible to miss as I had to answer the SCIFIO > dialog when > > the update came. > > What is the problem in showing a similar dialog and let people know what > will > > be going on? > > > > > I think there is a difference in the questions "what do you do with the > > > software" and "what do users do with the software". I don't believe we > will > > > ever ask the former question. > > > > Mark, what you or me personally *believe* somebody will ask in the > future does > > not matter. It is the process of getting informed consent on the data > > collection; IJ2 is assuming and makes it less obvious than it could be. > > > > > we can ask: > > > "How many times was Bio-Formats used with Java 7"? > > > we *can not* ask: > > > "how many times did Gabriel Landini run Bio-Formats?" > > > > Even with my poor knowledge of network traffic I can imagine that it > might > > trivial to script something using time stamps and ip addresses of the > > uploading machine as well as plenty of emails also ip addresses from > users. > > Not that I remotely think that the devel team would have the time or > > inclination to do this, but if we are talking about what is impossible, I > > suspect it is not. So whether that is potentially identifiable > information is > > probably debatable. If there is then you would be effectively logging in > a > > database their location every hour (!) IJ2 runs. Doesn't that sound a bit > > creepy? > > > > My issue was (and remains) that data collection needs to be fully > informed > > before it takes place, not to be On by default. > > > > > >If this happens to be something people want to adhere to, then there > is > > > > nothing to worry about as there will be lots of users opting in when > given > > > > the chance. > > > > > I believe this is actually hard to predict. > > > > Ask the users in a similar way SCIFIO was done and you will have the > answer. > > Then we would not be having this conversation. > > > > > If usage statistics were presented similarly - with a pop up on launch > and > > > an options menu - my expectations for opt-in numbers would be very > low. Not > > > because people don't want to contribute but because we created a > barrier to > > > the process. > > > > The issue that does not seem to stick after all this typing is that IJ2 > should > > not make that decision for the users. IJ2 is not the owner of the > processes > > happening in a user's computer. You need to ask, not assume, that people > will > > be happy for their computers to contact a database every hour and > letting it > > know they are there and doing this or that. > > > > > A more successful alternative might be, when statistics are actually > being > > > uploaded, to display a dialog asking to proceed or not - with > yes/no/don't > > > ask me again options. That sounds promising, but also potentially > annoying > > > or confusing to get that pop up, and we can still expect statistics > > > reporting to drop. > > > > But if the reporting statistics drop, that would have to do. Make > estimates > > instead of collecting all possible data. > > > > > So since we are not sending or storing use-specific data, and provided > and > > > publicized the opt-out mechanism, we decided to go with the option > that was > > > un-disruptive at the workflow level and maximized data collection. > > > > Yes, you said that before, and I am sure I am not alone thinking it is > not the > > desirable way of doing it. > > > > > Especially given, as you mentioned, that users ultimately need to > agree to > > > communicate with an external server to download these applications and > > > updates. > > > > But there is an obvious difference between the two situations. One is > > requesting an update. The other is broadcasting to a database. > > > > > I hope it's clear that I am not saying we are unwilling to change how > > > permissions are exposed.. but if we can circumvent that need via > discussion > > > it would certainly be my preference. And if we do end up making any > > > changes, I would like them to be as minimally damaging to the quality > of > > > the data gathering as possible. > > > > I sounds like it is preferable not to ask people about the data > collection. > > That is in my view an error of judgement that can be resolved easily. > > > > > To me, there has to be actual user data being exposed to be a matter of > > > privacy. Can you clarify what you believe to be the concern here? > > > > Sure: that the process of collecting usage data is not made clear from > the > > beginning and it should have informed consent before the collection > starts. > > > > If there are no privacy issues, why is the function to switch it Off > called > > "Privacy"? > > > > Regards > > > > Gabriel > > > > -- > > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Usage data collection (was: Re: ImageJ 2.0.0-rc-11 released)
|
|
Mark,
At this point your only sensible option is to isolate all user tracking commits into a separate branch, reverting them from master and from the updater. From the conversation in this mailing list, it is clear to me that the ImageJ 2 team has not thought through the wide implications of user and usage tracking. The defensive tone of your replies suggests that a reflexive period of cooling, thought, planning and careful public disclosure is in order, or you risk alienating this very vibrant and extremely diverse community. We appreciate very much the work that the ImageJ 2 team is putting in. Lets keep it at the highest standard. Best, Albert -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by Gabriel Landini
Hi Mark, all,
If I also may comment on this topic... I see it similar to Gabriel. If I would not have payed attention to the release note from Curtis and Gabriels first mail, I actually would have missed this whole issue. I guess a lot of users not using the mailing list are thus not informed about the "data" collection. I see, that there might be some general advantage in the collection concerning future funding etc., so I would not argument for a complete removal of the feature. For me it would for example also be interesting to see how often the tools I created where used! Anyway, nowadays more of our "private" data are collected and send somewhere by all our electronic devices (especially Smartphones....). But one needs to think about tools created in best willingness and without hidden agenda might be misused simply due to their existence by malicious subjects, not assuming that this can happen or will be possible in this specific case. Therefore, I would also suggest to make the tool opt-in with an initial popup message after the first run of Fiji/IJ2, like for SCIFIO. This potentially "interrupts" the first workflow, but I think this is not a big issue when you see this once in the lifetime of your current Fiji/IJ2 version. The updater actually does the same with the 3 options "update/remind me later/never" which to me seems a good possibility for your tool. Then everybody is informed and can make a sound decision for her-/himself. Obviously, this will result in a drop of N in your statistics but I guess you will still get sufficient people who contribute to that. Just out of curiosity, how was the map existing already since long ago ( http://fiji.sc/Fiji_Usage) actually created having no such "collection" tool (download statistics?)? Additionally, the list of data collected is only shortly mentioned in brackets on the release page. Is this a comprehensive list or only exemplary. It would be nice to show the users which data are collected exactly. Performance wise, I had the impression that it really makes Fiji slower (without being able to put this in numbers). Therefore, minimizing data transfer (only at the end of a session) and collection should be the goal. Because if IJ2 is designed for dealing with big data which need way more calculation power (without exactly knowing how it is able to process higher amounts faster and if this is affected by the collection) etc., potentially slowing the performance time down by a process like the data collection might not be advantageous. I think this is a topic where you will never find a common consense (not even inside this very same e-mail ;-) ), but to conclude, informing the user and presenting options is preferrable in my opinion. Besides that, thanks for all the effort of your team and trying to make it performing better every day. Jan 2014-08-11 23:53 GMT+02:00 Gabriel Landini <[hidden email]>: > On Monday 11 Aug 2014 14:18:11 Mark Hiner wrote: > > > SCIFIO was opt in, but usage tracking is opt out? It does not make > sense. > > > > To be clear, SCIFIO is enabled by default.. you have to uncheck a box to > > disable SCIFIO, so it is opt out. > > Right, but it was impossible to miss as I had to answer the SCIFIO dialog > when > the update came. > What is the problem in showing a similar dialog and let people know what > will > be going on? > > > I think there is a difference in the questions "what do you do with the > > software" and "what do users do with the software". I don't believe we > will > > ever ask the former question. > > Mark, what you or me personally *believe* somebody will ask in the future > does > not matter. It is the process of getting informed consent on the data > collection; IJ2 is assuming and makes it less obvious than it could be. > > > we can ask: > > "How many times was Bio-Formats used with Java 7"? > > we *can not* ask: > > "how many times did Gabriel Landini run Bio-Formats?" > > Even with my poor knowledge of network traffic I can imagine that it might > trivial to script something using time stamps and ip addresses of the > uploading machine as well as plenty of emails also ip addresses from users. > Not that I remotely think that the devel team would have the time or > inclination to do this, but if we are talking about what is impossible, I > suspect it is not. So whether that is potentially identifiable information > is > probably debatable. If there is then you would be effectively logging in a > database their location every hour (!) IJ2 runs. Doesn't that sound a bit > creepy? > > My issue was (and remains) that data collection needs to be fully informed > before it takes place, not to be On by default. > > > >If this happens to be something people want to adhere to, then there is > > > nothing to worry about as there will be lots of users opting in when > given > > > the chance. > > > I believe this is actually hard to predict. > > Ask the users in a similar way SCIFIO was done and you will have the > answer. > Then we would not be having this conversation. > > > If usage statistics were presented similarly - with a pop up on launch > and > > an options menu - my expectations for opt-in numbers would be very low. > Not > > because people don't want to contribute but because we created a barrier > to > > the process. > > The issue that does not seem to stick after all this typing is that IJ2 > should > not make that decision for the users. IJ2 is not the owner of the processes > happening in a user's computer. You need to ask, not assume, that people > will > be happy for their computers to contact a database every hour and letting > it > know they are there and doing this or that. > > > A more successful alternative might be, when statistics are actually > being > > uploaded, to display a dialog asking to proceed or not - with > yes/no/don't > > ask me again options. That sounds promising, but also potentially > annoying > > or confusing to get that pop up, and we can still expect statistics > > reporting to drop. > > But if the reporting statistics drop, that would have to do. Make estimates > instead of collecting all possible data. > > > So since we are not sending or storing use-specific data, and provided > and > > publicized the opt-out mechanism, we decided to go with the option that > was > > un-disruptive at the workflow level and maximized data collection. > > Yes, you said that before, and I am sure I am not alone thinking it is not > the > desirable way of doing it. > > > Especially given, as you mentioned, that users ultimately need to agree > to > > communicate with an external server to download these applications and > > updates. > > But there is an obvious difference between the two situations. One is > requesting an update. The other is broadcasting to a database. > > > I hope it's clear that I am not saying we are unwilling to change how > > permissions are exposed.. but if we can circumvent that need via > discussion > > it would certainly be my preference. And if we do end up making any > > changes, I would like them to be as minimally damaging to the quality of > > the data gathering as possible. > > I sounds like it is preferable not to ask people about the data collection. > That is in my view an error of judgement that can be resolved easily. > > > To me, there has to be actual user data being exposed to be a matter of > > privacy. Can you clarify what you believe to be the concern here? > > Sure: that the process of collecting usage data is not made clear from the > beginning and it should have informed consent before the collection starts. > > If there are no privacy issues, why is the function to switch it Off called > "Privacy"? > > Regards > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- CEO: Dr. rer. nat. Jan Brocher phone: +49 (0)6234 917 03 39 mobile: +49 (0)176 705 746 81 e-mail: [hidden email] info: [hidden email] inquiries: [hidden email] web: www.biovoxxel.de -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Re: Usage data collection (was: Re: ImageJ 2.0.0-rc-11 released)
|
|
In reply to this post by Albert Cardona-2
Dear All,
I would like to provide a perspective from someone who is not so concerned about privacy (I use Gdocs, shop on Amazon etc.). In my opinion Mark has put forward some very sensible arguments, there is a big difference between logging "Someone in Dresden just updated Fiji" and "Pavel Tomancak in Dresden just updated Fiji". I have had these discussions with my computer science friends and colleagues a lot. It is clear that the more knowledge of what is possible to deduce from an IP address you have, the more concerned about privacy you will be. The opt-in suggestion put forward is a good one and I support it. I would be however strongly opposed to disabling usage tracking altogether. As mentioned before, Fiji does this since the very beginning. While for someone this is one of the reasons not to use Fiji, for others this is one of the reasons why they do. There are literally thousands of academic open source projects out there, most don't take off the ground simply because people have an attitude that this is just another pet project of XY to get a paper out. I keep using what I am used to no matter how advanced the functionality of the new software might be. Usage tracking in the form of a world map of updates has been instrumental in lifting Fiji above the threshold in the bioimaging community. I have been showing this map all over the world and I am not ashamed of it. It does not violate anyones privacy. Many other project do this kind of usage tracking. And yes, funding is an issue. I also admit I am a bit addicted to this usage map ;-). Its good we have a discussion about this topic, but I would also encourage readers who, similarly to me, don't share these burning privacy concerns to voice their opinion. All the best PAvel ----------------------------------------------------------------------------------- Pavel Tomancak, Ph.D. Group Leader Max Planck Institute of Molecular Cell Biology and Genetics Pfotenhauerstr. 108 D-01307 Dresden Tel.: +49 351 210 2670 Germany Fax: +49 351 210 2020 email: [hidden email] homepage: http://www.mpi-cbg.de/research/research-groups/pavel-tomancak.html twitter: @PavelTomancak ----------------------------------------------------------------------------------- -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
|
|
In reply to this post by gankaku
Dear Mark,
It looks to me that you (or the Fiji team) have opened a whole can of worms. I have no background in law but my feeling is that you have to be very careful with what data you are going to collect, how you are going to store, manage and use this data and how the users are informed about this. It is not just what the Fiji team "thinks" about this, there are laws. Part of your users, including myself, live in the EU and as you will collect data from computers in the EU I think there might be a problem. I did a quick search online and found: According to a ruling of the Court of Justice of the EU on 24 November 2011 IP addresses are personal data (http://www.mondaq.com/x/162538/Copyright/ECJ+Confirms+That+IP+Addresses+Are+Personal+Data). This has been confirmed by the European Commission on 14 March 2013 (http://www.privacy-europe.com/blog/ip-tracking-is-it-compliant-with-data-protection-laws/). It seems it does not matter what somebody does with the data but what somebody could do with the data. Then I can imagine that there are also issues if this data is leaving the EU. The Fiji.sc website seems to be registered in Germany but part of the development team is in the US (and I am not sure where the download servers are) but I came across something that the US recipient of the data has to be signed up to the US Department of Commerce Safe Harbor Scheme. I really cannot tell you if (part of) these rules cover the collection of the data by Fiji but it seems to me that some more thoughts have to go into the legal framework behind this data collection. Best wishes Kees Dr Ir K.R. Straatman Senior Experimental Officer Advanced Imaging Facility Centre for Core Biotechnology Services University of Leicester http://www2.le.ac.uk/colleges/medbiopsych/facilities-and-services/cbs/lite/aif 2014-08-11 23:53 GMT+02:00 Gabriel Landini <[hidden email]>: > On Monday 11 Aug 2014 14:18:11 Mark Hiner wrote: > > > SCIFIO was opt in, but usage tracking is opt out? It does not make > sense. > > > > To be clear, SCIFIO is enabled by default.. you have to uncheck a > > box to disable SCIFIO, so it is opt out. > > Right, but it was impossible to miss as I had to answer the SCIFIO > dialog when the update came. > What is the problem in showing a similar dialog and let people know > what will be going on? > > > I think there is a difference in the questions "what do you do with > > the software" and "what do users do with the software". I don't > > believe we > will > > ever ask the former question. > > Mark, what you or me personally *believe* somebody will ask in the > future does not matter. It is the process of getting informed consent > on the data collection; IJ2 is assuming and makes it less obvious than > it could be. > > > we can ask: > > "How many times was Bio-Formats used with Java 7"? > > we *can not* ask: > > "how many times did Gabriel Landini run Bio-Formats?" > > Even with my poor knowledge of network traffic I can imagine that it > might trivial to script something using time stamps and ip addresses > of the uploading machine as well as plenty of emails also ip addresses from users. > Not that I remotely think that the devel team would have the time or > inclination to do this, but if we are talking about what is > impossible, I suspect it is not. So whether that is potentially > identifiable information is probably debatable. If there is then you > would be effectively logging in a database their location every hour > (!) IJ2 runs. Doesn't that sound a bit creepy? > > My issue was (and remains) that data collection needs to be fully > informed before it takes place, not to be On by default. > > > >If this happens to be something people want to adhere to, then > > >there is nothing to worry about as there will be lots of users > > >opting in when > given > > > the chance. > > > I believe this is actually hard to predict. > > Ask the users in a similar way SCIFIO was done and you will have the > answer. > Then we would not be having this conversation. > > > If usage statistics were presented similarly - with a pop up on > > launch > and > > an options menu - my expectations for opt-in numbers would be very low. > Not > > because people don't want to contribute but because we created a > > barrier > to > > the process. > > The issue that does not seem to stick after all this typing is that > IJ2 should not make that decision for the users. IJ2 is not the owner > of the processes happening in a user's computer. You need to ask, not > assume, that people will be happy for their computers to contact a > database every hour and letting it know they are there and doing this > or that. > > > A more successful alternative might be, when statistics are actually > being > > uploaded, to display a dialog asking to proceed or not - with > yes/no/don't > > ask me again options. That sounds promising, but also potentially > annoying > > or confusing to get that pop up, and we can still expect statistics > > reporting to drop. > > But if the reporting statistics drop, that would have to do. Make > estimates instead of collecting all possible data. > > > So since we are not sending or storing use-specific data, and > > provided > and > > publicized the opt-out mechanism, we decided to go with the option > > that > was > > un-disruptive at the workflow level and maximized data collection. > > Yes, you said that before, and I am sure I am not alone thinking it is > not the desirable way of doing it. > > > Especially given, as you mentioned, that users ultimately need to > > agree > to > > communicate with an external server to download these applications > > and updates. > > But there is an obvious difference between the two situations. One is > requesting an update. The other is broadcasting to a database. > > > I hope it's clear that I am not saying we are unwilling to change > > how permissions are exposed.. but if we can circumvent that need via > discussion > > it would certainly be my preference. And if we do end up making any > > changes, I would like them to be as minimally damaging to the > > quality of the data gathering as possible. > > I sounds like it is preferable not to ask people about the data collection. > That is in my view an error of judgement that can be resolved easily. > > > To me, there has to be actual user data being exposed to be a matter > > of privacy. Can you clarify what you believe to be the concern here? > > Sure: that the process of collecting usage data is not made clear from > the beginning and it should have informed consent before the collection starts. > > If there are no privacy issues, why is the function to switch it Off > called "Privacy"? > > Regards > > Gabriel > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- CEO: Dr. rer. nat. Jan Brocher phone: +49 (0)6234 917 03 39 mobile: +49 (0)176 705 746 81 e-mail: [hidden email] info: [hidden email] inquiries: [hidden email] web: www.biovoxxel.de -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |