dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Hi Lars,
What I mean by the IP being collected, is it "might" be collected (unless
you are careful) by your reverse proxy or upstream providers. Even though
whatever protocol you might come up with might not collect it, it would
require you to purposefully NOT collect it though unintentional means, such
as through the logs of your upstream proxies or by your ISP. Additionally,
 I think it needs to be crystal clear who the "DHIS core team" is, under
what laws they operate, and how it can be certified that such information
is not being collected (other than just saying that it is not being done).

I think the fact that many ministries and governments use DHIS2 is
particularly relevant in this case, because I have run up against a lot of
distrust of the whole cloud computing model which many implementers
(including myself) are using. Adding the possible collection of any data by
the "DHIS core team" to this, could further complicate already long
negotiations on the issue of hosting. Although the data which DHIS2
collects is generally not regarded to be secret, there have been instances
of which I personally know of, in which this is the case.  Since you have
stated the information would be open-source, it would mean that potentially
it could be used for research purposes, or other unknown (and possibly
nefarious)  purposes, which again, could complicate already sensitive
 discussions with some of the DHIS2 users.

So, I think until you make clear exactly what is going to done with the
data, who will manage and protect it,  I think the "opt in" model would be
the only really feasible option, and even then, make it exactly clear what
is going to be submitted and to whom and for what purpose.

Regards,
Jason



