dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

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