[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging Jalview -- any general guidelines concerning privacy?

Hi Andreas,

Le 27/11/2020 à 09:22, Andreas Tille a écrit :

Hi Pierre,

On Thu, Nov 26, 2020 at 10:11:14PM +0100, Pierre Gruet wrote:



>> [...]>>

- HTTP logs on the Jalview website
     We record IP addresses of machines which access the web site, either via
the browser when downloading the application, or when the Jalview Desktop
user interface is launched.

- Questionnaires, from time to time
     The questionnaire web service at
www.jalview.org/cgi-bin/questionnaire.pl is checked and a unique cookie for
the current questionnaire is stored in the Jalview properties file.

- The Jalview web services stack is contacted to retrieve the currently
available web services. All interactions with the public Jalview web
services are logged, but we delete all job data (input data and results)
after about two weeks.

- Google Analytics, used if user explicitly consents
     Since Jalview 2.4.0b2, the Jalview Desktop records usage data with
Google Analytics via the JGoogleAnalytics class.
     The Google Analytics logs for Jalview version 2.4 only record the fact
that the application was started, but in the future, we will use this
mechanism to improve the Desktop user interface, by tracking which parts of
the user interface are being used most often.
This all sounds like privacy violations from a Debian point of view - 
at least if this is implemented as default.

I would like to know if you have general practice or advice to give
concerning this: can we package as is or do we need to take some special
care about privacy?
If you have some pointers to provide me with, I will also be very happy.


I've never seen those things before.  The only thing set of packages
that was collecting user data systematically were those using
pp-popularity-contest.  This was some agreement with the lab where a
set of software was developed and where the funding was dependant from
the number of users.

Regarding Jalview the license permits us to change the code and to patch
this out.  While this would be probably the easiest means we could to in
the interest of our users it would probably be not fair against upstream.
I wonder whether it would be really hard to provide some kind of opt-in
mechanism that can be controlled via a debconf question.  However, if
this is really hard to implement I'd vote for patching things out in a
first update of this package and leave the enhancement for later.
Thanks for the detailed answer. Concerning the Google Analytics part, is uses a class that is not in Debian and is also poorly licensed in my opinion, so this will be deactivated in any case.
For the rest, I think I could join upstream so that a fair decision can be made. Maybe the popularity-contest information can be informative enough.
Anyway, although all that you said makes much sense, would you know of any assessment of Debian rules and priorities concerning privacy, beyond the DFSG? 




Thanks a lot for reading,


Thanks a lot for working on this!

Kind regards

       Andreas.


Best regards,
Pierre



PS: I have one more Java issue.  As the ITP bug #956838 shows there are
     some remaining JARs which I overlooked :-( in r-cran-rcdk.  If I
     remove these JARs the build fails with

** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for 'rcdk':
  .onLoad failed in loadNamespace() for 'rcdk', details:
   call: .jnew("org/openscience/cdk/formula/rules/NitrogenRule")
   error: java.lang.ClassNotFoundException
Error: loading failed
Execution halted


Its definitely a Java problem but somehow hidden in the R build system
and I have no idea where to ask how to fix

    https://salsa.debian.org/r-pkg-team/r-cran-rcdk



Acknowledged! I will answer in the bug thread.
Reply to: