ImageJ 2.0.0-rc-11 released

[Dimiter Prodanov (imec)]

Dear all,

I think that tracking user activities MUST be optional and a matter of informed consent.
Therefore, it should come in  a form of a plugin which the user be able to disable in an easy manner.

The whole business is on the border of being unethical so I strongly agree with Gabriel about the privacy issues.
It think that the IJ2 team should not adopt bad practices in the spirit of Fakebook and M$$.

Best regards,

Dimiter Prodanov
 

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Herbie-4]

Mark,

to cite one of our previous ministers of foreign affairs:

        "I'm not convinced!"

(It turned out that he was right.)

Simply tell people, organizations, or agencies who like to see the
option in question, that you and the team won't provide it but that they
may write and distribute plugins with this functionality. Of course,
such plugins can't be part of the Fiji or of whatever distribution of
IJ-2 or IJ-2 itself.__

If somebody provides plugins for the scientific community and is proud
about the associated download rates, then I would call this either
childish or commercial behavior. We provide scientific tools and help no
matter who and how many will use it.

Presently, I'm glad that ImageJ-1 is available, healthy and transparent.

If IJ-2 is relies on different principles or assumptions than IJ-1 it
should be named differently.

Best wishes

Herbie
__________________________________
PS:

 >> Are you sure users check the exact sever?
 >
 > I'm sorry, I'm not sure what you mean...

If you download something, do you check whether the server, from which
you actually perform the download, belongs to or is authorized by the
person, company, agency who offered the download?

Some days ago I received an eMail with an official and valid sender
address of a German Civil Court of Law. It turned out that it was a
highjacked address.

It is really easy to distribute software that has been manipulated and
it is easy as well to identify users. Although you may doubt this as well.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
On 11.08.14 23:25, Mark Hiner 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

[jni]

Herbie:

That is a great quote. ;)

IJ devs:

*There's just no question that the right thing to do here is opt-in.* Yes,
you will lose tracking data but you are definitely going to piss people off
by collecting usage -- and some of those people may be lawyers.

It is standard practice for software to show a splash page at install time
specifically to address the collection of usage data, with a statement
along the lines of "please help us improve this software by collecting
anonymous usage data". At a *minimum*, this is what IJ should do. If you
wanted to be extra-nice about it, as you should, you would on the same
screen print a list of exactly what was being collected, and this list
would be generated from the code, so that it's impossible for the doc and
the code to fall out of sync.

To reiterate what others have said, with so much discussion around privacy
and metadata currently in the media (Snowden, Australian metadata
collection, the Facebook experiment, the excellent Paul Revere post
<http://kieranhealy.org/blog/archives/2013/06/09/using-metadata-to-find-paul-revere/>),
and with plenty of research showing that de-anonymising data is usually
much easier than one thinks, it's surprising (to say the least) that the IJ
devs went the opt-out, no notification route.

My 2c.

Juan.

(Thanks @PavelTomancak <https://twitter.com/PavelTomancak> for putting me
onto this discussion.)


On Tue, Aug 12, 2014 at 7:11 PM, Herbie <[hidden email]> wrote:

> Mark,
>
> to cite one of our previous ministers of foreign affairs:
>
>         "I'm not convinced!"
>
> (It turned out that he was right.)
>
> Simply tell people, organizations, or agencies who like to see the option
> in question, that you and the team won't provide it but that they may write
> and distribute plugins with this functionality. Of course, such plugins
> can't be part of the Fiji or of whatever distribution of IJ-2 or IJ-2
> itself.__
>
> If somebody provides plugins for the scientific community and is proud
> about the associated download rates, then I would call this either childish
> or commercial behavior. We provide scientific tools and help no matter who
> and how many will use it.
>
> Presently, I'm glad that ImageJ-1 is available, healthy and transparent.
>
> If IJ-2 is relies on different principles or assumptions than IJ-1 it
> should be named differently.
>
> Best wishes
>
> Herbie
> __________________________________
> PS:
>
>
> >> Are you sure users check the exact sever?
> >
> > I'm sorry, I'm not sure what you mean...
>
> If you download something, do you check whether the server, from which you
> actually perform the download, belongs to or is authorized by the person,
> company, agency who offered the download?
>
> Some days ago I received an eMail with an official and valid sender
> address of a German Civil Court of Law. It turned out that it was a
> highjacked address.
>
> It is really easy to distribute software that has been manipulated and it
> is easy as well to identify users. Although you may doubt this as well.
>
> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
> ::::::::::::::::
>
> On 11.08.14 23:25, Mark Hiner 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
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Monday 11 Aug 2014 20:19:01 Mark Hiner wrote:

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

Mark, I said this before. What you 'personally' think and whether you shop in
Amazon is not relevant; you should not be dictating what is acceptable and
what is not. This is about what everybody else thinks about the data that will
be collected from their computers into your database. I feel some inexplicable
reluctance to accept you should seek permission to do so. Why?

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

You might think it is an innocent plugin count. Here is another possible abuse
of the data:
Let's say I write a new plugin called cell_scanner. My name appears in the
plugin pages. Can you guess who's computer will show a spike in its use during
the development and debug time together with a location, language and "etc."
of where it happened? Then because every IJ2 install gets a unique identifier
based on the hash of the username and mac address, for the rest of the life of
my network card it will be logged when my computer runs IJ2, at 1hr intervals
and when I close it. Now that will be in a database and shared with the world,
and you think that I should not have an option to actively agree? How naive is
that?

> So, this is embarrassing, but I completely forgot about my own commit
> <https://github.com/imagej/imagej/commit/49d6bc1f8491a4fe41101f88588895dc851
> 041ad> 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.

No, it is not the same. You need to *ask*, so users give you *informed
consent*. That is one of the basic requirements of data collection.
You know that people might not read EULAS or long documents when in an hurry.
You need to make them aware so they can decide if they are happy to be
tracked.
It needs to be a question, a dialog, with a check box so people have to click
on it to agree the first time that this is implemented or IJ installed and
when you delete the prefs file, where the choice is stored.

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

Not a document. A dialog with a check box, so the act of clicking on it gives
you some indication that the users want it. You do not need it every day. If
users change their mind they can revert to non-private mode easily.

I repeat what Stephan S said: by not giving a choice it looks like it aims to
dupe the clueless. Then you said that if you ask it will result in less people
allowing tracking and that is not good... So this could be seen as not a
completely ethical approach.
Here we need to submit all our scientific projects to ethical review and they
*always* insist that we abide by the principles of the ICO and we need to be
explicit about it. Even with anonymised data. What you are planning falls
short of several of those principles (no informed consent, no specified period
for collection of data [is this for eternity?], no clear explanation of what
the data is collected for, no recourse to delete entries from the database if
somebody change their mind, transfer of data outside the EU, just to name a
few). I am sure that this is not intentional, but lack of intention does not
make it right or acceptable.

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

IJ2 data tracking is quite a change from the previous behaviour of IJ, and it
is one that could affect users without clear evidence of how it will benefit
them.

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

You need to ask permission to *collect* the data, not to upload...
I hope IJ2 would not be collecting the data anyway and just not uploading?
Why is this built in in IJ2 and not a separate plugin?

The more I hear about this the less I like it. I am very disappointed by this
unexpected change of scope in the IJ2 project which until now seemed very
promising. This should be put right as a matter of urgency.

Regards

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Doube-4]

Dear Listers

On 11/08/14 22:59, Gabriel Landini wrote:
> My issue was (and remains) that data collection needs to be fully informed
> before it takes place, not to be On by default.

I'm responding here because I have a great deal of respect for your frank opinions.

For some time now, BoneJ users have had the option to 'opt-in' to data collection.

When the user first runs a plugin from the BoneJ suite, a dialog pops-up with information about what data are collected, where they go, how they are processed, and what for (in line with the UK Data Protection Act). Then the user has to click OK to allow data collection, Cancel if they don't want to and Help if they want more information, which is here:

http://bonej.org/stats

and the code is here:

https://github.com/mdoube/BoneJ/blob/master/src/org/doube/util/UsageReporter.java
https://github.com/mdoube/BoneJ/blob/master/src/org/doube/util/ReporterOptions.java

I was pretty concerned about doing this with as much respect for user privacy as possible, because that is something I care about personally too. It has been gratifying that quite a number of users (some hundreds, I think, including me) have chosen to opt-in, and allowed us to count by now millions of plugin runs. I hope that people who are uncomfortable about this data collection - for whatever, or no, reason - would continue to use the software confident that we take their opt-out seriously. And if they wanted a disconnected version which doesn't know how to phone home, they are welcome to ask for it (it would be easy to do), or make it themselves.

The primary use for these data has been to apply for (competitive, hard-to-win) funding so that we can hire someone to maintain and improve the software, which I can't commit to as well as I could when I was a postdoc. Summary statistics have been used in a ~£700k bid to BBSRC (only just out of the money, unfortunately). The grant panel was very impressed by the level of usage which we were able to demonstrate with these collated user data, so it did make a difference, and we plan to do something similar with Wellcome Trust later this year (successful, this time, I hope...).

The other use is to identify patterns of work that we can help to improve - so if someone always runs plugin A followed by B and C, perhaps we can put those together a bit better. If no-one is using it on Mac OS version whatever, maybe it is broken there and no-one told us (silence does not equate to satisfaction).

I tried very hard to do this as transparently as possible. Logging was announced on the mailing list, the code and all its changes are available, the user has to make a choice to opt-in or -out, and can do so at any point. Quitting the dialog by reflexive hitting Esc key opts-out. The data which are transmitted can be examined in the log window. Opting out clears local data. It only sends data on a live network connection - if you are disconnected no report is ever sent.

On release, I braced myself for an outcry like the current one around ImageJ2, but there was none - but maybe the unhappy people just went away rather than sharing their opinions - which I'd really like to hear, because that is how we can make it better. So far I've had no negative comments and lots of people opting in. Naturally, I have no figures on opt-outs!

My suggestion to the ImageJ2 team is that a great big annoying difficult to ignore and easy to read opt-in screen is required if you want to include phone-home functionality (as Eclipse does, for example). As Gabriel stated, people need to actively grant permission for the software to send their data - permission must not be passively assumed, otherwise you set up a nasty trust/power dynamic.

Best regards,

Michael

--
Dr Michael Doube
BPhil BVSc PhD MRCVS
Lecturer, Comparative Biomedical Sciences
The Royal Veterinary College, University of London
London NW1 0TU
United Kingdom

[phone] (Internal: 5503)

<http://www.rvc.ac.uk>

This message, together with any attachments, is intended for the stated addressee(s) only and may contain privileged or confidential information. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Royal Veterinary College.

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[gankaku]

Hi all,

Me, being not part of the core developer team of all the IJ-based
distributions or IJ2, would like to add a (potentially) summarizing
consideration to this.
I think this discussion is heating up and making the opinions drifting
further apart, though it is urgently necessary and important to be held.

As I see the growing comment list, the number of users and especially
(main!) developers of IJ, Fiji and IJ2 is growing who are rather against
the tracking tool (or at least dislike it).

Thus, you (@Mark) might rethink and balance the idea, possibilities, real
necessity and potential "hazard" of such a tool and:

1.) at least change its mode of action OR
2.) eliminate/remove it completely

These are just suggestions from me as individual/independent user/developer
due to all the comments, but........

In an open source environment the whole thing lives somehow by or due to a
certain support from the majority of the community.

If now the majority of the users (and again... even developers) are
extremely sceptical or completely against the data collection this will
finally affect the complete IJ2. It might not only drop the contributor
numbers to your statistics. It rather might decrease the total number of
IJ2 users, if not using it would be the only option to avoid data
collection. The latter would actually be rather devastating for such a
great project like IJ2 especially since it is "new" to the users and
contains a lot of effort of many people and an investment in the future for
image processing and analysis.

I personally, by thinking about the projects' overall benefit, would not
put it at risk for one tool/option which is rejected by a majority. Even
you would like to see/have it in IJ2/Fiji. Thus, democratic decisions are
sometimes hard for the individual but might help the complete community or
project.

I hope nobody feels offended by my suggestion and comments but I felt the
urge to share it to pinpoint the more or less only 2 options to finally
avoid any harm to the general image of the IJ2 project.

cheers,
Jan





2014-08-12 12:45 GMT+02:00 Gabriel Landini <[hidden email]>:

> On Monday 11 Aug 2014 20:19:01 Mark Hiner wrote:
> > 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.
>
> Mark, I said this before. What you 'personally' think and whether you shop
> in
> Amazon is not relevant; you should not be dictating what is acceptable and
> what is not. This is about what everybody else thinks about the data that
> will
> be collected from their computers into your database. I feel some
> inexplicable
> reluctance to accept you should seek permission to do so. Why?
>
> > 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).
>
> You might think it is an innocent plugin count. Here is another possible
> abuse
> of the data:
> Let's say I write a new plugin called cell_scanner. My name appears in the
> plugin pages. Can you guess who's computer will show a spike in its use
> during
> the development and debug time together with a location, language and
> "etc."
> of where it happened? Then because every IJ2 install gets a unique
> identifier
> based on the hash of the username and mac address, for the rest of the
> life of
> my network card it will be logged when my computer runs IJ2, at 1hr
> intervals
> and when I close it. Now that will be in a database and shared with the
> world,
> and you think that I should not have an option to actively agree? How
> naive is
> that?
>
> > So, this is embarrassing, but I completely forgot about my own commit
> > <
> https://github.com/imagej/imagej/commit/49d6bc1f8491a4fe41101f88588895dc851
> > 041ad> 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.
>
> No, it is not the same. You need to *ask*, so users give you *informed
> consent*. That is one of the basic requirements of data collection.
> You know that people might not read EULAS or long documents when in an
> hurry.
> You need to make them aware so they can decide if they are happy to be
> tracked.
> It needs to be a question, a dialog, with a check box so people have to
> click
> on it to agree the first time that this is implemented or IJ installed and
> when you delete the prefs file, where the choice is stored.
>
> > 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.
>
> Not a document. A dialog with a check box, so the act of clicking on it
> gives
> you some indication that the users want it. You do not need it every day.
> If
> users change their mind they can revert to non-private mode easily.
>
> I repeat what Stephan S said: by not giving a choice it looks like it aims
> to
> dupe the clueless. Then you said that if you ask it will result in less
> people
> allowing tracking and that is not good... So this could be seen as not a
> completely ethical approach.
> Here we need to submit all our scientific projects to ethical review and
> they
> *always* insist that we abide by the principles of the ICO and we need to
> be
> explicit about it. Even with anonymised data. What you are planning falls
> short of several of those principles (no informed consent, no specified
> period
> for collection of data [is this for eternity?], no clear explanation of
> what
> the data is collected for, no recourse to delete entries from the database
> if
> somebody change their mind, transfer of data outside the EU, just to name a
> few). I am sure that this is not intentional, but lack of intention does
> not
> make it right or acceptable.
>
> > 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.
>
> IJ2 data tracking is quite a change from the previous behaviour of IJ, and
> it
> is one that could affect users without clear evidence of how it will
> benefit
> them.
>
> > 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?
>
> You need to ask permission to *collect* the data, not to upload...
> I hope IJ2 would not be collecting the data anyway and just not uploading?
> Why is this built in in IJ2 and not a separate plugin?
>
> The more I hear about this the less I like it. I am very disappointed by
> this
> unexpected change of scope in the IJ2 project which until now seemed very
> promising. This should be put right as a matter of urgency.
>
> Regards
>
> Gabriel
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--

CEO: Dr. rer. nat. Jan Brocher
phone:  [phone]
mobile: [phone]
e-mail: [hidden email]
info: [hidden email]
inquiries: [hidden email]
web: www.biovoxxel.de

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kevin W Eliceiri-2]

Hi All,


On behalf of all parties involved in the ImageJ2 project, I want to announce we understand the concerns raised and as such will make any user data collection in ImageJ2 strictly opt in with a clear message. We were just using the same approach that has served FIJI well in collected anonymized metrics for overall usage reporting purposes such as grants. But we are listening and understand the privacy concerns and as such will put a new ImageJ2 release out shortly that will have a clear opt in for those that want to help with reporting effort. For those that decide to optin this will be just tracking location information and strictly used for supporting funding efforts such as we already do with FIJI.


Please consider this issue addressed, and always we appreciate all the discussion and efforts that make the ImageJ community great.


all the best
kevin

On 08/12/14, "Doube, Michael"  wrote:

