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 <bobjolli...@gmail.com> 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.picker...@gmail.com>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 <larshe...@gmail.com >> > 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-us...@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~dhis2-users >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
