Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Paul Wise]

On Sun, Dec 29, 2019 at 12:42 AM Robie Basak wrote:

> I file serious bugs when I discover this kind of behaviour in Debian
> packages. I've come across this only twice, but I've never spent time
> actually looking, so perhaps there are many more?

I expect there are quite a few more, some listed on the wiki:

https://wiki.debian.org/PrivacyIssues

> I was unable to find anything in policy either, but I take the position
> that, if asked, Debian developers are likely to take a similar position,
> and it has just never come up because maintainers haven't (as far as I'm
> aware) objected to treating this behaviour as a serious bug. Has any
> maintainer specifically objected?

Please document objections on the wiki page if you see them.

> Here are mine:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778947
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935042

I have added these to the privacy usertag:

$ bts user debian-devel@lists.debian.org , usertags 778947 + privacy
$ bts user debian-devel@lists.debian.org , usertags 935042 + privacy

https://wiki.debian.org/PrivacyIssues#Reports

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Robie Basak]

On Thu, Dec 26, 2019 at 02:42:58PM +0900, Norbert Preining wrote:
> - check for updates of itself
> - check for updates of plugins
> - send UID, OS, program version, and the icon theme selected in the
>   program to the statistic site [1]

I file serious bugs when I discover this kind of behaviour in Debian
packages. I've come across this only twice, but I've never spent time
actually looking, so perhaps there are many more?

I was unable to find anything in policy either, but I take the position
that, if asked, Debian developers are likely to take a similar position,
and it has just never come up because maintainers haven't (as far as I'm
aware) objected to treating this behaviour as a serious bug. Has any
maintainer specifically objected?

Would it be worth trying to gather a list of the occasions that this has
taken place to see if a policy change might be warranted?

Here are mine:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778947
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935042

Robie

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Paul Wise]

On Fri, Dec 27, 2019 at 6:01 AM Norbert Preining wrote:

> Upstream states clearly what he is collecting, and the rest is obvious
> because displayed on start. No magic necessary.
> Also no hidden stuff, all is clearly stated and open.

That sounds reasonable then.

> What do you mean with "informed consent and correct behaviour"?

I would expect something like this: in the user interface (help menu
perhaps, or on first start), have a button "send usage feedback" (or
similar) that when pressed displays a page containing the exact data
set that is proposed to be sent, what other information is captured
(or expressly not captured) by the server (IP address etc if anything)
in the sending process, list information about what all that
information is used for (with a link to the stats etc) and buttons for
confirming sending the data and for cancelling sending.

> Would a clear statement in the NEWS file be enough?

That is unlikely to reach all users of the package, but would be
helpful if the data collection is opt-out rather than opt-in.

> I read through that case and I consider it quite different. In the Cura
> case quite a lot of information where sent, while in the Calibre case
> there is only a random ID, the OS (no specifics, just
> Linux/Windows/Mac), and the iconset selected (if any) which has
> influence only on the order of selectable iconsets in the menu ;-)
>
> No information about the library (not even the number of books).

Indeed, sounds fairly different. Is there any information about what
the random ID is, how it is generated and if it gets copied around in
sync scenarios?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Norbert Preining]

Hi Paul,

On Fri, 27 Dec 2019, Paul Wise wrote:
> I am wondering how you discovered these, was it just reading the
> upstream code/website or are you monitoring traffic on your machine?

Upstream states clearly what he is collecting, and the rest is obvious
because displayed on start. No magic necessary.
Also no hidden stuff, all is clearly stated and open.

> Personally, I don't like any of them enabled by default but with
> informed consent and correct behaviour the plugin update checks could
> be reasonable for the Debian package. The general update check isn't

What do you mean with "informed consent and correct behaviour"? Would a
clear statement in the NEWS file be enough?

> useful on Debian but could be for some of the upstream platforms that
> don't have system-wide package update checks.

Yes, I think this is something everyone agrees upon.

> In case you want to convince upstream to correct the behaviour, here
> is an example of somewhere that upstream was (eventually) convinced to

I read through that case and I consider it quite different. In the Cura
case quite a lot of information where sent, while in the Calibre case
there is only a random ID, the OS (no specifics, just
Linux/Windows/Mac), and the iconset selected (if any) which has
influence only on the order of selectable iconsets in the menu ;-)

No information about the library (not even the number of books).

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Paul Wise]

On Thu, Dec 26, 2019 at 5:52 AM Norbert Preining wrote:

> Calibre is normally doing the following checks:

I am wondering how you discovered these, was it just reading the
upstream code/website or are you monitoring traffic on your machine?

