Bug#735321: lintian: privacy-breach-logo exception for SourceForge etc

[Tony Houghton]

Package: lintian
Version: 2.5.21
Severity: wishlist

I'm getting privacy-breach-logo warnings for roxterm's HTML
documentation. I'm fairly sure it can only be my use of the Sourceforge
logo; there are no other img tags with external src:

<a id="SourceforgeLink" href="http://sourceforge.net/projects/roxterm"
title="RoxTerm Sourceforge">
<img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=124080&amp;type=8"
width="80" height="15"
alt="Get RoxTerm at SourceForge.net. Fast, secure and Free Open
Source software downloads" />
</a>

I don't think there should be any objection to using a SF logo this way
in a Debian package's documentation, so please could this tag have a
whitelist for SourceForge and other trusted hosting sites.

-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii binutils 2.24-2
ii bzip2 1.0.6-5
ii diffstat 1.58-1
ii file 1:5.14-2
ii gettext 0.18.3.1-2
ii hardening-includes 2.5
ii intltool-debian 0.35.0+20060710.1
ii libapt-pkg-perl 0.1.29+b1
ii libarchive-zip-perl 1.30-7
ii libclass-accessor-perl 0.34-1
ii libclone-perl 0.36-1
ii libdpkg-perl 1.17.5
ii libemail-valid-perl 1.192-1
ii libfile-basedir-perl 0.03-1
ii libipc-run-perl 0.92-1
ii liblist-moreutils-perl 0.33-1+b2
ii libparse-debianchangelog-perl 1.2.0-1
ii libtext-levenshtein-perl 0.06~01-2
ii libtimedate-perl 2.3000-1
ii liburi-perl 1.60-1
ii man-db 2.6.5-3
ii patchutils 0.3.2-3
ii perl [libdigest-sha-perl] 5.18.1-5
ii t1utils 1.37-2

Versions of packages lintian recommends:
ii libautodie-perl 2.22-1
ii libperlio-gzip-perl 0.18-1+b3
ii perl-modules [libautodie-perl] 5.18.1-5

Versions of packages lintian suggests:
pn binutils-multiarch <none>
ii dpkg-dev 1.17.5
ii libhtml-parser-perl 3.71-1+b1
pn libtext-template-perl <none>
pn libyaml-perl <none>
ii xz-utils 5.1.1alpha+20120614-2

-- no debconf information

[Russ Allbery]

Post by Tony Houghton
I'm getting privacy-breach-logo warnings for roxterm's HTML
documentation. I'm fairly sure it can only be my use of the Sourceforge
<a id="SourceforgeLink" href="http://sourceforge.net/projects/roxterm"
title="RoxTerm Sourceforge">
<img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=124080&amp;type=8"
width="80" height="15"
alt="Get RoxTerm at SourceForge.net. Fast, secure and Free Open
Source software downloads" />
</a>
I don't think there should be any objection to using a SF logo this way
in a Debian package's documentation, so please could this tag have a
whitelist for SourceForge and other trusted hosting sites.

The problem with this HTML code is that, every time a user visits this
HTML page in a browser, the browser contacts sourceforge.net to retrieve
the image and hands lots of information about the browser to Sourceforge.
This includes referrer information, so it provides Sourceforge with
tracking data about who is using roxterm. Generally, browsers provide
enough information to be uniquely identified even without cookies.

If the logo is free, you could include a copy directly in the source
package, which would avoid that problem. But I'm guessing it's not.

This is something that, by and large, the free software community hasn't
been thinking about much, but these sorts of apparently innocuous
remotely-sourced images are a key component of the pervasive commercial
surveillance architecture that underlies most of the ad-supported
companies. Individual pieces of data like this are, in isolation,
arguably not a big deal, but they're heavily aggregated and analyzed, and
the results can become rather disturbing.

Lintian is trying to get out in front of the problem, which is going to be
kind of painful, at least at first, since this is something that upstreams
have mostly not been paying close attention to.