> Dear Listers
>
> On 11/08/14 22:59, Gabriel Landini wrote:
> > My issue was (and remains) that data collection needs to be fully informed
> > before it takes place, not to be On by default.
>
> I'm responding here because I have a great deal of respect for your frank opinions.
>
> For some time now, BoneJ users have had the option to 'opt-in' to data collection.
>
> When the user first runs a plugin from the BoneJ suite, a dialog pops-up with information about what data are collected, where they go, how they are processed, and what for (in line with the UK Data Protection Act). Then the user has to click OK to allow data collection, Cancel if they don't want to and Help if they want more information, which is here:
>
> http://bonej.org/stats
>
> and the code is here:
>
> https://github.com/mdoube/BoneJ/blob/master/src/org/doube/util/UsageReporter.java
> https://github.com/mdoube/BoneJ/blob/master/src/org/doube/util/ReporterOptions.java
>
> I was pretty concerned about doing this with as much respect for user privacy as possible, because that is something I care about personally too. It has been gratifying that quite a number of users (some hundreds, I think, including me) have chosen to opt-in, and allowed us to count by now millions of plugin runs. I hope that people who are uncomfortable about this data collection - for whatever, or no, reason - would continue to use the software confident that we take their opt-out seriously. And if they wanted a disconnected version which doesn't know how to phone home, they are welcome to ask for it (it would be easy to do), or make it themselves.
>
> The primary use for these data has been to apply for (competitive, hard-to-win) funding so that we can hire someone to maintain and improve the software, which I can't commit to as well as I could when I was a postdoc. Summary statistics have been used in a ~£700k bid to BBSRC (only just out of the money, unfortunately). The grant panel was very impressed by the level of usage which we were able to demonstrate with these collated user data, so it did make a difference, and we plan to do something similar with Wellcome Trust later this year (successful, this time, I hope...).
>
> The other use is to identify patterns of work that we can help to improve - so if someone always runs plugin A followed by B and C, perhaps we can put those together a bit better. If no-one is using it on Mac OS version whatever, maybe it is broken there and no-one told us (silence does not equate to satisfaction).
>
> I tried very hard to do this as transparently as possible. Logging was announced on the mailing list, the code and all its changes are available, the user has to make a choice to opt-in or -out, and can do so at any point. Quitting the dialog by reflexive hitting Esc key opts-out. The data which are transmitted can be examined in the log window. Opting out clears local data. It only sends data on a live network connection - if you are disconnected no report is ever sent.
>
> On release, I braced myself for an outcry like the current one around ImageJ2, but there was none - but maybe the unhappy people just went away rather than sharing their opinions - which I'd really like to hear, because that is how we can make it better. So far I've had no negative comments and lots of people opting in. Naturally, I have no figures on opt-outs!
>
> My suggestion to the ImageJ2 team is that a great big annoying difficult to ignore and easy to read opt-in screen is required if you want to include phone-home functionality (as Eclipse does, for example). As Gabriel stated, people need to actively grant permission for the software to send their data - permission must not be passively assumed, otherwise you set up a nasty trust/power dynamic.
>
> Best regards,
>
> Michael
>
> --
> Dr Michael Doube
> BPhil BVSc PhD MRCVS
> Lecturer, Comparative Biomedical Sciences
> The Royal Veterinary College, University of London
> London NW1 0TU
> United Kingdom
>
> [phone] (Internal: 5503)
>
> <http://www.rvc.ac.uk>
>
> This message, together with any attachments, is intended for the stated addressee(s) only and may contain privileged or confidential information. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Royal Veterinary College.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
Kevin W. Eliceiri
Director, Laboratory for Optical and Computational Instrumentation (LOCI)
Departments Cell and Molecular Biology and Biomedical Engineering
Affiliate Principal Investigator, Morgridge Institute for Research (MIR)
Room 271 Animal Sciences, 1675 Observatory Drive, Madison, WI 53706
Phone: [phone]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Jürgen Gluch]

Dear all,

Thanks for the discussion and all the statements made so far.
As a perspective from a simple user of Fiji - not a developer, nor
somebody who reads the code - I strongly prefer to be presented by an
opt-in dialoge, not silently to be tracked, whatever the information
will be. If the statements/reason and data to be submitted are
explained well, I certainly will contribute to the data collection to
help further development and funding of the development.

As IJ is very modular it might be a good idea to separate the data
collection and upload functionality to a separate plugin. Anyone who
is really concerned about privacy can delete the plugin to make a hard
cut. The soft version must be an opt-in after install/update and an
option to change this at users will in a dialogue.

I know that current Fiji contains IJ1 (1.49e) and IJ2 (2.0.0-rc-9).
Does it collects data already? If so, how can I turn it off?

cheers,
Jürgen



--
Jürgen Gluch
Kötitzer Str. 9f / 01445 Radebeul / Deutschland
Mobil: [phone]
VOIP: [hidden email]
XMPP: [hidden email]


2014-08-12 13:39 GMT+02:00 BioVoxxel <[hidden email]>:

> Hi all,
>
> Me, being not part of the core developer team of all the IJ-based
> distributions or IJ2, would like to add a (potentially) summarizing
> consideration to this.
> I think this discussion is heating up and making the opinions drifting
> further apart, though it is urgently necessary and important to be held.
>
> As I see the growing comment list, the number of users and especially
> (main!) developers of IJ, Fiji and IJ2 is growing who are rather against
> the tracking tool (or at least dislike it).
>
> Thus, you (@Mark) might rethink and balance the idea, possibilities, real
> necessity and potential "hazard" of such a tool and:
>
> 1.) at least change its mode of action OR
> 2.) eliminate/remove it completely
>
> These are just suggestions from me as individual/independent user/developer
> due to all the comments, but........
>
> In an open source environment the whole thing lives somehow by or due to a
> certain support from the majority of the community.
>
> If now the majority of the users (and again... even developers) are
> extremely sceptical or completely against the data collection this will
> finally affect the complete IJ2. It might not only drop the contributor
> numbers to your statistics. It rather might decrease the total number of
> IJ2 users, if not using it would be the only option to avoid data
> collection. The latter would actually be rather devastating for such a
> great project like IJ2 especially since it is "new" to the users and
> contains a lot of effort of many people and an investment in the future for
> image processing and analysis.
>
> I personally, by thinking about the projects' overall benefit, would not
> put it at risk for one tool/option which is rejected by a majority. Even
> you would like to see/have it in IJ2/Fiji. Thus, democratic decisions are
> sometimes hard for the individual but might help the complete community or
> project.
>
> I hope nobody feels offended by my suggestion and comments but I felt the
> urge to share it to pinpoint the more or less only 2 options to finally
> avoid any harm to the general image of the IJ2 project.
>
> cheers,
> Jan
>
>
>
>
>
> 2014-08-12 12:45 GMT+02:00 Gabriel Landini <[hidden email]>:
>
>> On Monday 11 Aug 2014 20:19:01 Mark Hiner wrote:
>> > 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.
>>
>> Mark, I said this before. What you 'personally' think and whether you shop
>> in
>> Amazon is not relevant; you should not be dictating what is acceptable and
>> what is not. This is about what everybody else thinks about the data that
>> will
>> be collected from their computers into your database. I feel some
>> inexplicable
>> reluctance to accept you should seek permission to do so. Why?
>>
>> > 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).
>>
>> You might think it is an innocent plugin count. Here is another possible
>> abuse
>> of the data:
>> Let's say I write a new plugin called cell_scanner. My name appears in the
>> plugin pages. Can you guess who's computer will show a spike in its use
>> during
>> the development and debug time together with a location, language and
>> "etc."
>> of where it happened? Then because every IJ2 install gets a unique
>> identifier
>> based on the hash of the username and mac address, for the rest of the
>> life of
>> my network card it will be logged when my computer runs IJ2, at 1hr
>> intervals
>> and when I close it. Now that will be in a database and shared with the
>> world,
>> and you think that I should not have an option to actively agree? How
>> naive is
>> that?
>>
>> > So, this is embarrassing, but I completely forgot about my own commit
>> > <
>> https://github.com/imagej/imagej/commit/49d6bc1f8491a4fe41101f88588895dc851
>> > 041ad> 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.
>>
>> No, it is not the same. You need to *ask*, so users give you *informed
>> consent*. That is one of the basic requirements of data collection.
>> You know that people might not read EULAS or long documents when in an
>> hurry.
>> You need to make them aware so they can decide if they are happy to be
>> tracked.
>> It needs to be a question, a dialog, with a check box so people have to
>> click
>> on it to agree the first time that this is implemented or IJ installed and
>> when you delete the prefs file, where the choice is stored.
>>
>> > 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.
>>
>> Not a document. A dialog with a check box, so the act of clicking on it
>> gives
>> you some indication that the users want it. You do not need it every day.
>> If
>> users change their mind they can revert to non-private mode easily.
>>
>> I repeat what Stephan S said: by not giving a choice it looks like it aims
>> to
>> dupe the clueless. Then you said that if you ask it will result in less
>> people
>> allowing tracking and that is not good... So this could be seen as not a
>> completely ethical approach.
>> Here we need to submit all our scientific projects to ethical review and
>> they
>> *always* insist that we abide by the principles of the ICO and we need to
>> be
>> explicit about it. Even with anonymised data. What you are planning falls
>> short of several of those principles (no informed consent, no specified
>> period
>> for collection of data [is this for eternity?], no clear explanation of
>> what
>> the data is collected for, no recourse to delete entries from the database
>> if
>> somebody change their mind, transfer of data outside the EU, just to name a
>> few). I am sure that this is not intentional, but lack of intention does
>> not
>> make it right or acceptable.
>>
>> > 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.
>>
>> IJ2 data tracking is quite a change from the previous behaviour of IJ, and
>> it
>> is one that could affect users without clear evidence of how it will
>> benefit
>> them.
>>
>> > 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?
>>
>> You need to ask permission to *collect* the data, not to upload...
>> I hope IJ2 would not be collecting the data anyway and just not uploading?
>> Why is this built in in IJ2 and not a separate plugin?
>>
>> The more I hear about this the less I like it. I am very disappointed by
>> this
>> unexpected change of scope in the IJ2 project which until now seemed very
>> promising. This should be put right as a matter of urgency.
>>
>> Regards
>>
>> Gabriel
>>
>> --
>> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>>
>
>
>
> --
>
> CEO: Dr. rer. nat. Jan Brocher
> phone:  [phone]
> mobile: [phone]
> 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