Personally, I think we need much more systematic auditing of these
sort of issues as more and more upstreams are adding update checks and
usage reporting and other statistics and telemetry. We also need
better tooling for discovering the issues, unfortunately nsntrace was
removed from Debian and opensnitch/unoon aren't packaged yet.

https://github.com/jonasdn/nsntrace/
https://github.com/kushaldas/unoon/
https://github.com/evilsocket/opensnitch/

> Which of the above actions are acceptable for Debian/main?

Personally, I don't like any of them enabled by default but with
informed consent and correct behaviour the plugin update checks could
be reasonable for the Debian package. The general update check isn't
useful on Debian but could be for some of the upstream platforms that
don't have system-wide package update checks.

In case you want to convince upstream to correct the behaviour, here
is an example of somewhere that upstream was (eventually) convinced to
make their telemetry much more reasonable, but IIRC their change of
heart about that was mainly due to the GDPR and not driven by their
developers being convinced by folks suggesting the change in the issue
tracker.

https://github.com/Ultimaker/Cura/issues/2810

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Norbert Preining]

Hi Jonas,

thanks for your -- interesting and funny - email ;-) I am not so much
for political discussions, but just for clarification:

> It is bad that a system installed purely from Debian - with all security 
> updates carefully applied and all security announcements carefully 
> followed - can be insecure due to tools bypassing Debian and doing its 
> own update mechanisms.

That would **not** happen automatically. No updates are pulled
automatically. The user **must** install plugins by himself to "infect"
his computer, and **must** update to increase the infection.

The only thing that happens is an information to the user that updates
are available.

So I hope you have one less worry, right? In case you never ever install
any infectious disease^Wplugin, you are free from governmental spying
and all the evil Satan send us!

Enjoy, and thanks for you comments!

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Russ Allbery]

Andrey Rahmatullin  writes:

> Maybe it's time to document it in the Policy.

I think it would be a good idea, but it's some work because of the edge
cases.  Some of the things found by the Lintian check are tedious to fix
(unless maybe we can write a tool?) and make it more annoying to package
some software for Debian, so we should be clear on the project consensus
on how much work we want people to do.  For example, documentation HTML
pages that load styles or JavaScript (for mobile support for instance)
from a CDN are a privacy leak, as are web applications whose web pages
similarly include CDN links.

To be clear, I think we probably do care about those things and do want to
ask people to change them and use JavaScript packaged in Debian, but it's
also important to not underestimate how much work that is, since the norm
in the web page world is to pin to specific versions of these JavaScript
libraries and common style files.

There are some other edge cases that are closer to Norbert's question.
For example, gnubg (which I package) uses www.random.org as a random
number source by default (the upstream default, for various reasons that
involve fewer arguments with people who are absolutely convinced gnubg
wins against human players because it cheats on dice).  I've not changed
that, but one could make an argument that's a privacy leak as well (and
feel free to convince me that I should change it).

-- 
Russ Allbery (r...@debian.org)  

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Adam Borowski]

On Thu, Dec 26, 2019 at 12:41:34PM +0100, Jonas Smedegaard wrote:
> All of those activities are problematic, because they leak privacy.
> 
> First point is useless for packaged software and the code should be 
> patched to skip it.
> 
> Second point is ideally useless as well, because plugins should be 
> packaged as well.
> 
> Third point is, for the user, useless as well.

A good part of plugins won't ever be packaged.  I have a strong opinion
about privacy, but security is also a concern.

Thus, I'd suggest a policy like:

A program may auto-update its plugins/etc only if a given origin has
been enabled; installing something from an origin may be considered by
default to be a consent to check for further updates from that origin.

For example, this is the behaviour of Apt: it enables by default
origin=Debian (or Ubuntu, Devuan, Mint...) if you install from that
distribution's media, plus any explicitly added apt sources.

For Firefox, it'd mean that polling for updates from mozilla.org should
(absent a non-default configuration to the contrary) be done if there's
at least one non-packaged extension installed.

> I recommend to patch to disable all three mechanisms.
> 
> ...but that's not what you asked about.
> 
> I don't think Debian forbid privacy-leaky behaviours.

Aye, I say we should add this at least to the Policy -- if not the Social
Contract.  I believe the Dissident's Test should apply to not just licenses,
but also to building and running packaged software.

> If you choose to not voluntarily disable these mechanisms for the Debian 
> packaging, then at least consider mention explicitly these behaviours in 
> long description, and list them at https://wiki.debian.org/PrivacyIssues

+1


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Andrey Rahmatullin]

On Thu, Dec 26, 2019 at 05:48:17PM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 26, 2019 at 08:48:44PM +0900, Norbert Preining wrote:
> > Yeah, agreed with you feeling, but I searched today the policy and
> > social contract etc etc, and I didn't find any regulation concerning it.
> There are lintian checks and I think that's all.
> Maybe it's time to document it in the Policy.
I've found only https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726998
but only the last message there is relevant.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Jonas Smedegaard]

Quoting Norbert Preining (2019-12-26 13:36:28)
> On Thu, 26 Dec 2019, Jonas Smedegaard wrote:
> > Second point is ideally useless as well, because plugins should be 
> > packaged as well.
> 
> Well, they aren't, and will never be packaged (unless someone steps in).
> So getting notified of updates - possible of security issues - is in
> principle a good point.

Let me dare paraphrase:

"Well, we will never have global peace (unless God or aliens step in). 
So monitoring our citizens - potential terrorists - is in principle a 
good point."

I agree there is a point in letting software phone home about updates to 
infections inflicted by those same tools, but it is a *bad* point.  
Better point is to not let the tool infect the system!

Yes: To me a tool which injects rogue and potentially insecure code into 
a Debian system is essentially infecting the system.

I disagree that it is a good point for packaged software to phone home 
about updates to infections inflicted by those same tools, and to me a 
tool which injects rogue and potentially insecure code into a Debian 
system is essentially infecting the system.

Makes sense for a system _without_ the governance of a distribution to 
let its tools self-govern, but such mechanisms are unsuitable in a 
system with governance - and potentially outright dangerous, because the 
user _expect_ the system-wide governance to work (not for the governance 
to knowingly let things go rogue).

It is bad that a system installed purely from Debian - with all security 
updates carefully applied and all security announcements carefully 
followed - can be insecure due to tools bypassing Debian and doing its 
own update mechanisms.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Andrey Rahmatullin]

On Thu, Dec 26, 2019 at 08:48:44PM +0900, Norbert Preining wrote:
> Yeah, agreed with you feeling, but I searched today the policy and
> social contract etc etc, and I didn't find any regulation concerning it.
There are lintian checks and I think that's all.
Maybe it's time to document it in the Policy.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Norbert Preining]

Hi Jonas,

thanks for the insightful comments!

On Thu, 26 Dec 2019, Jonas Smedegaard wrote:
> First point is useless for packaged software and the code should be 
> patched to skip it.

Agreed, and that is my plan.

> Second point is ideally useless as well, because plugins should be 
> packaged as well.

Well, they aren't, and will never be packaged (unless someone steps in).
So getting notified of updates - possible of security issues - is in
principle a good point.

> Third point is, for the user, useless as well.

Jein (as we say). Indirect it might be useful to increase the number of
linux users in the statistics, and thus also the valuation and support
of the linux platform. So there is a - I agree rather diffuse - use.


> ...but that's not what you asked about.

Good point.

> If you choose to not voluntarily disable these mechanisms for the Debian 
> packaging, then at least consider mention explicitly these behaviours in 
> long description, and list them at https://wiki.debian.org/PrivacyIssues

Sounds like a good plan. I looked into this page and saw basex, which
does exactly one of the above checking for upstream versions. That is in
fact the most useless point IMNSHO, as it does not help the user to get
a newer version.

Thanks for for your comments

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Jonas Smedegaard]

Quoting Tomas Pospisek (2019-12-26 11:26:26)
> On 26.12.19 06:42, Norbert Preining wrote:
> 
> > (please Cc)
> > 
> > are there any requirements or restriction what a program packaged in
> > Debian is allowed to do when starting up? Calibre is normally doing the
> > following checks:
> > - check for updates of itself
> > - check for updates of plugins
> > - send UID, OS, program version, and the icon theme selected in the
> >   program to the statistic site [1]
> > 
> > Which of the above actions are acceptable for Debian/main?
> > 
> > [1] https://calibre-ebook.com/dynamic/calibre-usage
> 
> The last point seems inacceptable to me if the user hasn't explicitly
> consented to it. Checking for updates might be annoying but is "OK" to me.

All of those activities are problematic, because they leak privacy.

First point is useless for packaged software and the code should be 
patched to skip it.

Second point is ideally useless as well, because plugins should be 
packaged as well.

Third point is, for the user, useless as well.

I recommend to patch to disable all three mechanisms.

...but that's not what you asked about.

I don't think Debian forbid privacy-leaky behaviours.

