Bug#632438: popcon wrongly claims to be anonymous
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. 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
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
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
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. 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
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
Bug#632438: popcon wrongly claims to be anonymous
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