[Mark Hiner-2]

Hi Jürgen,

>I know that current Fiji contains IJ1 (1.49e) and IJ2 (2.0.0-rc-9). Does
it collects data already?

This functionality was uploaded to Fiji with IJ2 2.0.0-rc-11, so it
shouldn't be collecting data right now. To be sure, you can check your
local Fiji.app/jars or run "Help > Update Fiji > Advanced Mode" and look
for: imagej-usage-0.2.0.jar.

>If so, how can I turn it off?

"Edit > Options > Privacy... > Collect anonymous usage statistics". This
option is also contained in imagej-usage-0.2.0.jar so it will only be
available if statistics are already being uploaded.

You can also uninstall the imagej-usage-0.2.0.jar by manually deleting it
from your local Fiji.app/jars, or using the Update Fiji > Advanced Mode
dialog.

Let us know if you have any more questions, and thanks for the feedback.

- Mark


On Tue, Aug 12, 2014 at 7:46 AM, Jürgen Gluch <[hidden email]>
wrote:

> Dear all,
>
> Thanks for the discussion and all the statements made so far.
> As a perspective from a simple user of Fiji - not a developer, nor
> somebody who reads the code - I strongly prefer to be presented by an
> opt-in dialoge, not silently to be tracked, whatever the information
> will be. If the statements/reason and data to be submitted are
> explained well, I certainly will contribute to the data collection to
> help further development and funding of the development.
>
> As IJ is very modular it might be a good idea to separate the data
> collection and upload functionality to a separate plugin. Anyone who
> is really concerned about privacy can delete the plugin to make a hard
> cut. The soft version must be an opt-in after install/update and an
> option to change this at users will in a dialogue.
>
> I know that current Fiji contains IJ1 (1.49e) and IJ2 (2.0.0-rc-9).
> Does it collects data already? If so, how can I turn it off?
>
> cheers,
> Jürgen
>
>
>
> --
> Jürgen Gluch
> Kötitzer Str. 9f / 01445 Radebeul / Deutschland
> Mobil: [phone]
> VOIP: [hidden email]
> XMPP: [hidden email]
>
>
> 2014-08-12 13:39 GMT+02:00 BioVoxxel <[hidden email]>:
> > Hi all,
> >
> > Me, being not part of the core developer team of all the IJ-based
> > distributions or IJ2, would like to add a (potentially) summarizing
> > consideration to this.
> > I think this discussion is heating up and making the opinions drifting
> > further apart, though it is urgently necessary and important to be held.
> >
> > As I see the growing comment list, the number of users and especially
> > (main!) developers of IJ, Fiji and IJ2 is growing who are rather against
> > the tracking tool (or at least dislike it).
> >
> > Thus, you (@Mark) might rethink and balance the idea, possibilities, real
> > necessity and potential "hazard" of such a tool and:
> >
> > 1.) at least change its mode of action OR
> > 2.) eliminate/remove it completely
> >
> > These are just suggestions from me as individual/independent
> user/developer
> > due to all the comments, but........
> >
> > In an open source environment the whole thing lives somehow by or due to
> a
> > certain support from the majority of the community.
> >
> > If now the majority of the users (and again... even developers) are
> > extremely sceptical or completely against the data collection this will
> > finally affect the complete IJ2. It might not only drop the contributor
> > numbers to your statistics. It rather might decrease the total number of
> > IJ2 users, if not using it would be the only option to avoid data
> > collection. The latter would actually be rather devastating for such a
> > great project like IJ2 especially since it is "new" to the users and
> > contains a lot of effort of many people and an investment in the future
> for
> > image processing and analysis.
> >
> > I personally, by thinking about the projects' overall benefit, would not
> > put it at risk for one tool/option which is rejected by a majority. Even
> > you would like to see/have it in IJ2/Fiji. Thus, democratic decisions are
> > sometimes hard for the individual but might help the complete community
> or
> > project.
> >
> > I hope nobody feels offended by my suggestion and comments but I felt the
> > urge to share it to pinpoint the more or less only 2 options to finally
> > avoid any harm to the general image of the IJ2 project.
> >
> > cheers,
> > Jan
> >
> >
> >
> >
> >
> > 2014-08-12 12:45 GMT+02:00 Gabriel Landini <[hidden email]>:
> >
> >> On Monday 11 Aug 2014 20:19:01 Mark Hiner wrote:
> >> > 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.
> >>
> >> Mark, I said this before. What you 'personally' think and whether you
> shop
> >> in
> >> Amazon is not relevant; you should not be dictating what is acceptable
> and
> >> what is not. This is about what everybody else thinks about the data
> that
> >> will
> >> be collected from their computers into your database. I feel some
> >> inexplicable
> >> reluctance to accept you should seek permission to do so. Why?
> >>
> >> > 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).
> >>
> >> You might think it is an innocent plugin count. Here is another possible
> >> abuse
> >> of the data:
> >> Let's say I write a new plugin called cell_scanner. My name appears in
> the
> >> plugin pages. Can you guess who's computer will show a spike in its use
> >> during
> >> the development and debug time together with a location, language and
> >> "etc."
> >> of where it happened? Then because every IJ2 install gets a unique
> >> identifier
> >> based on the hash of the username and mac address, for the rest of the
> >> life of
> >> my network card it will be logged when my computer runs IJ2, at 1hr
> >> intervals
> >> and when I close it. Now that will be in a database and shared with the
> >> world,
> >> and you think that I should not have an option to actively agree? How
> >> naive is
> >> that?
> >>
> >> > So, this is embarrassing, but I completely forgot about my own commit
> >> > <
> >>
> https://github.com/imagej/imagej/commit/49d6bc1f8491a4fe41101f88588895dc851
> >> > 041ad> 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.
> >>
> >> No, it is not the same. You need to *ask*, so users give you *informed
> >> consent*. That is one of the basic requirements of data collection.
> >> You know that people might not read EULAS or long documents when in an
> >> hurry.
> >> You need to make them aware so they can decide if they are happy to be
> >> tracked.
> >> It needs to be a question, a dialog, with a check box so people have to
> >> click
> >> on it to agree the first time that this is implemented or IJ installed
> and
> >> when you delete the prefs file, where the choice is stored.
> >>
> >> > 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.
> >>
> >> Not a document. A dialog with a check box, so the act of clicking on it
> >> gives
> >> you some indication that the users want it. You do not need it every
> day.
> >> If
> >> users change their mind they can revert to non-private mode easily.
> >>
> >> I repeat what Stephan S said: by not giving a choice it looks like it
> aims
> >> to
> >> dupe the clueless. Then you said that if you ask it will result in less
> >> people
> >> allowing tracking and that is not good... So this could be seen as not a
> >> completely ethical approach.
> >> Here we need to submit all our scientific projects to ethical review and
> >> they
> >> *always* insist that we abide by the principles of the ICO and we need
> to
> >> be
> >> explicit about it. Even with anonymised data. What you are planning
> falls
> >> short of several of those principles (no informed consent, no specified
> >> period
> >> for collection of data [is this for eternity?], no clear explanation of
> >> what
> >> the data is collected for, no recourse to delete entries from the
> database
> >> if
> >> somebody change their mind, transfer of data outside the EU, just to
> name a
> >> few). I am sure that this is not intentional, but lack of intention does
> >> not
> >> make it right or acceptable.
> >>
> >> > 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.
> >>
> >> IJ2 data tracking is quite a change from the previous behaviour of IJ,
> and
> >> it
> >> is one that could affect users without clear evidence of how it will
> >> benefit
> >> them.
> >>
> >> > 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?
> >>
> >> You need to ask permission to *collect* the data, not to upload...
> >> I hope IJ2 would not be collecting the data anyway and just not
> uploading?
> >> Why is this built in in IJ2 and not a separate plugin?
> >>
> >> The more I hear about this the less I like it. I am very disappointed by
> >> this
> >> unexpected change of scope in the IJ2 project which until now seemed
> very
> >> promising. This should be put right as a matter of urgency.
> >>
> >> Regards
> >>
> >> Gabriel
> >>
> >> --
> >> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >>
> >
> >
> >
> > --
> >
> > CEO: Dr. rer. nat. Jan Brocher
> > phone:  [phone]
> > mobile: [phone]
> > 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
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Tuesday 12 Aug 2014 06:56:33 Kevin W Eliceiri wrote:

> On behalf of all parties involved in the ImageJ2 project, I want to announce
> we understand the concerns raised and as such will make any user data
> collection in ImageJ2 strictly opt in with a clear message. We were just
> using the same approach that has served FIJI well in collected anonymized
> metrics for overall usage reporting purposes such as grants. But we are
> listening and understand the privacy concerns and as such will put a new
> ImageJ2 release out shortly that will have a clear opt in for those that
> want to help with reporting effort. For those that decide to optin this
> will beG just tracking location information and strictly used for supporting
> funding efforts such as we already do with FIJI.
>
> Please consider this issue addressed, and always we appreciate all the
> discussion and efforts that make the ImageJ community great.

Lets go further.
Since this thread started, the concerns have changed. Kees made it clear that
there might be legal issues which seem that have not been fully thought by the
devel team.

I fully understand that developers *want* to track plugin usage, but it is not
really a requisite for funding and it is not a requisite for IJ functionality
either. IJ was developed by one person and supported by a great community to
become the most successful imaging platform, so the actual  tracking "need"
argument is weak. Everybody knows IJ. You can justify how great IJ2 is by many
other means.

If IJ2 starts getting labelled as a spy/tracking software, it will do no good
for further funding or for attracting new users. This is publicity that you do
not want at all.

So, I would like to second Albert's proposal to remove all user tracking
commits from the main IJ2 trunk and if the developers think it is necessary
create (as Dimiter mentioned) a specific plugin that collects the data
exclusively from those who actively want to help. Then users can provide data
at their own risk without affecting the rest who do have a concern.

That should remove any uncertainties users might have as to what IJ2 is doing
in the background, including privacy flags getting set or reset by mistake or
by careless macros and plugins.

I appreciate that this might not be exactly what the developers want to hear,
but I doubt there is another way of undoing the concerns that have been
raised.

I would like to encourage other users to support Albert's suggestion.

Regards

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Herbie-4]

Kevin,

thanks for the clarification!

[...]strictly used for supporting funding efforts[...]

So, that's the reason again and Mark's generalizations are neutralized?

I very much should like to see that the ImageJ-2 developer team declares
that they are not tracking or data collecting for funding purposes. All
funding agencies should know that tracking or data collecting for
whatever purpose can be abused.

Those who agree with tracking or data collecting for funding purposes
are opening doors for actions that may return badly.

Again, let those who want to see user statistics write plugins that, in
case, need to be installed by the users. If this harms the desired
statistics, so what, you get a statistic of users who are actively
supporting tracking or data collecting.

Please omit any tracking or data collecting options from ImageJ-2.

Best regards

Herbie

::::::::::::::::::::::::::::::::::::::::::
On 12.08.14 13:56, Kevin W Eliceiri wrote:

> Hi All,
>
>
> On behalf of all parties involved in the ImageJ2 project, I want to
> announce we understand the concerns raised and as such will make any
> user data collection in ImageJ2 strictly opt in with a clear message.
> We were just using the same approach that has served FIJI well in
> collected anonymized metrics for overall usage reporting purposes
> such as grants. But we are listening and understand the privacy
> concerns and as such will put a new ImageJ2 release out shortly that
> will have a clear opt in for those that want to help with reporting
> effort. For those that decide to optin this will be just tracking
> location information and strictly used for supporting funding efforts
> such as we already do with FIJI.
>
>
> Please consider this issue addressed, and always we appreciate all
> the discussion and efforts that make the ImageJ community great.
>
>
> all the best kevin
>
> On 08/12/14, "Doube, Michael"  wrote:
>> Dear Listers
>>
>> On 11/08/14 22:59, Gabriel Landini wrote:
>>> My issue was (and remains) that data collection needs to be fully
>>> informed before it takes place, not to be On by default.
>>
>> I'm responding here because I have a great deal of respect for your
>> frank opinions.
>>
>> For some time now, BoneJ users have had the option to 'opt-in' to
>> data collection.
>>
>> When the user first runs a plugin from the BoneJ suite, a dialog
>> pops-up with information about what data are collected, where they
>> go, how they are processed, and what for (in line with the UK Data
>> Protection Act). Then the user has to click OK to allow data
>> collection, Cancel if they don't want to and Help if they want more
>> information, which is here:
>>
>> http://bonej.org/stats
>>
>> and the code is here:
>>
>> https://github.com/mdoube/BoneJ/blob/master/src/org/doube/util/UsageReporter.java
>>
>>

https://github.com/mdoube/BoneJ/blob/master/src/org/doube/util/ReporterOptions.java

>>
>> I was pretty concerned about doing this with as much respect for
>> user privacy as possible, because that is something I care about
>> personally too. It has been gratifying that quite a number of users
>> (some hundreds, I think, including me) have chosen to opt-in, and
>> allowed us to count by now millions of plugin runs. I hope that
>> people who are uncomfortable about this data collection - for
>> whatever, or no, reason - would continue to use the software
>> confident that we take their opt-out seriously. And if they wanted
>> a disconnected version which doesn't know how to phone home, they
>> are welcome to ask for it (it would be easy to do), or make it
>> themselves.
>>
>> The primary use for these data has been to apply for (competitive,
>> hard-to-win) funding so that we can hire someone to maintain and
>> improve the software, which I can't commit to as well as I could
>> when I was a postdoc. Summary statistics have been used in a ~£700k
>> bid to BBSRC (only just out of the money, unfortunately). The grant
>> panel was very impressed by the level of usage which we were able
>> to demonstrate with these collated user data, so it did make a
>> difference, and we plan to do something similar with Wellcome Trust
>> later this year (successful, this time, I hope...).
>>
>> The other use is to identify patterns of work that we can help to
>> improve - so if someone always runs plugin A followed by B and C,
>> perhaps we can put those together a bit better. If no-one is using
>> it on Mac OS version whatever, maybe it is broken there and no-one
>> told us (silence does not equate to satisfaction).
>>
>> I tried very hard to do this as transparently as possible. Logging
>> was announced on the mailing list, the code and all its changes are
>> available, the user has to make a choice to opt-in or -out, and can
>> do so at any point. Quitting the dialog by reflexive hitting Esc
>> key opts-out. The data which are transmitted can be examined in the
>> log window. Opting out clears local data. It only sends data on a
>> live network connection - if you are disconnected no report is ever
>> sent.
>>
>> On release, I braced myself for an outcry like the current one
>> around ImageJ2, but there was none - but maybe the unhappy people
>> just went away rather than sharing their opinions - which I'd
>> really like to hear, because that is how we can make it better. So
>> far I've had no negative comments and lots of people opting in.
>> Naturally, I have no figures on opt-outs!
>>
>> My suggestion to the ImageJ2 team is that a great big annoying
>> difficult to ignore and easy to read opt-in screen is required if
>> you want to include phone-home functionality (as Eclipse does, for
>> example). As Gabriel stated, people need to actively grant
>> permission for the software to send their data - permission must
>> not be passively assumed, otherwise you set up a nasty trust/power
>> dynamic.
>>
>> Best regards,
>>
>> Michael
>>
>> -- Dr Michael Doube BPhil BVSc PhD MRCVS Lecturer, Comparative
>> Biomedical Sciences The Royal Veterinary College, University of
>> London London NW1 0TU United Kingdom
>>
>> [phone] (Internal: 5503)
>>
>> <http://www.rvc.ac.uk>
>>
>> This message, together with any attachments, is intended for the
>> stated addressee(s) only and may contain privileged or confidential
>> information. Any views or opinions presented are solely those of
>> the author and do not necessarily represent those of the Royal
>> Veterinary College.
>>
>> -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> -- Kevin W. Eliceiri Director, Laboratory for Optical and
> Computational Instrumentation (LOCI) Departments Cell and Molecular
> Biology and Biomedical Engineering Affiliate Principal Investigator,
> Morgridge Institute for Research (MIR) Room 271 Animal Sciences, 1675
> Observatory Drive, Madison, WI 53706 Phone: [phone]
>
> -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kevin W Eliceiri-2]

Hello All,

This feature of reporting geographically (that all we were doing) who uses ImageJ2 is not a important feature to us, just a useful thing that has served the FIJI community well for some time. Given the strong response we will remove all tracking and usage collecting in ImageJ2. This will be in the next release.


best
kevin

On 08/12/14, Herbie  wrote:

> Kevin,
>
> thanks for the clarification!
>
> [...]strictly used for supporting funding efforts[...]
>
> So, that's the reason again and Mark's generalizations are neutralized?
>
> I very much should like to see that the ImageJ-2 developer team declares that they are not tracking or data collecting for funding purposes. All funding agencies should know that tracking or data collecting for whatever purpose can be abused.
>
> Those who agree with tracking or data collecting for funding purposes are opening doors for actions that may return badly.
>
> Again, let those who want to see user statistics write plugins that, in case, need to be installed by the users. If this harms the desired statistics, so what, you get a statistic of users who are actively supporting tracking or data collecting.
>
> Please omit any tracking or data collecting options from ImageJ-2.
>
> Best regards
>
> Herbie
>
> ::::::::::::::::::::::::::::::::::::::::::
> On 12.08.14 13:56, Kevin W Eliceiri wrote:
> >Hi All,
> >
> >
> >On behalf of all parties involved in the ImageJ2 project, I want to
> >announce we understand the concerns raised and as such will make any
> >user data collection in ImageJ2 strictly opt in with a clear message.
> >We were just using the same approach that has served FIJI well in
> >collected anonymized metrics for overall usage reporting purposes
> >such as grants. But we are listening and understand the privacy
> >concerns and as such will put a new ImageJ2 release out shortly that
> >will have a clear opt in for those that want to help with reporting
> >effort. For those that decide to optin this will be just tracking
> >location information and strictly used for supporting funding efforts
> >such as we already do with FIJI.
> >
> >
> >Please consider this issue addressed, and always we appreciate all
> >the discussion and efforts that make the ImageJ community great.
> >
> >
> >all the best kevin
> >
> >On 08/12/14, "Doube, Michael" wrote:
> >>Dear Listers
> >>
> >>On 11/08/14 22:59, Gabriel Landini wrote:
> >>>My issue was (and remains) that data collection needs to be fully
> >>>informed before it takes place, not to be On by default.
> >>
> >>I'm responding here because I have a great deal of respect for your
> >>frank opinions.
> >>
> >>For some time now, BoneJ users have had the option to 'opt-in' to
> >>data collection.
> >>
> >>When the user first runs a plugin from the BoneJ suite, a dialog
> >>pops-up with information about what data are collected, where they
> >>go, how they are processed, and what for (in line with the UK Data
> >>Protection Act). Then the user has to click OK to allow data
> >>collection, Cancel if they don't want to and Help if they want more
> >>information, which is here:
> >>
> >>http://bonej.org/stats
> >>
> >>and the code is here:
> >>
> >>https://github.com/mdoube/BoneJ/blob/master/src/org/doube/util/UsageReporter.java
> >>
> >>
> https://github.com/mdoube/BoneJ/blob/master/src/org/doube/util/ReporterOptions.java
> >>
> >>I was pretty concerned about doing this with as much respect for
> >>user privacy as possible, because that is something I care about
> >>personally too. It has been gratifying that quite a number of users
> >>(some hundreds, I think, including me) have chosen to opt-in, and
> >>allowed us to count by now millions of plugin runs. I hope that
> >>people who are uncomfortable about this data collection - for
> >>whatever, or no, reason - would continue to use the software
> >>confident that we take their opt-out seriously. And if they wanted
> >>a disconnected version which doesn't know how to phone home, they
> >>are welcome to ask for it (it would be easy to do), or make it
> >>themselves.
> >>
> >>The primary use for these data has been to apply for (competitive,
> >>hard-to-win) funding so that we can hire someone to maintain and
> >>improve the software, which I can't commit to as well as I could
> >>when I was a postdoc. Summary statistics have been used in a ~£700k
> >>bid to BBSRC (only just out of the money, unfortunately). The grant
> >>panel was very impressed by the level of usage which we were able
> >>to demonstrate with these collated user data, so it did make a
> >>difference, and we plan to do something similar with Wellcome Trust
> >>later this year (successful, this time, I hope...).
> >>
> >>The other use is to identify patterns of work that we can help to
> >>improve - so if someone always runs plugin A followed by B and C,
> >>perhaps we can put those together a bit better. If no-one is using
> >>it on Mac OS version whatever, maybe it is broken there and no-one
> >>told us (silence does not equate to satisfaction).
> >>
> >>I tried very hard to do this as transparently as possible. Logging
> >>was announced on the mailing list, the code and all its changes are
> >>available, the user has to make a choice to opt-in or -out, and can
> >>do so at any point. Quitting the dialog by reflexive hitting Esc
> >>key opts-out. The data which are transmitted can be examined in the
> >>log window. Opting out clears local data. It only sends data on a
> >>live network connection - if you are disconnected no report is ever
> >>sent.
> >>
> >>On release, I braced myself for an outcry like the current one
> >>around ImageJ2, but there was none - but maybe the unhappy people
> >>just went away rather than sharing their opinions - which I'd
> >>really like to hear, because that is how we can make it better. So
> >>far I've had no negative comments and lots of people opting in.
> >>Naturally, I have no figures on opt-outs!
> >>
> >>My suggestion to the ImageJ2 team is that a great big annoying
> >>difficult to ignore and easy to read opt-in screen is required if
> >>you want to include phone-home functionality (as Eclipse does, for
> >>example). As Gabriel stated, people need to actively grant
> >>permission for the software to send their data - permission must
> >>not be passively assumed, otherwise you set up a nasty trust/power
> >>dynamic.
> >>
> >>Best regards,
> >>
> >>Michael
> >>
> >>-- Dr Michael Doube BPhil BVSc PhD MRCVS Lecturer, Comparative
> >>Biomedical Sciences The Royal Veterinary College, University of
> >>London London NW1 0TU United Kingdom
> >>
> >>[phone] (Internal: 5503)
> >>
> >><http://www.rvc.ac.uk>
> >>
> >>This message, together with any attachments, is intended for the
> >>stated addressee(s) only and may contain privileged or confidential
> >>information. Any views or opinions presented are solely those of
> >>the author and do not necessarily represent those of the Royal
> >>Veterinary College.
> >>
> >>-- ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
> >-- Kevin W. Eliceiri Director, Laboratory for Optical and
> >Computational Instrumentation (LOCI) Departments Cell and Molecular
> >Biology and Biomedical Engineering Affiliate Principal Investigator,
> >Morgridge Institute for Research (MIR) Room 271 Animal Sciences, 1675
> >Observatory Drive, Madison, WI 53706 Phone: [phone]
> >
> >-- ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
Kevin W. Eliceiri
Director, Laboratory for Optical and Computational Instrumentation (LOCI)
Departments Cell and Molecular Biology and Biomedical Engineering
Affiliate Principal Investigator, Morgridge Institute for Research (MIR)
Room 271 Animal Sciences, 1675 Observatory Drive, Madison, WI 53706
Phone: [phone]

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Tiago Ferreira-2]