If you choose to not voluntarily disable these mechanisms for the Debian 
packaging, then at least consider mention explicitly these behaviours in 
long description, and list them at https://wiki.debian.org/PrivacyIssues

Thanks for bringing it up!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Holger Levsen]

On Thu, Dec 26, 2019 at 08:48:44PM +0900, Norbert Preining wrote:
> Do you have any pointer to some statement, policy, GR or so that forbids
> it?

Debian packages should behave as 'good citizens' and that includes not
spying on the user.

it's probably written down in some preamble or so.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Norbert Preining]

Hi Mattia,

On Thu, 26 Dec 2019, Mattia Rizzolo wrote:
> Considering this is debian, I'd probably say that none of those are
> acceptable without a proper consent for the user.  Opt-in flags in the

Yeah, agreed with you feeling, but I searched today the policy and
social contract etc etc, and I didn't find any regulation concerning it.

I mean, the UID sent is the one of the calibre installation, not the
device or anything else, it is purely an accumulation of how many
installations of calibre there are, and on which OS.

Pushing the numbers of Linux users a bit up would definitely help, so I
don't necessarily see it bad by default, but then ...

Do you have any pointer to some statement, policy, GR or so that forbids
it?

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Geert Stappers]

On Thu, Dec 26, 2019 at 11:26:26AM +0100, Tomas Pospisek wrote:
> On 26.12.19 06:42, Norbert Preining wrote:
> 
> > (please Cc)
> > 
> > are there any requirements or restriction what a program packaged in
> > Debian is allowed to do when starting up? Calibre is normally doing the
> > following checks:
> > - check for updates of itself
> > - check for updates of plugins
> > - send UID, OS, program version, and the icon theme selected in the
> >   program to the statistic site [1]
> > 
> > Which of the above actions are acceptable for Debian/main?
> > 
> > [1] https://calibre-ebook.com/dynamic/calibre-usage
> 
> The last point seems inacceptable to me if the user hasn't explicitly
> consented to it.

That does bring back memory of  kobo e-reader which did
a "phone home" on each page of the user license agreement.
I did bring back the device to the shop, got refund
and spend my money on another e-reader.

In other words: sending out user information is unacceptable.


> Checking for updates might be annoying but is "OK" to me.

Debian user did choose the Debian version, there is no need 
for a check on an update outside Debian.


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Mattia Rizzolo]

On Thu, Dec 26, 2019 at 11:26:26AM +0100, Tomas Pospisek wrote:
> > are there any requirements or restriction what a program packaged in
> > Debian is allowed to do when starting up? Calibre is normally doing the
> > following checks:
> > - check for updates of itself
> > - check for updates of plugins
> > - send UID, OS, program version, and the icon theme selected in the
> >   program to the statistic site [1]
> > 
> > Which of the above actions are acceptable for Debian/main?
> > 
> > [1] https://calibre-ebook.com/dynamic/calibre-usage
> 
> The last point seems inacceptable to me if the user hasn't explicitly
> consented to it. Checking for updates might be annoying but is "OK" to me.

Considering this is debian, I'd probably say that none of those are
acceptable without a proper consent for the user.  Opt-in flags in the
preference windows about "automatically checks for (plugins|program)
updates at startup" would do it….

Silently sending out details like UID, OS, etc is a no-go in my mind
though.

See also the history of chromium that had to patch away similar
features.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: requirements and regulations concerning upgrade checks/statistics callback on program start

[Tomas Pospisek]

On 26.12.19 06:42, Norbert Preining wrote:

> (please Cc)
> 
> are there any requirements or restriction what a program packaged in
> Debian is allowed to do when starting up? Calibre is normally doing the
> following checks:
> - check for updates of itself
> - check for updates of plugins
> - send UID, OS, program version, and the icon theme selected in the
>   program to the statistic site [1]
> 
> Which of the above actions are acceptable for Debian/main?
> 
> [1] https://calibre-ebook.com/dynamic/calibre-usage

The last point seems inacceptable to me if the user hasn't explicitly
consented to it. Checking for updates might be annoying but is "OK" to me.
*t

requirements and regulations concerning upgrade checks/statistics callback on program start

[Norbert Preining]

Hi everyone

(please Cc)

are there any requirements or restriction what a program packaged in
Debian is allowed to do when starting up? Calibre is normally doing the
following checks:
- check for updates of itself
- check for updates of plugins
- send UID, OS, program version, and the icon theme selected in the
  program to the statistic site [1]

Which of the above actions are acceptable for Debian/main?

[1] https://calibre-ebook.com/dynamic/calibre-usage

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13