Re: Packaging Jalview -- any general guidelines concerning privacy?
Hi Pierre,
On Thu, Nov 26, 2020 at 10:11:14PM +0100, Pierre Gruet wrote:
>
> I'm currently on the packaging of Jalview.
Take a big thumbs up for this!
> I would like to get some advice
> as Jalview upstream is collecting statistics on its use through the
> Internet. Basically this amounts to 4 things, I'm quoting/commenting their
> documentation:
>
>
> - 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 a lot for reading,
Thanks a lot for working on this!
Kind regards
Andreas.
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
--
http://fam-tille.de
Reply to: