Felix Lechner <
felix.lechner@lease-up.com> writes:
The Policy Team was similarly reluctant. They have not acted on the
matter in nearly eight years. [3]
(The below is somewhat off the topic of the Lintian bug, which I know was
the original prompt for this message, and is more about the broader issue.
I'm not expressing an opinion on the merits of the Lintian tag, although I think reaching more of a consensus about the broader issue would help
inform a decisions about the tag, such as its severity.)
I'm not sure Policy is the appropriate place to talk about this in its
current state. Policy would be appropriate if there is a consensus in
Debian to ask all maintainers to modify upstream documentation that we
install to remove external images or external JavaScript.
There's some tricky nuance to that statement, so let me try to expand that carefully.
I think there is a consensus that we would all be very happy if upstream documentation did not contain such links that could be abused as trackers.
My belief from the previous discussions is that there are a few people who don't think this matters much, a few people who feel strongly about this
and are investing work into improving the situation, and a lot of people
who are uncomfortable with the existence of such things but are also not
very focused on it. If all such links went away without work by the maintainers, I think nearly everyone would be happy.
However, that's not precisely the question at hand. The question is
whether we are asking maintainers to take action to remove such things
from installed files. I think the implicit assumption here (and certainly
the assumption that I would make) is that most (not all) upstreams would
not be willing to take such patches, and some upstreams would be annoyed
by and opposed to such a change (often not, to be clear, because they are intending to use trackers as trackers, although I'm sure there is some of
that, but because things we consider trackers they believe are serving
some other purpose, such as linking to a donation site). Therefore, for
most packages, this would mean carrying Debian-local modifications and
some risk of upstream conflict.
That's a higher bar, since every modification of that type increases the maintenance load for maintainers and doesn't scale particularly well.
It's that practical concern -- the additional work burden that we would be asking maintainers to carry -- that I think is the root of the reluctance
that you're seeing and the lack of willingness to push forward with a
mandate or strong recommendation. In other words, I think this is a
trade-off question: the project has a certain capacity for work that we
ask maintainers to do, and if we ask them to spend time on one thing, this
will often mean they won't have time to spend on something else. Does
removing trackers rise to that level of request? This, I think, is less
clear.
One approach is to reduce the burden. If there were a highly reliable
tool that could be automatically run over installed files that would
remove all the abusable links with no negative effects on the quality of
the documentation when viewed locally and preserving clear and effective
paths for upstream maintainers to solicit donations to support their work,
I think it would be easy to arrive at a consensus that every package
should run that tool. My understanding is that people are working on developing such a tool but it doesn't exist in quite that reliable form
yet.
In the interim, one path forward would be for someone who cares strongly
about this area to write up a good guide for maintainers who have no
expertise here and not a lot of time but a willingness to do something
(this may already exist in the wiki), and then put that guide into the Developer's Reference (perhaps a "Best practices around privacy" section).
That gets the information about what to do into our technical
documentation and creates an on-ramp for elevating it to Policy advice and
then possibly a Policy recommendation as the tools improve.
--
Russ Allbery (
rra@debian.org) <
https://www.eyrie.org/~eagle/>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)