On Fri, Jun 28, 2013 at 6:21 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> Agree with Dan that a submit button on the about page (which previewed the
> information that would be sent) is better than ET calling home.
>
> Though we need to remain clear about the usage distinction of sharing with
> developers and feeding a more public repo.  Need to think a bit more.
>
>
> On 28 June 2013 17:10, Dan Cocos <dan@xxxxxxxxxxxx> wrote:
>
>> Perhaps it could be modeled after the Drupal Update Stats module. This
>> module generates simple stats that can be seen here.
>> https://drupal.org/project/usage/drupal you can read more about it here.
>> https://drupal.org/node/329620
>>
>> I'd also support a slightly more detailed optional submission as well
>> that does send OS, Java version, Web Server and database server, though
>> rather than it being a service that runs in the background there would be a
>> submit button on the About DHIS2 page. So it would be very clear what
>> information was being submitted and when that information was being
>> submitted. This information would be very help for the development team to
>> have a clear idea of the target DHIS2 environments and make sure they are
>> properly supported.
>>
>> Dan
>>
>> On Jun 28, 2013, at 11:54 AM, Lars Helge Øverland <larshelge@xxxxxxxxx>
>> wrote:
>>
>> Okay thanks for feedback.
>>
>> To clarify, for the "calling home" part we will only collect the DHIS 2
>> version (no IP, no Java version etc). In other words we will only register
>> that there exists a DHIS version out there with a given version. It will
>> not be possible to track it back to the IP.
>>
>> Then, what confuses me is; how could the fact that a government uses DHIS
>> 2 as their health system possibly be sensitive information or violate
>> country laws? It will already be a public Internet facing system, which
>> could be revealed through a google search; and with likely thousands of
>> users, knowing of its existence.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jun 28, 2013 at 5:24 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>wrote:
>>
>>> I agree with Jason on all counts so won't repeat them.
>>>
>>> A mandatory "ET call home" feature would not and should not be generally
>>> acceptable.  Besides which its not too clear how, or more pertinently,
>>> when, this exchange will happen.  On first boot?  Every boot.  Periodically?
>>>
>>> Anyway I don't like it and also worry that these things have a nasty
>>> habit of leading to scope creep.
>>>
>>> I think the idea of periodically scanning for releases and updates is
>>> good.  Also planning to integrate such behaviour in dhis2-tools.
>>>
>>> Bob
>>>
>>>
>>>
>>> On 28 June 2013 15:01, Jason Pickering <jason.p.pickering@xxxxxxxxx>wrote:
>>>
>>>> Hi Lars,
>>>>
>>>> I think it is important to get it right from the beginning. following
>>>> the lead of other big open source projects. It is critical to remember that
>>>> many of the organisations using DHIS2 are governments, and there could be
>>>> some possible sensitivies about the DHIS core team collecting any sort of
>>>> information.
>>>>
>>>> Before you go too far with this, I would think it would be good to
>>>> identify what the purpose (which you mention)  of collecting any data would
>>>> be, and spell it out very clearly, and why opting out would not be an
>>>> option.  I would also be clear about all of the legal technicalities,
>>>> including what county's law would regulate the collection of such
>>>> information.
>>>>
>>>> Even if you were not to collect the IP's, there is of course always the
>>>> possibility that they could be collected upstream. This might not be
>>>> directly the core team's worry, but it might be.
>>>>
>>>> Regards,
>>>> Jason
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jun 28, 2013 at 2:35 PM, Lars Helge Øverland <
>>>> larshelge@xxxxxxxxx> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> thanks for the good questions and comments.
>>>>>
>>>>> This information will be stored in some central system. The system
>>>>> will be managed by the DHIS core team. That system will be made open source
>>>>> so that anyone who feels like it could investigate it.
>>>>>
>>>>>
>>>>>>  Who would have access to the "sensitive" data like IP addresses of
>>>>>> the servers, i.e. the data which would not be publicly disclosed? Given
>>>>>> recent revelations in the news, how would possible data requests from third
>>>>>> parties be handled (such as a list of IP addresses for where DHIS2 is used)?
>>>>>>
>>>>>>
>>>>> We will simply not store IP addresses. We are not interested in them
>>>>> anyway, and to avoid any thinkable doubt of misuse or NSA inquiries we will
>>>>> not store them.
>>>>>
>>>>> I am thinking that for this function to have a purpose, it should not
>>>>> be possible to opt out of the very basic, anonymous data, like DHIS version
>>>>> and random system identifier. If optional then the statistics wouldn't be
>>>>> very useful. If that is not acceptable we would rather drop the feature. Of
>>>>> course, the "activation" feature with contact person etc would be
>>>>> completely optional and require that you actively enable it.
>>>>>
>>>>> One way to approach IP address security is to not record them anywhere
>>>>>> (and make sure the central server to which the data is sent does not keep
>>>>>> any log of them.) If the central server doesn't know the IP addresses, they
>>>>>> can't be divulged to any third party.
>>>>>>
>>>>>>
>>>>> Agreed.
>>>>>
>>>>>
>>>>>> A very different approach to openness and security is taken by the
>>>>>> optional OpenMRS "Atlas module". This opt-in module allows an OpenMRS
>>>>>> installation to provide information that is available in a public OpenMRS
>>>>>> "atlas" of implementations. The atlas can facilitate interactions between
>>>>>> OpenMRS community members, including prospective members, and it also
>>>>>> serves as publicity for OpenMRS as well as the implementers. I'll leave it
>>>>>> for others to say whether DHIS2 administrators would feel comfortable or
>>>>>> even welcome this kind of public information for their implementations. See
>>>>>> http://openmrs.org/atlas/ for the OpenMRS atlas itself, and
>>>>>> https://wiki.openmrs.org/display/docs/Atlas+Module+User+Guide for
>>>>>> the atlas module user guide.
>>>>>>
>>>>>
>>>>> Thanks for the tip, I will check out the atlas module for inspiration.
>>>>>
>>>>> Another idea for this concept: The DHIS instances could be checking
>>>>> with a central system whether new major versions of DHIS are available for
>>>>> download or whether any critical bugfixes are available for the current
>>>>> major version. This notifications could be made available through the DHIS
>>>>> messaging system and be sent to some group of system admin users.
>>>>>
>>>>>
>>>>> More comments are welcome.
>>>>>
>>>>> cheers
>>>>>
>>>>> Lars
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~dhis2-users
>>>> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dhis2-users
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-users
> Post to     : dhis2-users@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-users
> More help   : https://help.launchpad.net/ListHelp
>
>