Bug#632438: popcon wrongly claims to be anonymous

2013-05-09 Thread Christian PERRIER
Quoting Helmut Grohne (hel...@subdivi.de):

 Sorry, but given these issues I currently recommend not using popcon to
 people who ask me.


This discussion starts to annoy me, to say the least.

Could please ultra-paranoid people propose patches instead of telling
the popcon maintainer what he should do but not help home doing so?

I feel like my hair has been cut in four pieces many many many times
since I read popcon PTSand my bike has been painted in different
colours a few gazillion times. But I haven't seen many proposed
patches.






signature.asc
Description: Digital signature


Bug#632438: popcon wrongly claims to be anonymous

2013-05-09 Thread Bill Allombert
On Wed, May 08, 2013 at 06:07:36PM +0200, Helmut Grohne wrote:
 On Sun, May 05, 2013 at 02:57:12PM +0200, Bill Allombert wrote:
  I agree with the risk of deanonymization, however you have to look at the
  consequence: we only publish agregated results, not individual reports, so 
  this
  is only leaking whether someone is reporting or not, this does not leak the
  full list of packages, or the popcon UUID.
 
 You are missing a few pieces. There is a general principle of not
 collecting data that you don't need.

 Believe it or not, the popcon server may be compromised at a future
 time. We can defend now by not even collecting data that is not needed.

I completly agree with that, but if you look at the list of bug report, you
will see half of them ask for more information to be reported, and the other
half to report less information. So my only viable option is to keep the status
quo. This at least has the benefit of providing consistency and do not require
users to make new security/privacy deicision with each new popcon release.

 What about the actual data transfer? It usually works via http or smtp.
 Anyone sniffing the traffic can learn a lot from those little extra
 packages not to be found in the archive. Of course the traffic could be
 encrypted. Turning it harmless is another viable option though.

Yes there is plan to encrypt traffic. Mainly now it depends whether Debian is
willing to pay for the extra CPU time decrypting the reports.

 Finally I did find a number of corporate packages in popcon already.
 Packages that clearly belong to a particular institution or company. Now
 you learn that said institution uses Debian and popcon from the publicly
 visible popcon reports.

Could you give me some pointer to such packages (even privately if you prefer) ?
I have been considering allowing some packages to opt-out of popcon.

 Sorry, but given these issues I currently recommend not using popcon to
 people who ask me.

If you deal with people with strict security/privacy requirement, you are 
correct
to do so. I would do the same.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#632438: popcon wrongly claims to be anonymous

2013-05-08 Thread Helmut Grohne
On Sun, May 05, 2013 at 02:57:12PM +0200, Bill Allombert wrote:
 I agree with the risk of deanonymization, however you have to look at the
 consequence: we only publish agregated results, not individual reports, so 
 this
 is only leaking whether someone is reporting or not, this does not leak the
 full list of packages, or the popcon UUID.

You are missing a few pieces. There is a general principle of not
collecting data that you don't need.

Believe it or not, the popcon server may be compromised at a future
time. We can defend now by not even collecting data that is not needed.

What about the actual data transfer? It usually works via http or smtp.
Anyone sniffing the traffic can learn a lot from those little extra
packages not to be found in the archive. Of course the traffic could be
encrypted. Turning it harmless is another viable option though.

Finally I did find a number of corporate packages in popcon already.
Packages that clearly belong to a particular institution or company. Now
you learn that said institution uses Debian and popcon from the publicly
visible popcon reports.

Sorry, but given these issues I currently recommend not using popcon to
people who ask me.

Helmut


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#632438: popcon wrongly claims to be anonymous

