unfortunately, many of the entries which were added to the blacklists in the early years of parabola, were not well documented, if documented at all - i have added some sanity checking to the blacklist generation script, to reject entries which do not specify some brief rationale and an associated bug report it would be a lot of work to re-evaluate all of the incomplete entries though; so that code is yet to be used - i have been trying in recent years to clarify them whenever i have reason to wonder myself - hopefully, they all will be clarified eventually; but in this case, i also could find no discussion about 'libgdata' - we should probalby elect this ticket as the bug reference for the 'libgdata' entry

i can only assume that there was some clear justification for each entry; but such vague rationales as: "it's unsafe and dangerous" should not satisfy anyone, as they fail to convey the justification, to both users and future maintainers

unfortunately, in this case, the upstream description is not much more helpful

https://wiki.gnome.org/Projects/libgdata

based only on the upstream description, it is not evident that this is a privacy concern, in that it is probably not itself an anti-feature, though it could possibly be used as one by some clients - also, it appars to be an interface to web APIs, which often require each user to configure their personal credentials, in order to be useful, even to access public data, which is all that most clients would want to do with them - if that is the case, it is clearly not an anti-feature; because it would not be possible to use it unintentionally - ironically, that frivilous requirement is the very thing that diminishes it's potential as an anti-feature

for those reasons, it should probably be removed from the blacklist, and each of its clients should be evaluated instead, to determine how the library is actually used - for example, if some client uses it to make un-attended connections (of the "phone-home" sort), then it could be considered as an anti-feature of that client, but not necessarily the libary

to add the the mystery, the blacklist entry for 'shotwell' supports the assumption that manual configuration (therefore explicit consent) is required; though the entry for 'gnome-online-miners' suggests that the other services are supported via 'libgdata'

for a concrete example, totem, as mentioned in the upstream description, uses it to search youtube (totem is not blacklisted BTW) - that is a legitimate use-case, and probably not a privacy concern; because presumably, it is only used if the user has firstly configured their youtube API credentials, and accessed only when the user explicitly searches youtube at runtime

for a practical example of a blacklisted package, i looked into this because i rebuilt 'claws-mail' - the arch 'claws-mail' package has 'libgdata' only as an optional dependency - the parabola 'claws-mail' replacement removes the optional recomendation and intentionally compiles out the ability to use 'libgdata' - as 'your-privacy' currently conflicts with 'libgdata', it necessarily precludes that functionality from activating anyways, even while using the arch package; so it seems to me that there is no reason to blacklist 'claws-mail'

again, i think that the best plan moving forward is the opposite: to determine if 'libgdata' may be removed from the blacklist, and only clients which use it as an anti-feaute would need to remain blacklisted