On Tuesday 12 Aug 2014 09:47 Gabriel Landini wrote:
> Lets go further.

I’m also disappointed by the fact that the optin was not adopted in the first place but that is not why I’m chiming in. I just wanted to add some notes to the discussion (I do apologize if I’m stating the obvious here):
In short: The arguments in favor of usage tracking are twofold: 1) To impress granting agencies and 2) To help developers to get a sense for the community needs and priorities.

On 1): No matter what, granting agencies are likely to prefer the number of citations ImageJ receives to any other usage-based metric. After all, citation-based metrics are the norm when assessing scientific productivity (perhaps that should not be the case[1], but that is a whole other discussion). Just by looking at some reports e.g. [2] and [3], it becomes easily predictable that IJ is indeed, the de facto standard in scientific image processing.
Plugins and algorithms that cannot be traced to a single publication can (and should) be referenced by Zenodo DOIs ([4],[5]). These are citable (thus, traceable) and are a great step towards the idea of a more reproducible IJ.
Sure, we all know that we the official record is an underestimation of the real usage (at least in the biosciences), because biologists tend to be sloppy when describing their methods, but that just needs a mentality change, that all of us (as authors and reviewers) could start changing right now.

On 2): I wonder if  this is not one of those “if it ain’t broken don’t fix it” issues. IJ as a project seem to have succeeded at gathering suitable feedback from its users from resources such as this mailing list. Now, it could be that email-based feedback has become a burden to core developers, who get diverted from real coding, and other approaches expediting user feedback should be implemented. But, if that is the case, than perhaps we should be discussing that instead?

I’d also be curious to know how other projects (CellProfiler, Icy, microManager, KNIME, etc...) have dealt with these issues...

Thanks to all for the discussion,
-tiago

[1] http://kingsreview.co.uk/magazine/blog/2014/02/24/
[2] http://fiji.sc/Publications
[3] http://imagej.nih.gov/ij/docs/guide/146-References.html#References
[4] http://zenodo.org/
[5] https://guides.github.com/activities/citable-code/

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Gabriel Landini]

On Tuesday 12 Aug 2014 10:24:39 Kevin W Eliceiri wrote:
> This feature of reporting geographically (that all we were doing) who uses
> ImageJ2 is not a important feature to us, just a useful thing that has
> served the FIJI community well for some time. Given the strong response we
> will remove all tracking and usage collecting in ImageJ2. This will be in
> the next release.

Thank you Kevin, Mark et al for removing the tracking features.

It was very reassuring that the development team listened to the community
concerns and actions took place quickly.

Something that is important to keep in mind for the future collection of
feedback and usage is that it is not our personal views on privacy that
dictate what to collect and how to handle other people's information. In most
countries, collecting data from others requires a number of principles to be
followed.

Separating usage tracking (not an imaging function) from the IJ2 core is
therefore a step towards guaranteeing that no issues will unexpectedly arise
in the future.
This will help keeping the good name of ImageJ, the developers and their
institutions (which in the end are the legal responsible of data safeguard) in
high esteem.

*That* is something that funders and users will appreciate more than a map
with icons.

Thank you again.

Best wishes,

Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Dimiter Prodanov (imec)]

Dear Kevin and IJ2 developers,

Thanks for the prompt response in disabling use/user tracking functionality in IJ2.
While I do not doubt the noble intentions of the IJ2 developers my experience so far shows that ideas/ functionality can find application quite far away from the original intentions. After all, we people are quite inventive.
Therefore, decisions having potentially wide impact on the community should be taken by some kind of community social process (i.e. democratic way, consensus , to name but a few).
On the other hand, in my opinion, the hot discussion from these 2 days points out a generic weakness of ImageJ development at present.
We do not have a community-based process for road mapping and deciding upon the functionality of ImageJ.
ImageJ (1) is originally developed and maintained by Wayne who is the gatekeeper/guru of the process and of ImageJ.
Your team aspires for such a role, which is admirable, but you do not (yet) have the support of the whole community of developers and users.
I think that IJ2 is a great idea and goal but unless you involve more the community in the development/support process the impact will not match your expectations.
In my opinion we, as a community, need a process by which we roadmap and steer the development of ImageJ.
Examples of good practices are all around us (Apache, PHP, IEEE standards etc. to name but a few) so we can adapt them to our culture of development and decision making.
It is not necessary to "(re)discover the hot water".
I think it is time to start a discussion about such a process.

Best regards,

Dimiter


--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[John Hayes]

Hi all,

I would just like to add that, as a somewhat naive developer/user of
ImageJ-family software (but big advocate of 'Open Source' software yet
with intimate knowledge of the IJ1 base), I support Dimiter's ideas
while still particularly commending Wayne, the IJ2 and Fiji
developers, for building such a robust community that it may require
more formal road-map organization. Wayne's original efforts have met
with formidable success IMO, and I think we forget that sometimes!