2013-05-05 Thread Bill Allombert
On Mon, Oct 29, 2012 at 09:57:55AM +0100, Helmut Grohne wrote:
 I think the problem is worse than Paul Wise outlines. The package
 description claims anonymity. This is only true if it cannot be
 trivially defeated.
 
 The common use case for equivs is to create a package based on the
 hostname. Gladly popcon gives us numbers[1]. So about 8% of the
 submitters are using equivs. (Some machines will use packages generated
 using equivs without actually having installed equivs.) Let's assume
 that half of them employ a metapackage based on the hostname. The
 hostname is kind of public. It occurs in message-ids, bug reports, etc.
 So using this scheme we can almost trivially deanonymize 4% of the
 users.
 
 Another case is looking at packages whose versions are newer than sid or
 experimental. Most likely the machine owner is the maintainer or an
 uploader. This also works for mentors and for them probably even better,
 because their packages tend to wait for a long time until being
 uploaded. A quick grep on the maintainer field shows about 2000
 different maintainer addresses. Let's guess every fourth maintainer is
 using using pop-con and can be deanonymized using this technique.
 Another 0.5%.
 
 These numbers are low for the general but still alarming. The risk of
 being deanonymized is way higher for maintainers or developers unless
 they are aware of the problem an work around[2] it or simply remove
 popcon.

I agree with the risk of deanonymization, however you have to look at the
consequence: we only publish agregated results, not individual reports, so this
is only leaking whether someone is reporting or not, this does not leak the
full list of packages, or the popcon UUID.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#632438: popcon wrongly claims to be anonymous

2012-10-29 Thread Helmut Grohne
I think the problem is worse than Paul Wise outlines. The package
description claims anonymity. This is only true if it cannot be
trivially defeated.

The common use case for equivs is to create a package based on the
hostname. Gladly popcon gives us numbers[1]. So about 8% of the
submitters are using equivs. (Some machines will use packages generated
using equivs without actually having installed equivs.) Let's assume
that half of them employ a metapackage based on the hostname. The
hostname is kind of public. It occurs in message-ids, bug reports, etc.
So using this scheme we can almost trivially deanonymize 4% of the
users.

Another case is looking at packages whose versions are newer than sid or
experimental. Most likely the machine owner is the maintainer or an
uploader. This also works for mentors and for them probably even better,
because their packages tend to wait for a long time until being
uploaded. A quick grep on the maintainer field shows about 2000
different maintainer addresses. Let's guess every fourth maintainer is
using using pop-con and can be deanonymized using this technique.
Another 0.5%.

These numbers are low for the general but still alarming. The risk of
being deanonymized is way higher for maintainers or developers unless
they are aware of the problem an work around[2] it or simply remove
popcon.

Please remove the false anonymity claim until this is fixed as it leads
users into wrong beliefs. I therefore suggest upgrading severity to
rc-ness.

Imo the default for popcon should be only listing packages that
originate from Debian. Everything else is none of our business.

Unfortunately I cannot provide a solution or patch. For instance the
Origin field (in dpkg-query --showformat) does not help here. An option
might be to use aptitude search '~i ~ODebian' -F '%p'. (Thanks Paul!)
This would introduce a dependency on aptitude.

Helmut

[1] http://qa.debian.org/popcon.php?package=equivs
[2] http://bonedaddy.net/pabs3/log/2012/10/29/thoughts-on-debian-testing/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#632438: popcon wrongly claims to be anonymous

2012-10-29 Thread Paul Wise
On Mon, 2012-10-29 at 09:57 +0100, Helmut Grohne wrote:

 Imo the default for popcon should be only listing packages that
 originate from Debian. Everything else is none of our business.

I strongly disagree with this. The unknown packages index of popcon is
one of the most useful parts of it. It is useful sorting RFPs by number
of existing users on wnpp.debian.net. It is useful because all the
derivatives other than Ubuntu are currently submitting to popcon.d.o,
many of them include new packages that we might want to package and it
would be a good idea to gauge popularity before doing so. They also
reveal the extent to which Debian is not meeting the needs of our users
as well as the extent to which Debian users use external non-free
packages. IMO restricting the package set needs to be an explicit choice
on the part of the user.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part