Felix Lechner <felix.lech...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
