dhis2-devs team mailing list archive

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

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