I particularly like the distinction Fiji makes with regards to Fiji as
being analogous with a Linux distribution (i.e., IJ1 but 'bolts
included'); Wayne's IJ1 is the kernel a la the Linux kernel --
beautiful!

I unfortunately miss ImageJ conferences and don't know how IJ2 is
related to IJ1 (a la Wayne -- which is because I believe he's with NIH
and producing 'public domain' code -- not 'Open Source' per se) --
IJ2: it sounds like you're doing cool things with the API, but I
haven't delved deeper yet I'm sorry because IJ1's code is very
clean/smart IMO for Java and my needs so far.

But I'm a big believer in the GPL (I LOVE Linux) and Open Source, and
I think the difference in licenses in the different distributions
confuses people (inextricably) from outside the programming world (or
even naive me at least).

Should there be an 'independent' mailing list for these
meta-ImageJ-community (IJ1/IJ2/Fiji, etc?) issues that could
coordinate these things (roadmap?) without bothering simple users?
There was relatedly similar complaints about the lack of feedback on
the community conferences -- maybe these sort of meta issues could be
best dealt with on a separate mailing list where presumably the
readers would be better informed (perhaps myself included)?

Just my 2c, and all the best as I love the spirit for generating good
science I'm seeing on this list!

John

On Wed, Aug 13, 2014 at 3:07 PM, Dimiter Prodanov (imec)
<[hidden email]> wrote:

> Dear Kevin and IJ2 developers,
>
> Thanks for the prompt response in disabling use/user tracking functionality in IJ2.
> While I do not doubt the noble intentions of the IJ2 developers my experience so far shows that ideas/ functionality can find application quite far away from the original intentions. After all, we people are quite inventive.
> Therefore, decisions having potentially wide impact on the community should be taken by some kind of community social process (i.e. democratic way, consensus , to name but a few).
> On the other hand, in my opinion, the hot discussion from these 2 days points out a generic weakness of ImageJ development at present.
> We do not have a community-based process for road mapping and deciding upon the functionality of ImageJ.
> ImageJ (1) is originally developed and maintained by Wayne who is the gatekeeper/guru of the process and of ImageJ.
> Your team aspires for such a role, which is admirable, but you do not (yet) have the support of the whole community of developers and users.
> I think that IJ2 is a great idea and goal but unless you involve more the community in the development/support process the impact will not match your expectations.
> In my opinion we, as a community, need a process by which we roadmap and steer the development of ImageJ.
> Examples of good practices are all around us (Apache, PHP, IEEE standards etc. to name but a few) so we can adapt them to our culture of development and decision making.
> It is not necessary to "(re)discover the hot water".
> I think it is time to start a discussion about such a process.
>
> Best regards,
>
> Dimiter
>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Dimiter,

> In my opinion we, as a community, need a process by which we roadmap
> and steer the development of ImageJ.

I suggest reading OSS Watch's article on governance models for some
grounding on this topic:
    http://oss-watch.ac.uk/resources/governancemodels

ImageJ2 and Fiji are Bazaar style projects -- i.e.: very open to community
contributions. Anyone can open an issue or pull request on GitHub to
propose or implement changes, which can then be discussed publicly by the
community. Even better: anyone can create an ImageJ update site and release
their plugins to the community, making them available at the check of a
box. And anyone can improve the documentation by editing the wiki.

In short: the development directions of the project are whatever motivated
parties choose to work on.

Regards,
Curtis

P.S. Further reading:
http://oss-watch.ac.uk/resources/howtobuildcommunity
http://oss-watch.ac.uk/resources/rolesinopensource


On Wed, Aug 13, 2014 at 8:07 AM, Dimiter Prodanov (imec) <
[hidden email]> wrote:

> Dear Kevin and IJ2 developers,
>
> Thanks for the prompt response in disabling use/user tracking
> functionality in IJ2.
> While I do not doubt the noble intentions of the IJ2 developers my
> experience so far shows that ideas/ functionality can find application
> quite far away from the original intentions. After all, we people are quite
> inventive.
> Therefore, decisions having potentially wide impact on the community
> should be taken by some kind of community social process (i.e. democratic
> way, consensus , to name but a few).
> On the other hand, in my opinion, the hot discussion from these 2 days
> points out a generic weakness of ImageJ development at present.
> We do not have a community-based process for road mapping and deciding
> upon the functionality of ImageJ.
> ImageJ (1) is originally developed and maintained by Wayne who is the
> gatekeeper/guru of the process and of ImageJ.
> Your team aspires for such a role, which is admirable, but you do not
> (yet) have the support of the whole community of developers and users.
> I think that IJ2 is a great idea and goal but unless you involve more the
> community in the development/support process the impact will not match your
> expectations.
> In my opinion we, as a community, need a process by which we roadmap and
> steer the development of ImageJ.
> Examples of good practices are all around us (Apache, PHP, IEEE standards
> etc. to name but a few) so we can adapt them to our culture of development
> and decision making.
> It is not necessary to "(re)discover the hot water".
> I think it is time to start a discussion about such a process.
>
> Best regards,
>
> Dimiter
>
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi John,

> I unfortunately miss ImageJ conferences and don't know how IJ2 is
> related to IJ1

See these wiki pages:
http://imagej.net/ImageJ
http://imagej.net/ImageJ2

> IJ2: it sounds like you're doing cool things with the API, but I
> haven't delved deeper yet I'm sorry because IJ1's code is very
> clean/smart IMO for Java and my needs so far.

There is no need to apologize. The goal of ImageJ2 is largely to expand
ImageJ to encompass new use cases -- since ImageJ1 handles your use case
well, that is great.

> I think the difference in licenses in the different distributions
> confuses people (inextricably) from outside the programming world

Have you seen choosealicense.com? It is a great site for concisely
explaining the more popular licensing options.

> Should there be an 'independent' mailing list for these
> meta-ImageJ-community (IJ1/IJ2/Fiji, etc?) issues that could
> coordinate these things (roadmap?) without bothering simple users?

Yes, there are such lists:
http://imagej.net/mailman/listinfo/imagej-devel
http://groups.google.com/group/fiji-devel

See also: http://imagej.net/Mailing_Lists

Regards,
Curtis


On Wed, Aug 13, 2014 at 12:59 PM, John Hayes <[hidden email]> wrote:

> Hi all,
>
> I would just like to add that, as a somewhat naive developer/user of
> ImageJ-family software (but big advocate of 'Open Source' software yet
> with intimate knowledge of the IJ1 base), I support Dimiter's ideas
> while still particularly commending Wayne, the IJ2 and Fiji
> developers, for building such a robust community that it may require
> more formal road-map organization. Wayne's original efforts have met
> with formidable success IMO, and I think we forget that sometimes!
>
> I particularly like the distinction Fiji makes with regards to Fiji as
> being analogous with a Linux distribution (i.e., IJ1 but 'bolts
> included'); Wayne's IJ1 is the kernel a la the Linux kernel --
> beautiful!
>
> I unfortunately miss ImageJ conferences and don't know how IJ2 is
> related to IJ1 (a la Wayne -- which is because I believe he's with NIH
> and producing 'public domain' code -- not 'Open Source' per se) --
> IJ2: it sounds like you're doing cool things with the API, but I
> haven't delved deeper yet I'm sorry because IJ1's code is very
> clean/smart IMO for Java and my needs so far.
>
> But I'm a big believer in the GPL (I LOVE Linux) and Open Source, and
> I think the difference in licenses in the different distributions
> confuses people (inextricably) from outside the programming world (or
> even naive me at least).
>
> Should there be an 'independent' mailing list for these
> meta-ImageJ-community (IJ1/IJ2/Fiji, etc?) issues that could
> coordinate these things (roadmap?) without bothering simple users?
> There was relatedly similar complaints about the lack of feedback on
> the community conferences -- maybe these sort of meta issues could be
> best dealt with on a separate mailing list where presumably the
> readers would be better informed (perhaps myself included)?
>
> Just my 2c, and all the best as I love the spirit for generating good
> science I'm seeing on this list!
>
> John
>
> On Wed, Aug 13, 2014 at 3:07 PM, Dimiter Prodanov (imec)
> <[hidden email]> wrote:
> > Dear Kevin and IJ2 developers,
> >
> > Thanks for the prompt response in disabling use/user tracking
> functionality in IJ2.
> > While I do not doubt the noble intentions of the IJ2 developers my
> experience so far shows that ideas/ functionality can find application
> quite far away from the original intentions. After all, we people are quite
> inventive.
> > Therefore, decisions having potentially wide impact on the community
> should be taken by some kind of community social process (i.e. democratic
> way, consensus , to name but a few).
> > On the other hand, in my opinion, the hot discussion from these 2 days
> points out a generic weakness of ImageJ development at present.
> > We do not have a community-based process for road mapping and deciding
> upon the functionality of ImageJ.
> > ImageJ (1) is originally developed and maintained by Wayne who is the
> gatekeeper/guru of the process and of ImageJ.
> > Your team aspires for such a role, which is admirable, but you do not
> (yet) have the support of the whole community of developers and users.
> > I think that IJ2 is a great idea and goal but unless you involve more
> the community in the development/support process the impact will not match
> your expectations.
> > In my opinion we, as a community, need a process by which we roadmap and
> steer the development of ImageJ.
> > Examples of good practices are all around us (Apache, PHP, IEEE
> standards etc. to name but a few) so we can adapt them to our culture of
> development and decision making.
> > It is not necessary to "(re)discover the hot water".
> > I think it is time to start a discussion about such a process.
> >
> > Best regards,
> >
> > Dimiter
> >
> >
> > --
> > 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

[Dimiter Prodanov (imec)]

Hi Kurtis,

Obviously there is a "model mismatch" then because ImageJ has more Cathedral than Bazar type of model.
The fact that we are having  this discussion right now shows that there is also a perception mismatch between IJ2 and the rest of the community.
I would like to repeat that key decisions concerning the core of ImageJ should be taken after a thorough discussion in the community.
Otherwise everybody will end up developing a boutique project.

Best regards,

Dimiter


Date:    Wed, 13 Aug 2014 21:14:48 -0500
From:    Curtis Rueden <[hidden email]>
Subject: Re: Usage data collection (was: Re: ImageJ 2.0.0-rc-11 released)

Hi Dimiter,

> In my opinion we, as a community, need a process by which we roadmap
> and steer the development of ImageJ.

I suggest reading OSS Watch's article on governance models for some grounding on this topic:
    http://oss-watch.ac.uk/resources/governancemodels

ImageJ2 and Fiji are Bazaar style projects -- i.e.: very open to community contributions. Anyone can open an issue or pull request on GitHub to propose or implement changes, which can then be discussed publicly by the community. Even better: anyone can create an ImageJ update site and release their plugins to the community, making them available at the check of a box. And anyone can improve the documentation by editing the wiki.

In short: the development directions of the project are whatever motivated parties choose to work on.

Regards,
Curtis

P.S. Further reading:
http://oss-watch.ac.uk/resources/howtobuildcommunity
http://oss-watch.ac.uk/resources/rolesinopensource


--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html