> In response, Xiao pointed out that the package description can be read by any user who chooses to install the software, and it does mention the scan feature.
Wouldn't be the first (or last) time a Debian maintainer has pulled the "you should read the descriptions of all (hundreds) of your packages (most installed as dependencies)" card in response to a bug report.
If someone started reading all the package descriptions and READMEs we're meant to be thoroughly familiar with when Trixie was released a few days ago, they'd still be reading them.
“the plans and the demolition orders have been on display at the local planning office on Alpha Centauri for fifty of your Earth years. If you can't be bothered to take an interest in local affairs...”
We're not going to agree on that. The response is clearly there to point to a fig leaf instead of saying 'oh, oops, we will make this more obvious in the UI', the software is working as intended: as a way to gain access to more data.
Note that clipboard data can be just about anything and is a valuable dataset, more so if the source of the data isn't aware of being a source, besides, there is no history so you won't even know what you've lost.
Select to translate is almost a standard feature for translation software. Not sure if the situation gets better now, but back then the software was written, using clipboard as temporary storage is a very robust and maybe the only way to implement such feature.
Trivia: It's likely sending Ctrl+C and reading clipboard to get the selected text. No easy cross-platform API for this lol.
Also note that the software is very old and poorly maintained.
It's clearly a defensive excuse, as it is extremely unrealistic to expect final users to read all the docs of all the dependencies of a Linux distro. It's the responsibility of the maintainer to read the subset of docs relevant to the package(s) they're contributing, not the user's.
It could be that they were caught with their pants down and posted an ill-thought response, but I'd lean strongly towards malice with such a poor defense, it borders on confession. Clipboards are one of the most critical privacy/security features, you don't ever want to leak them unintentionally.
Did we already forget about the XZ Utils backdoor? There have to be multiple efforts to infiltrate backdoors in Linux going right now.
> It's the responsibility of the maintainer to read the subset of docs relevant to the package(s) they're contributing, not the user's.
I agree a lot with this. You're supposed to trust your distributions packages. If you can't trust your distro, who can you trust? If you don't, find one you do trust, as that's a viable alternative. If none are trustworthy to you, then the only real option is to become your own package maintainer and have fun with Linux From Scratch.
I disagree; it's basically lawyerspeak for "sucks to be you".
If one is expected to go through all the documentation of both the main package and all dependency packages, and also through whatever specific configuration details to your case, just to be able to catch a specific IMPORTANT detail that's not clearly spelled out in the main package, that's malicious.
"A dependency we use captures your clipboard data and sends it to remote servers"
That sentence right there would kill their userbase, so they omit warning you about it. And on top of the "...user should have read the description..." non-apology, "just split the packages, bro".
Finally, a rational argument from the torch and pitchfork crowd. Xiao is not taking security sensitivities to heart : HTTP?? To China‽ and a dismissive BS answer.
Hanlon's razor applies here, I think. It's just ignorance, not malice. I doubt the maintainer has connection, or was pressured by these two random dictionary websites to include this - nor do I think that they gain any advantage of it.
People need to be on the lookout though, the xz incident showed that FOSS is indeed vulnerable.
Not only is it outdated, the Nolnah's razor (reverse form of Hanlon) is more likely to be true nowadays: "Never attribute to incompetence that which is adequately explained by malice".
Wholesale violations of legal and social norms as the secret sauce that will give your company a leg up? Sure if we get caught the stockholders will have to pay to keep our asses out of jail. But we'll get to keep our share of the loot.
use TLS enabled dictionary service. if there is none, you dont want this feature. at all. make sure they click through something or explicitly enable is even hard as you cannot assume a user understands the impact. they might not understand what it means to send their data over plaintext, or what someone can do with it.
I don't want this feature with TLS either. Sometimes I copy passwords from my password manager to paste into the intended app. I don't want everything that enters my clipboard sent to a third party.
Will the existence or lack thereof excuse the absolute lack of security and privacy this package exhibits? And the lack of interest from the developer?
I think that in today's polarized world, it's very much needed. I think we need to look at each other's fallibilities and failures, and not hate each other for it. But the issue needs to be taken care of, especially since it's known since 2009. It's ridiculous that everyone let if fly for so long.
Yes, but it is a tricky situation when a common tactic is to pretend to be ignorant. For example by "just asking questions". We need more patience and respect in this polarized world but at the same time there are a minority of malicious actors who intentionally abuse any assumption of good faith given
I definitely consider it a security breach. But I do still think it's ignorance. Debian maintainers let it slide since 2009, so for at least 16 years now (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534731) - are they also malicious? I just think that not enough fucks were given.
Debian maintainers in 2009 did not let it slide, they did fix it in 2009 ... but it came back, twice! (and it seems not many cared about StarDict in 2015 to fix it promptly that time)
> the same kind of problem was reported by Pavel Machek in 2009 and again by "niekt0" in 2015. The 2009 bug was solved by patching the application's default configuration to disable networked dictionaries. That appears to have worked for a time, but the YouDao plugin, which was added in 2016, does not respect the configuration option. The 2015 problem was not fixed until August 6 of this year (although the package was removed from Debian for unrelated reasons for a few months from 2020 to 2021). That fix just removed the stardict_dictdotcn.so plugin, which also sent translation requests to dict.cn and was later subsumed by the YouDao plugin, from the package.
It isn't rare at all for bugs to surface many years later and that doesn't mean whoever was responsible for maintenance to be malicious, it is if the bug was planted on purpose, and there are some examples of that (the xz library saga, for instance). Of course, you could argue that that too was incompetence but that's not how this works: lack of oversight by others does not imply malice on the part of those others for failure to catch the issue.
Stuff like this can fly under the radar for a long time because lots of people will assume how it works without actually verifying that it really works like that.
I completely agree. Also, these people have a lot of other assignment, as I imagine. I, for one, have certainly let things slide in the past that ended up biting me, for whatever reason, malice not included.
I guess the companies receiving all this clipboard traffic are absorbing operational costs to humbly provide this surreptitious service to the world for free, and the package maintainer only wants to help them realize their mission.
Why can't reasonable people disagree here? Surely if the utility of some features might outweigh the security concerns for some people. Making features opt-in instead of opt-out significantly changes their discoverability and usage metrics. On the whole, a translation system that has a feature to translate selected text seems hardly surprising. Similarly, using an online service to improve translation quality and reduce local resource usage also seems reasonable.
Fundamentally, always-online, home-phoning features are the norm, and it should be up to OS distributions to manage security postures such as allowlists for network access. Think something along the lines of "StarDict wants to connect to dict.cn. Allow/Deny?".
They can, but framing this as a mere disagreement is disingenuous: One approach might slightly inconvenience someone, while the other (as was taken here) inflicts irreparable damage.
> Fundamentally, always-online, home-phoning features are the norm,
No. Although common on certain platforms, they are not a fundamental norm in software, nor should they be.
There are dozens of chrome extensions that translate (read: submit to untrusted server) on hover / highlight / context menu / textarea edit / etc. It is implied, that user acknowledges this functionality and accepts the risk. This includes untrusted server (because that's how they proxy requests to Google/Bing/Yandex Translate without exposing API keys).
A moderately popular Chrome extension is frequently bought for tens of thousands of dollars for various purposes, frequently malware injection. They contact extension makers.
I think the bar for trust in terms of evil intent is on the floor.
Such a response is not considered a valid defence under GDPR. You cannot sign away your right to privacy any more than you can sign away your right to life.
I'm not going to fault you for that, but no, you really can not sign away your right-to-life even with assisted death. The process is explicitly tooled around this to ensure that people's rights are not violated. I am not saying that there will never be a mistake made here or even that that has not possibly already happened but in principle your right-to-life is not violated by this procedure, and I realize that I will not be able to convince you otherwise.
That requires a complete re-thinking of your moral framework if you are not familiar with the concept.
Just like for some people gay marriage is inconceivable and results in them being ready to man the barricades and for others it doesn't even move the needle. And then there is abortion and bodily autonomy. Large swathes of humanity are not going to be able to understand the remainder when it comes to those subjects, they all arrive at their own conclusions through a mixture of tradition, religion, philosophy and cultural exposure (media, mostly) as well as peer pressure.
I've long ago decided that the only party that will hopefully be able to get all of those right using an objective frame of reference will be born a few thousand years from now, assuming humanity will make it that far.
> you really can not sign away your right-to-life even with assisted death. The process is explicitly tooled around this to ensure that people's rights are not violated
I’m saying that on a practical level the difference is unobservable. Part of your right to life, in this formulation, is your right to sign it away.
The terminality of a right to life makes it a poor comparison to privacy, which has no comparably-irreversible end state like death.
Please stop this sophistry. Assisted dying is in no way comparable to "signing away your right to life". Even if you want to reduce it to such black and white phrasing (which, quite frankly, makes you come across as an asshole), it's actually asserting ultimate control over your own life. At no point in that process are other people allowed to perform acts not specifically authorized by you.
i agree. if in 2025 ppl dont understand plaintext of user data to places on the net is bad, they should not write code nor be maintainers of oss software -_-.
how many times does everyone need to be totally compromised by some shitty software before people start to care?
innocent individuals each days are suffering hacks and malicious interactions. people are losing their livelihoods. companies are getting shutdown... what more need to happen?? :S
> i agree. if in 2025 ppl dont understand plaintext of user data to places on the net is bad, they should not write code nor be maintainers of oss software -_-.
LLMs are only going to make this worse. We're going to see a plethora of vibe coded slop everywhere.
Malicious intent written in the package description? I would think that really unlikely.
I think it's just a cultural difference. Sogou, a super popular Chinese input program for Windows iOS and Android does the same with everything you type and nobody cares.
I'd say that having terms of service that document your shady behavior whilst at the same time not making this obvious in the UI in any way is a tried and true (corporate) malware pattern.
Just because Microsoft did it that doesn't make it a valid defense, in fact it shows the opposite (after all, they too did not have the best interests of their users at heart). The fact that the recipient of the data sits on the other side of the GFW and that clipboards can contain very interesting data you really should wonder about the intentions of the author, they do not get the benefit of the doubt. In fact, open source software that to all intents and purposes looks like it runs locally but pumps your (private) data out without your consent is a very large red flag to me: it gains access to data that otherwise likely would never be found in the wild. At a minimum this is a fairly serious GDPR violation.
I think so too. It's cultural difference, and ignorance at most. I doubt the maintainer has control over that two random dictionary websites, or was tasked by them to do this or anything like that. They are just a different person, and they didn't give a fuck.
That doesn’t even address the problem! The package description does mention the scan feature, but not the automatically-send-it-to-a-server-in-plain-text feature.
Sure, if you read the description and the list of plugins and correctly guess how this plugin is implemented, then you can deduce some of it.
I install stuff from Debian's repos for 2 reasons. Convience & trust. And while people do complain when maintainers modify packages behavior, I think people would rather have the send my clipboard contents to someone else to be opt-in. Instead of violating their trust!
I do agree with your point, specially when it is not the first time a package maintained by that guy does non-expected behavior like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010165 (Inappropriate package, modifies other package's (conf) files, should be removed from archive).
I disagree that "modifying other packages' conf files" is a problem. Conf files in general are there for the user to modify, and as the maintainer points out, it shouldn't matter if the user uses vi, joe, emacs or this specific tool to modify them.
The problem in this case is that the package modifies generated files belonging to another package. Making it about conffiles is bad phrasing by the bug submitter.
> If someone started reading all the package descriptions and READMEs we're meant to be thoroughly familiar with when Trixie was released a few days ago, they'd still be reading them.
That used to be viable back in the late 1990s and early 2000s when I first used Debian. It would take an afternoon of going through all the packages in dselect (does anyone here still remember dselect?) and marking the ones you wanted to install, and around the same amount of time going through every option on the kernel's menuconfig to precisely tailor the kernel to your specific hardware configuration (things were much less dynamic back then).
Nowadays, there are simply too many packages and kernel configuration options to go through (also, does anyone still use dselect?).
"If someone started reading all the package descriptions and READMEs we're meant to be thoroughly familiar with when Trixie was released a few days ago, they'd still be reading them."
Another option might be to reduce the amount of software one is "blindly"^1 using and relying upon
For example, I have been making own Linux distribution, not following Linux from Scratch (although that is a useful reference)
This is for both learning but also reliability and robustness purposes (where "robustness" includes ability to recover quickly from losing everything)
IME starting from scratch gives a better appreciation for the "inconveniences" that maintainers must endure
"Inconvenience" may be putting it mildly
Certainly, the inconvenience varies depending on the software
Some software builds even on the most deficient/broken installations
Other software is absurdly difficult to compile, often due to minor oversights, sometimes due to obivous carelessness
The wild inconsistencies from one project to another is itself part of the inconvenience
The ease with which software can be compiled by me, and presumably anyone else, on any computer, including underpowered ones, with minimal dependencies, is among the factors I consider when choosing whether to rely on any particular software
1. Here "blindly" means the user has zero curiosity about where it comes from or how it works
No comment on this particular software or the Debian maintainer
I have up on X11 many years ago
I never liked that Debian maintainers make subjective, opinionated changes to other peoples' software, especially since it seems like the majority of Debian users do not compile from source
"RTFM!" comments comes in flavors and bears nuances. In this case, as another commenter has pointed out, the answer smells fishy.
I have been told to "RTFM!" countless times in many places. Some of them were legitimately the correct answer in that context, in hindsight. Some were knee-jerk reactions like this.
Debian's discussion culture might be a little edgy sometimes, but this has nothing to do with Debian.
> of course a dictionary program will include code to talk to dictionary-providing web sites.
I wouldn't say that is just a given, if I've apt-get installed a dictionary I might expect that is the whole thing on my machine. It's not like we haven't had dictionaries in physical books for centuries...
It seems like stardict is very much an online thing, which I suppose could be legit, but the whole thing does seem like a trap.
I's a generational thing. I would guess that someone who expects applications to phone home, on the off chance that they are actually otherwise local, is likely someone pretty young who hasn't lived in a world of locally installed software that doesn't talk to anything.
If we search for the author's bio, that seems to check out. They are a well-credentialed CS person; obviously they know that dictionary programs such as translation pop ups can have offline dictionaries, and mentions that. But they are a person of their time with an according set of "of courses".
Today, an application being locally installed and works with offline data is like a a statement of quaint chivalry, promulgated by a few remaining Don Quixotes of computing. (It saddens me to say. So much that this analogy brings me insufficient amusement.)
For many languages, there simply isn't a comprehensive dictionary file that could be redistributed legally as part of a free-software offline dictionary application. You either settle for a few thousand words put together by a handful of volunteers, or you redistribute a commercial dictionary illegally, or you have to connect to an online service to provide sufficient coverage legally.
I could buy the idea of the plugin system itself being desired (e.g. maybe I even want english definitions from Merriam-Webster or something because I like their style more than the open source database) but I think that's separate from what an app does by default. Especially on something like Debian, one should expect a FOSS-first approach whenever reasonable, and for >99% of users the reasonable default is a local dictionary.
Wiktionary is massive with 1.4M English entries [1] (3x the size of the Merriam Webster's Unabridged dictionary [2], though with a lower average quality), and CC-BY-SA-licensed[3]
Yes, the abundance of English data is why I felt the need to point out that this isn't the case for other languages. (Also, the raw count from Wiktionary can be misleading if you don't take into account that there are many low-effort entries for different forms of the same word.)
Dictionaries are small! It's insane to think that a dictionary requires network access. If it did, why would I install it locally??
> Today, an application being locally installed and works with offline data is like a a statement of quaint chivalry, promulgated by a few remaining Don Quixotes of computing.
But a dictionary package has no valid reason to be online.
Wouldn't someone's expectation instead depend on the nature of the application, and what data it needs? My expectation is that an application does not access the network unless it requires a resource only available from the network. I would totally expect a "Yelp" application to make network requests as part of its core functionality. Yelp is an online service, and in order to use it, you have to talk to the network, and you're generally requesting data that might often change, so you need fresh copies. Same for an Internet browser, or ftp or git (for remotes) or things like that. I would not expect a spell checker to need to access a network because it can all be done locally and the spelling of words doesn't change often enough to need a fresh dictionary from the network over and over. And I certainly would not expect the software to send data to the network. I would also not expect a calculator application to request math function from the network or send my equations to a network service so that the network service could provide a result.
... Is it? Dictionary apps have been working like this for more than twenty years. Babylon Pro of which stardict is pretty much a clone was doing this with already millions of users in the year 2000! Kindles work like that!
Because without HTTPS it's trivial to MITM that clipboard content if they're always sending it via http.
People in your coffee shop on the same WiFi could read it.
I get some people don't realize that's how TCP/IP works and the firesheep stuff all happened 15 years ago. But a bit worrying to see a frequent HN contributor challenging that.
Not all guest Wi-Fi uses a PSK. In general, assuming all networks will already be encrypted along each hop to the server is a losing assumption for users.
Https everywhere is a good start, it keeps the other plebs at the coffee shop out of your business. But it's still open to anyone with enough power to coerce a CA, which is the more concerning sort of adversary anyhow. So yes, https everywhere, but let's not stop there.
At some point I started running gui apps without network access, first with firejail and then bubblewrap. This was before flatpak became a thing. I still use collection of bash scripts that built up over time to run applications in sandbox.
a bloom filter look up is by hash, and given the relatively small set of words in english, it would be pretty easy for the server to reverse the hash sent to it. Thus a bloom filter wouldn't be very private.
Additionally, a typical spell checker feature is to provide alternative, correct, spellings, rather than just telling you whether a word is correctly spelled.
I bet there's some cool way to do this with zero-knowledge or homomorphic cryptography though!
> a bloom filter look up is by hash, and given the relatively small set of words in english, it would be pretty easy for the server to reverse the hash sent to it. Thus a bloom filter wouldn't be very private.
The typical use of a Bloom filter is to have it locally as a prefilter, not to send hashes to the server.
There are two scenarios I believe, first accidentally sending a (decent) password, and second the server not learning what you actually look up.
For the first case, sending a hash would prevent the server from learning a password that is not in the dictionary, something like password5 would hash to gibberish.
For the second, the server needs to know what to actually send back. I believe Google's malicious website check works (or used to) by truncating a hash an then just sending the answer for some 128 or so websites and have the browser figure out which of them the user wanted to visit. That creates some deniability over witch website you actually visited and should be also usable to prevent the server from learnering what you actually looked up.
So yes, I think you could design a more secure Protokoll. Though general security disclaimer the people trying to read your letters probably spend more time attacking than I spend writing this post.
Somewhat related, I was quite surprised when I discovered that my Samsung phone was sharing ALL my clipboard with all my other Samsung devices, including passwords copied into the clipboard, and even preserving the history. I can't remember if the sharing was enabled by default or I opted in by accident. I assume it also goes through their servers to reach my other devices. I could disable the sharing, but still can't turn off the clipboard history, even switching to a different keyboard, the Samsung keyboard still captures the clipboard and saves the history, when I switch the keyboard to Samsung everything is there... I guess my next phone won't be Samsung.
I noticed this happening through KDE connect, where passwords copied on Linux show up in Android's clipboard history, is there a way to block passwords from being transported around like that without completely disabling clipboard sharing altogether?
KDE connect lets you disable/configure individual plugins, just disable the "Clipboard sync". I don't think it can by itself figure out that you're copying a password, at least across UI toolkits. FWIW most toolkits and browsers don't actually copy from a password input anyway.
You might want to disable KDE's clipboard history too btw, or at least find a solution that doesn't involve copying passwords. Either use the selection instead of the clipboard, or use password filling through non-clipboard channels.
Querying a local dictionary on each clipboard seems okay; having a feature to request remote dictionaries is okay; making it easy to combine both is dubious but understandable (would be better off as a special flag); but having them combined by default? That's pretty much malicious.
It's talking about querying youdao, which is more translation service. Offline translation < online translation, i.e. I don't want to fallback to local google offline translate language package unless I have no data. I don't use stardict, but it should be completely expected functionality if translating more than words like dictionary.
This entire article should be, Chinese translation program sends clipboard data to it's own website and chinese translation services, but on http.
It's really difficult to not assume malice with something like this. From the maintainer:
> The stardict has "Scan" function, when user enable this function,
after user select some text, it will trigger stardict do translate for this selected text... Why the user selects some confidential data to query dictionary?
The Wayland framing at the end strikes me as misleading. This gets it exactly right:
> Or maybe StarDict would have started asking for special permissions to let it work on Wayland, and users would have accepted those defaults the same way they currently do.
Yes, that’s what it would do. Its installer might even configure that special permission automatically, without user intervention.
Malware’s gonna mal. Wayland might help defend against some things, but it’s not going to defend against packages installed as part of the distro.
It is not misleading, Wayland is better than Xorg in this particular respect.
But the other concern is part of the systemic problem. Consider that the data that was transmitted was sent in the clear!
> StarDict ... while running on X11, using Debian's default configuration, it will send a user's text selections over unencrypted HTTP to two remote servers.
> Any user who did read the description of the package, and who knew what the YouDao plugin would do, might nevertheless expect the resulting communication to at least be encrypted. But the plugin actually reaches out to its backend servers — dict.youdao.com and dict.cn — over unsecured HTTP. So, not only are these servers sent any text the user selects, but anyone who can view traffic anywhere along its path can see the same thing.
It's extra misleading, because "Wayland" isn't a thing when it comes to policy like this. Unless a compositor implements some sort of user approve/deny UI when an app requests access to the clipboard, apps on Wayland can snoop on the clipboard just as easily as on X11. I haven't run GNOME or KDE in Wayland mode, so maybe they do implement something like that, but none of the wlroots-based compositors I've tried do.
>This would normally not be much cause for concern; of course a dictionary program will include code to talk to dictionary-providing web sites.
Hey, an area I finally know something about. It depends on what you're trying to do.
The slimmed down version of a Finnish dictionary I provide in `tsk` [1] weighs in at around 30 MB, for about 250,000 Finnish words. It's small enough that I embed the whole dictionary directly into the binary and reconstruct the prefix search on the fly every time the user starts the app.
However, the much larger database which contains things like lemmatization and etymology information easily balloons up to many, many gigabytes in size. My problem domain is providing Truly Instant Lookup, keystroke by keystroke, so I can't really get around this level of memoization. The work to figure all this out was sufficient that I decided to make future versions a paid product instead [2].
Most other use cases would just call out to a server, because it's silly to think most people are going to download a giant database for that use case alone. A hybrid approach could also make a lot of sense, eg cache the most common 10,000 words locally and call out for the next 1.5 million, which are statistically extremely rare.
Some context for ppl who are not paranoid, it's a very old software and not very maintained since very long time ago. I'm pretty sure HTTPS was not common at the time. And the selection scanning a very common and wanted feature in many alternatives for windows, browsers, etc.
If there's anything we can learn from it - don't use obsolete software.
While I have a lot of respect for the effort that goes into Debian, I always disliked this kind of "maximalism" from the package manager. Oh, the user wants "foo"? Let's install every software that might be even remotely useful somehow in combination with foo! Oh there is a network daemon in there? Fantastic, let's start it immediately!
I know that there is a flag to disable the installation for "recommended" packages. I just think the default is a disservice here.
First of all, "Recommends" is reserved for packages which enhance the functionality of the package you're installing. Without these the package will not break, but some very useful functionality might be disabled.
The package-class you're talking about is "suggests", IOW, "these packages might also be useful for you, wanna look?" section. These are not installed by default already.
On the other hand, apt and aptitude provides previews before doing something. You don't have to accept them. In aptitude's case, you can fine tune before the final commit, even.
There's a tension. Minimalism vs. user utility. Somebody told in Debian 13 release comments that "Debian will never be a end-user friendly distro". Now, you're saying that packages shouldn't install recommends by default.
What should Debian be? "An IKEAesque DIY distro", or "A more user friendly, yet very stable and vanilla distro". I vote for the latter, personally. Plus, as I told before, advanced users are free to use what they want to change.
If you want to change the default, the configuration files are at /etc/apt/conf.d/. If you want to disable feature for once, it's --no-install-recommends.
Well, as a user of one of the more "IKEAesque" distros, I guess I have made my choice ;)
And that's perfectly fine, it just means I don't align with Debian on this one. And that freedom is what Linux is all about, I guess. So it seems it's working as intended :)
Edit: And I totally get that users might often want that kind of maximalism. It's just not for me. Although starting network daemons by default might sometimes be a bridge too far, or the case described in the article here.
While I'll argue that Debian's network daemons come with very sane defaults and an accompanying AppArmor profile to prevent both network disruptions and attack surface increases, I'm certainly not with the developer of StarDict. That thing smells malicious.
...and this is what Debian Testing is actually for. To catch these types of issues.
Of course, people are free to select what they resonates with them. I'm not against more DIY distributions (I'm also contemplating using a LFS VM to explore things even further, but time is an issue), and I'm not against your personal choices. I just wanted to note the tension, and share my observations about Debian.
I agree that recommends makes sense but this is a bullshit argument:
> On the other hand, apt and aptitude provides previews before doing something. You don't have to accept them. In aptitude's case, you can fine tune before the final commit, even.
You can't expect the average user to understand the entire dependency tree and read the description of dozens of random packages that the average program pulls in. RTFM is not a valid excuse for bad defaults.
I don't expect average user to read an entire dependency tree. However, apt and aptitude does a relatively good job of explaining their actions' reasons.
Let me rephrase:
1. Installation of recommended packages is a good default for the average user, because it provides functionality they expect.
2. If the user is not happy with what's happening, changing defaults are not hard.
IOW, if you don't like how your system behaves, read the documents. Otherwise, I argue, current defaults is good for the benefit of the newcomer and average Linux user. If you are at a point where you are caring which package is doing what, you're leaving "average user / beginner" realm.
In the case of StarDict, as I noted elsewhere, I think the developer's answer is fishy, or ill-informed at least.
From my experience, newbie users are generally more interested in the end result: Their intended packages are working, and what that package is doing. They are not yet interested in all the libraries required and whatnot.
As they get familiar with their systems, they get interested in what makes the particular package or software tick. Then, the digging starts. At that point they are already pretty proficient with their package managers, and start to learn their systems inside out. At that point they're not beginners since they can do targeted tinkering.
Except very rare circumstances, I didn't see anyone to dive to the deep end directly.
If wondering about why some libraries are installed as a part of an application, and having a desire to learn the function of a library in that context is a "weird" definition of "wondering about what software does", then yes.
This is a classic tension between convenience and security - Debian's "recommends" defaults were designed for a pre-cloud era when network connectivity wasn't assumed and local functionality was prioritized over potential security boundaries.
Actually the default value of `APT::Install-Recommends` had been false, and it was changed to true in Debian 6.0 Squeeze (2011-02-06). I didn't like the change at the time because my Debian and Ubuntu systems suddenly installed more packages by default. However, now that I think of, the distinction of recommended packages and suggested packages was blurry before the change, because both were opt-in. Auto-installing recommended packages, while allowing the user to opt out is a better default I guess. But I still turn off auto-installation of recommended packages in the systems I manage.
I don't have a problem with --install-recommends being the default. I think it's a fine distinction to have Recommends be "most of our users will want these" and "this package provides some niche feature that most users won't need".
However, like you, I do have a problem with maintainers abusing the Recommends: field to further their own world domination plans. There is no valid reason that installing an archive tool should mandate a specific init system (looking at you, file-roller and gnome team in general).
The other extreme where you are missing expected functionality because it's optional isn't any better. The problem is not that recommended dependencies are installed by default, it's that package recommendations should perhaps be more conservative. Note that Debian already differentiates between recommended dependencies (which most users should want) and suggested dependencies (related functionality or enhancements that are not relevant for every user).
Your link is about privacy issues in upstream software that Debian hasn't sufficiently worked around yet. The main advantage of the Distro model (as opposed to developer-maintained package ecosystems) is exactly that there is someone protecting you from questionable software "features".
There's also no insistence on privacy in the Debian Social Contract or DFSG (not that these would be appropriate places for it, they're mainly about licensing)
> I don't think Debian intentionally shields you from privacy-invading software
There is a culture of valuing privacy though, including patching out privacy issues. Especially since a lot of Debian folks are from Europe, with corresponding GDPR knowledge.
I know that the lintian warnings pointing out privacy issues in HTML documentation do get a lot of patches.
Also, opensnitch is packaged as a mitigation.
You are right about the policy problem, Debian really needs to do something about that.
There is at least a privacy policy for Debian services.
2. Self-abandoned, or given up to vice; extremely wicked, or sinning
without restraint; irreclaimably wicked ; as, an abandoned villain.
Syn.
-- Profligate; dissolute; corrupt; vicious; depraved; reprobate;
wicked; unprincipled; graceless; vile.
-- Abandoned, Profligate, Reprobate. These adjectives agree in
expressing the idea of great personal depravity. Profligate has
reference to open and shameless immoralities, either in private life
or political conduct; as, a profligate court, a profligate ministry.
Abandoned is stronger, and has reference to the searing of conscience
and hardening of heart produced by a man's giving himself wholly up
to iniquity; as, a man of abandoned character. Reprobate describes
the condition of one who has become insensible to reproof, and who is
morally abandoned and lost beyond hope of recovery.
God gave them over to a reprobate mind. Rom. i. 28.
I don't understand why the whole thing isn't local. A comprehensive Chinese dictionary has less than 400k words. Even at 1k per word that's less than 400MB.
It's just poor design to make something require a network connection when it could work offline locally.
If I would be deciding, I would kick-ban StarDict immediately from the distribution, and scrutinize i) the maintainer for all the packages he has ever touched, ii) StarDict authors for allowing such a default behavior in their system.
Most Chinese sites do not use HTTPS. In fact, TLS 1.3 traffic seems to be completely blocked within China's internet.[1] The decision to use plain HTTP is only strange from a Western viewpoint. Note: I am not defending this behavior. I still remember the era of ISPs injecting content into webpages. But it's important to keep in mind our subset of the world does not reflect the rest of the world.
> StarDict on Wayland doesn't have this problem, because Wayland prevents applications from being able to capture text from other applications by default.
StarDict on Wayland has a different issue, it causes a segfault.
Sat, 02 Aug 2025: Bug#1003710: stardict crash in gnome with message Segmentation fault
Yeah, I don't really know much about Wayland but.... That does not sound correct to me... Wayland has a copy/paste protocol, and my 5-minute web search indicates that it works much like the X11 copy paste protocol, each application takes care of what will be sent when pasted. then some other application requests a paste, the display server connects the two they negotiate a format and the "copied" data squirts across. that is to say Wayland applications can totally capture text from other applications.
Now if the article meant to say Wayland applications are unable to capture arbitrary text via mechanisms other than then the copy paste protocol I would say fair enough, but it sounds like the problem application is using the normal X11 copy paste protocol. so I don't see how that statement is relevant.
Besides, capturing text from other applications is very much required for various utilities. It's as much of a security feature in Wayland as turning off your computer and never turning it back on is.
Those privileged interfaces cover known use cases but don't allow for novel tools - or even full functionality of existing tools in many cases.
You also underestimate how many programs make use of functionality that could be abused in some way. And unless you lock all those interfaces down it's all security theater. Who cares if the display protocol disallows copy paste snooping when there are a million different ways to get the the memory of other processes or the files that they store sensitive information in. And such a locked down ecosystem is antithetical to free and open computing.
I don't use my computer to be secure, I use it to get shit done and and to have fun. I'm not going to accept approaches to security that interfere with that any more than I will accept the same in real life. There aren't any bars over my windows because we have functioning police to deter criminals. I don't need lab tests done for all the food I buy because we have regulations that ensure food sold is generally safe to eat. I go outside without body armor and weapons even though someone could theoretically kill me. 100% security is always a tradeoff for quality of life.
But then StarDict would still be sending your selections out.
Personally I think the X11/Wayland distinction is moot, given this appears to be an explicit feature of StarDict, and it seems more likely it just hasn't been ported to Wayland yet.
My personal security tolerance means that I have multiple levels of firewalls and blockers: network, dns, device, and browser. It's also why I find myself scanning my DNS traffic (pihole), and running OpenSnitch.
Whether malicious or not, to me isn't the point. The point is that I, as an individual deserve the illusion of control over my data and communication. I have neither the time, nor inclination to read all release notes. Furthermore, as someone who has spent enough time writing code - I recognize that humans make mistakes and don't always update them with salient details. All the automation in the world, and AI (yes, I've tried AI for release notes) just doesn't help.
Whatever is making plain HTTP requests in 2025 should be a cause of concern. Wouldn't it be nice to have a low resource daemon watching for common pitfalls alerting users so we eliminate or minimise classes of problems like this?
I think lots of windows antivirus come with features like this? Perhaps with vast crystalized kno eledge nowadays we can afford to create OSS system level package that offers some level of protection.
It's not a technicality, the package was removed from Debian so there was no reason to keep the bug report open. And it was reopened by a debian developer when the package was reintroduced a year later.
That's not an excuse for why it wasn't dealt with until now but what you are suggesting didn't happen.
This post caught my eyes immediately because I have been sort of benefiting from StarDict project. Although I do not use it directly. I have been using sdcv, a CLI tool that reads StarDict dictionary. It’s minimal and serves me well.
> Part of the justification for moving to Wayland over X11 is to make security vulnerabilities relating to one application spying on another more difficult to introduce.
Yea, because, how else am I going to run shady poorly maintained dictionary software that ignores system settings from a hostile country? What kind of world are we living in with X11?!
The software could just as well hook into your downloads folder and transparently "translate" any downloaded text or PDF file for you. In which case the method by which pixels arrive on your screen would not be relevant.
How is this an X11 vs Wayland issue and not a distribution hygiene issue? Why is this package even a part of the distribution? In the desire to force one desktop system to stop existing, for whatever reason, I think they've missed the broader point.
Flatpak'd wayland applications are super usable and they prevent the clipboard spying and the download folder shenanigans. You can edit permissions straight from KDE settings.
Of course, you can't safety just run malware in flatpak.
I agree with you, this is not an X11 issue, it's a "why are we letting software like this in the repository" issue. The kind of lax attitude towards security I'd expect from a random AUR package, not in the Debian repo.
Which is interesting (as according to the LWN article) it seems like the general issue of what is sent is an ever-present one for StarDict, as apparently the earlier issue was around the defaults for all dictionaries, whereas the new issue is around a specific plugin.
Personally, if I was using (or a maintainer of) a dictionary tool which autoreads the clipboard (or any dictionary tool), I'd be checking what it is doing and considering whether it is what I would want to use.
I assume it must be 2015 at most because my first job in 2008 ran everything, including images, on HTTPS. But I can imagine some last holdpouts 7 years after that.
I recently found wordnet through an offline dictionary/thesaurus program and thought it was a pretty neat project. https://wordnet.princeton.edu/
For my use case I was more interested in the data than the application and so never installed it and am unable to comment on how usable it is, but will include a link if you want to look. https://sourceforge.net/projects/artha/
Not everyone participates in the popularity context. By some estimates about 1% of users do: There are about a quarter million popcon responses in Debian's recent popcon graphs. Absolute number of users is hard to estimate but I find one estimate of 20-50 million Debian users. So taking 1% as a lower bound, at least 18k people use StarDict in Debian. I don't know how to guess the number that use StarDict in another OS.
In my Windows, it wouldn't be a problem. The firewall I use would pop up for any new program that tries to connect somewhere.
But Linux doesn't have a per-program firewall.
... and even if it did, there's no way to do popups/questions from the kernel,
... and even if there was, most programs would just run curl or wget or openssl. That would mean a popup for each and every connection attempt through those programs.
Windows does certain security things better than Linux OSes, which makes it such a shame that Microsoft keeps shipping more and more stuff with Windows that undermines all that work.
I honestly don't think x11 is the primary problem. The package maintainer not thinking it's a big deal to send this data over http by default wouldn't be a good situation on Wayland either. They wouldn't get the clipboard but they're still not responsible. I presume this program also has full access to the filesystem.
it looks like a serious "privacy violation" for English-only users. But for many ESL or non-English users out there, the "translation" is a must.
On Windoes, I remember some translation programs go extreme, they hijack all GDI calls and scan for all strings on GUIs trying to translate and replace them inline. Local dictionary were pretty limited so many of them use online services. What happens when user input something "sensitive" on the GUI?
Well they goes straight to the translation service.
Translation isn't the problem, sending data over the network by default is. Data is leaked to Chinese dictionary servers even if you're translating between European languages using a local language according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960.
With the GDI hijacking programs you usually download them for specific languages with the knowledge they're internet connected.
> But for many ESL or non-English users out there, the "translation" is a must.
As an ESL user, I vehemently disagree. You're only going to need translations as long as you keep relying on translations. Like it or not but English is the lingua franca of the computing age and you're doing yourself a disservice if you don't learn it.
I cannot comment on how useful these tools are or not since I started using computers in English (there were no translations to my language back then) without any such tool or without knowing any English. I had the of speaking another Germanic language but I would say if you know some basic you can use computers without any tool assistance and learn English quickly.
No, you don't need a translator tool to learn other language. Certainly not one that automatically translates everything you copy.
Once you know the basics (which a translator won't teach you) the most effective way to become proficient is practice, which is the opposite of relying on a tool to translate things for you.
English-only users need translation too, there are lots of web resources out there only in non-English languages. I found the Bergamot offline translation tool embedded into Firefox helps a lot for that these days.
Docs is obviously designed to be misleading. If I would design a malware, this is how I would do it. Plausible deniability. Don’t fool yourself. Kick this shit, and people who develop it, out of debian asap.
Meanwhile on Wayland:
> StarDict on Wayland doesn't have this problem, because Wayland prevents applications from being able to capture text from other applications by default.
Seems irrelevant to me. I shouldn't need to defend against software provided by the official repositories. The entire point is for those to be trustworthy.
Also Wayland breaks a lot of stuff. It's certainly a move in the right direction on the whole but I wouldn't blindly interpret something like this as a win.
You are cherry picking. The next statement says that the scan feature doesn't even work on wayland. Lol. That's worse than working + buggy. (security bugs are just bugs. Nothing special about them)
> That does mean that it breaks StarDict's scan feature, though.
No, Wayland is clearly better here. Not allowing an app to do a potentially stupid privacy compromising thing is better that allowing it by default and providing no way to block it.
Better does not necessarily mean good though, that Mac approach of block by default but allow users to enable these things for specific apps on settings would be a great improvement.
The privacy compromising part is _not_ in the 'reading selection' part. It is in the part where it sends it over http to dict.cn. The solution is therefore, obviously, to replace dict.cn with an offline dictionary. Not what wayland does, which is blocking reading selections in the first place. That is brain damaged.
In the X11 case, I can uninstall the app and install one that uses an offline dictionary and gives me a scan feature. That very much is a way to "block" it. Wanting a scan feature is not wrong. It's my computer. I want it. In the Wayland case, I cannot do _anything_ about it. The X11 situation is thus obviously better.
It's not like "define current selection" is some niche feature either. It's a default feature in macOs, iOS and Android.
You either do it the macos way or the windows/x11 way. You cannot half-ass something in between. That is just security theatre and is utterly retarded. Every wayland release until it makes a macos-style permission system (I dont care whether the default is accept or deny) is pure cancer. And every distro/DE that pushes wayland onto you until that point is also cancer.
I'm not sure how Wayland specifically prevents the privacy issue on its own (it can't block network calls), it seems it's down to not implementing the required Wayland calls, but I would be surprised if there was no portal or DBus or similar IPC to get the clipboard on Wayland (which is called out in the package description as noted by the maintainer). The issue is what the app plugin does with the clipboard data, while it's not something I want, I can see people wanting automatic lookups of words.
I think in a similar way to how xz attack required integration via systemd to exist, this is really more about defaults and integrations (which the last message from the maintainer acknowledges and seems to be fixing). https://xkcd.com/2044/ is as always an ever-present problem.
Android has its fair share of issues as well. For a recent issue, take a look at the localhost tracking, wherein "Meta devised an ingenious system that bypassed Android’s sandbox protections to identify you while browsing on your mobile phone — even if you used a VPN, the browser’s incognito mode, and refused or deleted cookies in every session":
It's by design that apps on Android can talk to each other. It doesn't require a sandbox escape to do. Usually it's done via binder, but it also works through shared memory, unix sockets, network sockets, or pipes.
I get that. Well, not in the linked Facebook case, seeing how much legal attention they have attracted, but in general. And I think that the X server's design is the same. What StarDict did was using an intentional part of the design, not a hack, or exploiting vulnerability. Which is why the Android comparison doesn't stand.
My point is it's the browser app's responsibility to add extra security before reaching out to private / loopback addresses when it wants extra privacy.
Android already provides a way to sandbox apps from one another, so if people don't want social media apps talking with other apps they can already separate them.
Which Android versions ask for permission before an app can make HTTP requests? I know it's something the app has to declare in the manifest, but other than obscure ROMs every normal version of Android just allows network usage without asking the user.
Android itself doesn't enforce it, but starting with Android 9, you have to opt in to HTTP requests rather than opt out. Most app developers don't even know about this so their applications (and the ads packaged within) cannot do plaintext HTTP calls using the normal system API.
Still doesn't prevent an ad library from bundling libcurl and doing HTTP calls manually, of course, but it's a sane default.
A society that balances cause and effect! Money is also balanced! Money flows perfectly through multiple lifetimes! Being respected ultimately leads to balance!
Part of the fun of free software is that it might do terrible things. Debian is not a distro that promises you a walled garden run by an iron-fisted tyrant who beats programmers into submission so they'll respect your privacy
Nothing in Debian will install StarDict invisibly. Only you install StarDict. Only you run StarDict.
Wayland is not a panacea. If you want StarDict to translate everything you highlight/clip, you will tell Wayland to let StarDict do that. If Wayland can't do that, it's bad, paternalistic software. There is Android and iOS for idiots who want to be bossed around by their device and have no real freedom.
The real problem are these HTTP lookups by default, which is the fault of the packager, and Debian as a whole for not prodding them into fixing it.
This bug was already reported and fixed as CVE-2009-2260. Then StarDict was kicked out of Debian, and when it came back, so did this bug. The most recent re-reporting of this bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960 raised in 2015) was fixed a few days ago by removing the dict.cn plugin, 2 days after Vincent Lefevre raised this issue on oss-security-list. He also raised CVE-2025-55014 for another dictionary plugin that sends HTTP requests, which has also been fixed by removing that plugin.
Both plugins should be removed from Trixie as of today, and more appropriately, all the "network dictionaries" are now in their own package (stardict-plugin-network-dictionary), not installed by default (stardict-plugin suggests rather than recommends it):
Package: stardict-plugin-network-dictionary
Description: [...]
*Warning*
* The query word will send through the network use plain-text in this plugin!
* Please do *NOT* selects any confidential data to query dictionary
* When enable "Scan" function on stardict, the selected text will sended on the net at once.
Package: stardict-plugin
Suggests: [...]
stardict-plugin-network-dictionary (= ${binary:Version}),
You can expect that any software might do anything, either because of a bug or because it's intentional, and you won't know until you see it happen. It's why the major FOSS licenses say things like THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
You can want software to be well behaved, and in most cases it is. But if you want some level of assurance that the software is behaved as you'd like it, some requirement in law that the software is not allowed to exist unless it meets your requirements, or the platform it runs on is neutered so it literally can't do the thing you don't want it to do -- that's where the tyrant comes in.
You're asking Debian to check out all aspects of a program and hold them liable if it does something you don't like, or their volunteers does something you don't like.
That's not what Debian is doing. Debian is asking for volunteers to package the world's free software, also written by volunteers. They have their own checklists, your "dodgy behaviour" concerns aren't on it. Confirming the software meets your expectations depends on you evaluating it. If it doesn't, you can then volunteer your time to write them a bug report, which they might or might not accept and fix.
They did. The article exists. The package manager behavior was changed accordingly. It doesn't automatically include that plug-in. My understanding was you scoffed at the "paternalism" and said part of the fun is that there might be terrible behaviors. Others disagree.
Indeed there were terrible behaviours, and they were fixed. My scoffing is at people who believe these behaviours should never have happened, or it shouldn't be possible.
Unless there is a omnipotent tyrant, there will be the possibility that you encounter terrible behaviours, and the possibility that those who could fix them, don't. You can try advocating to the maintainer that they should fix it, you can even try leading a campaign against the maintainer. If they still disagree, you can fix it yourself, with the source they gave you, and you can publicise your fixed version, which people might adopt over the other version if enough people agree with you. That is the fun!
Their reaction reminds me of when the Raspberry Pi Foundation tried gaslighting us.
RPi Foundation hires a cop and brags about how cop used RPis to spy on people. People got upset. RPi Foundation acts clueless and says vegetarians and vegans were upset because they posted a picture of meat.
Now Debian is less concerned with their core tenets and more concerned with winning popularity contests, as can be evidenced by their dropping of i386 support, for instance.
Instead of seeing an issue like this and raising an alarm, examining how this possibly happened, and discussing ways of making sure it doesn't happen again, they're like, "eh, so what?"
Debian, which for ages was the last big holdout of Linuxes becoming corporate, seems to have a bleak future.
> In response, Xiao pointed out that the package description can be read by any user who chooses to install the software, and it does mention the scan feature.
Wouldn't be the first (or last) time a Debian maintainer has pulled the "you should read the descriptions of all (hundreds) of your packages (most installed as dependencies)" card in response to a bug report.
If someone started reading all the package descriptions and READMEs we're meant to be thoroughly familiar with when Trixie was released a few days ago, they'd still be reading them.
“the plans and the demolition orders have been on display at the local planning office on Alpha Centauri for fifty of your Earth years. If you can't be bothered to take an interest in local affairs...”
https://www.youtube.com/watch?v=Z1Ba4BbH0oY
For the uninformed: this is a quote from The Hitchhiker's Guide to the Galaxy.
Thanks for giving the reference right here. I should have in addition to the link!
the reference was available with a minor full-text search of the internet.
You mean, for those who couldn't be bothered to click the link under a joke.
I understood the reference, but I’m also on a limited mobile plan at the moment and would absolutely not click on a YT or similar link.
In other words might have appreciated the explanation.
Such responses to me are proof of malicious intent.
While I think the response was not well thought out, it's still a far cry from "proof of malicious intent".
We're not going to agree on that. The response is clearly there to point to a fig leaf instead of saying 'oh, oops, we will make this more obvious in the UI', the software is working as intended: as a way to gain access to more data.
Note that clipboard data can be just about anything and is a valuable dataset, more so if the source of the data isn't aware of being a source, besides, there is no history so you won't even know what you've lost.
And yes, that IS the expected behavior.
Select to translate is almost a standard feature for translation software. Not sure if the situation gets better now, but back then the software was written, using clipboard as temporary storage is a very robust and maybe the only way to implement such feature.
Trivia: It's likely sending Ctrl+C and reading clipboard to get the selected text. No easy cross-platform API for this lol.
Also note that the software is very old and poorly maintained.
It's clearly a defensive excuse, as it is extremely unrealistic to expect final users to read all the docs of all the dependencies of a Linux distro. It's the responsibility of the maintainer to read the subset of docs relevant to the package(s) they're contributing, not the user's.
It could be that they were caught with their pants down and posted an ill-thought response, but I'd lean strongly towards malice with such a poor defense, it borders on confession. Clipboards are one of the most critical privacy/security features, you don't ever want to leak them unintentionally.
Did we already forget about the XZ Utils backdoor? There have to be multiple efforts to infiltrate backdoors in Linux going right now.
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
> It's the responsibility of the maintainer to read the subset of docs relevant to the package(s) they're contributing, not the user's.
I agree a lot with this. You're supposed to trust your distributions packages. If you can't trust your distro, who can you trust? If you don't, find one you do trust, as that's a viable alternative. If none are trustworthy to you, then the only real option is to become your own package maintainer and have fun with Linux From Scratch.
I disagree; it's basically lawyerspeak for "sucks to be you".
If one is expected to go through all the documentation of both the main package and all dependency packages, and also through whatever specific configuration details to your case, just to be able to catch a specific IMPORTANT detail that's not clearly spelled out in the main package, that's malicious.
"A dependency we use captures your clipboard data and sends it to remote servers"
That sentence right there would kill their userbase, so they omit warning you about it. And on top of the "...user should have read the description..." non-apology, "just split the packages, bro".
That's malicious.
> That sentence right there would kill their userbase
No, it wouldn't. People don't take privacy very seriously.
If this were about a Windows or MacOS program, sure.
The overlap between Linux desktop users and digital privacy concerns is pretty large.
This is Debian, of course they do.
But it wouldn't kill their userbase because nobody reads the package descriptions anyway.
> it's still a far cry from "proof of malicious intent"
Is the difference meaningful? It’s proof of a value set so different from the community’s as to merit the same response: expulsion.
Is there a defined set of values that one must uphold, or at least believe in theoretically, to be a welcome member?
> We expel people for different values now?
Yes, that's what core values mean. If they're not embraced by everyone, they cease to be core.
If X11 tolerates developers who think piping data unseen to remote servers is okay, the project as a whole ceases to be trustworthy.
> I'm not Christian, should I be expelled?
From a listserv? No. From, like, a religious group? Maybe.
We can't afford that level of benefit of the doubt for the people that are supposed to guard us from exactly this kind of bs.
Intent or not, that developer is a risk to the project.
Finally, a rational argument from the torch and pitchfork crowd. Xiao is not taking security sensitivities to heart : HTTP?? To China‽ and a dismissive BS answer.
Hanlon's razor applies here, I think. It's just ignorance, not malice. I doubt the maintainer has connection, or was pressured by these two random dictionary websites to include this - nor do I think that they gain any advantage of it.
People need to be on the lookout though, the xz incident showed that FOSS is indeed vulnerable.
I think Hanlon's razor is outdated. Plausible deniability is the new meta. On top of that, the maintainer seems intent on not fixing the problem.
Not only is it outdated, the Nolnah's razor (reverse form of Hanlon) is more likely to be true nowadays: "Never attribute to incompetence that which is adequately explained by malice".
The bad actors have become too good at acting like well-meaning klutzes.
Wholesale violations of legal and social norms as the secret sauce that will give your company a leg up? Sure if we get caught the stockholders will have to pay to keep our asses out of jail. But we'll get to keep our share of the loot.
Yeah this is the world we now live in.
Right, there are times where the "algorithm" falls over because of pathological inputs.
Can the problem be fixed without making the software useless?
Sure. We've had dictionary software for decades.
This whole trend of adding a service to stuff that doesn't need a service is very annoying.
In that language…
Since it has been shown to be possible in other languages, why wouldn't it be?
It is possible. If you have a free database to do that please upload it?
You can absolutely have an offline DB for lookups/translation for any language that has a server-hosted option available.
Do you have a freely licensed one to share?
Absolutely. In my understanding and approach, it would need two smaller modifications:
1. making "scanning" (the clipboard capturing feature opt-in, with a huge notification for the implications
2. disabling the English-Chinese online translation plugin by default
use TLS enabled dictionary service. if there is none, you dont want this feature. at all. make sure they click through something or explicitly enable is even hard as you cannot assume a user understands the impact. they might not understand what it means to send their data over plaintext, or what someone can do with it.
I don't want this feature with TLS either. Sometimes I copy passwords from my password manager to paste into the intended app. I don't want everything that enters my clipboard sent to a third party.
Does this service exist?
Does it matter?
Will the existence or lack thereof excuse the absolute lack of security and privacy this package exhibits? And the lack of interest from the developer?
Yes it matters. Something that doesn't exist cannot be used. Any other insightful comment you wish to make?
Don't be dense.
At least try to keep up with the main concern: "sending potentially private or security impacting information in plaintext across the internet".
"Does not exist blah blah"
That has to be one of the most inane replies I've read in a while.
I think that in today's polarized world, it's very much needed. I think we need to look at each other's fallibilities and failures, and not hate each other for it. But the issue needs to be taken care of, especially since it's known since 2009. It's ridiculous that everyone let if fly for so long.
Yes, but it is a tricky situation when a common tactic is to pretend to be ignorant. For example by "just asking questions". We need more patience and respect in this polarized world but at the same time there are a minority of malicious actors who intentionally abuse any assumption of good faith given
Yeah, I agree, it's tricky. And besides, the clipboard leak should be fixed for sure, malice or not. It's strange that it has been known for so long.
But it cannot be adequately attributed to ignorance, so no, Hanlon's razor does not apply. There is an obvious security breach.
I definitely consider it a security breach. But I do still think it's ignorance. Debian maintainers let it slide since 2009, so for at least 16 years now (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534731) - are they also malicious? I just think that not enough fucks were given.
Debian maintainers in 2009 did not let it slide, they did fix it in 2009 ... but it came back, twice! (and it seems not many cared about StarDict in 2015 to fix it promptly that time)
> the same kind of problem was reported by Pavel Machek in 2009 and again by "niekt0" in 2015. The 2009 bug was solved by patching the application's default configuration to disable networked dictionaries. That appears to have worked for a time, but the YouDao plugin, which was added in 2016, does not respect the configuration option. The 2015 problem was not fixed until August 6 of this year (although the package was removed from Debian for unrelated reasons for a few months from 2020 to 2021). That fix just removed the stardict_dictdotcn.so plugin, which also sent translation requests to dict.cn and was later subsumed by the YouDao plugin, from the package.
It cannot be ignorance if they have been fully aware of this behaviour. As it stands, it's either maliciousness or negligence.
It isn't rare at all for bugs to surface many years later and that doesn't mean whoever was responsible for maintenance to be malicious, it is if the bug was planted on purpose, and there are some examples of that (the xz library saga, for instance). Of course, you could argue that that too was incompetence but that's not how this works: lack of oversight by others does not imply malice on the part of those others for failure to catch the issue.
Stuff like this can fly under the radar for a long time because lots of people will assume how it works without actually verifying that it really works like that.
I completely agree. Also, these people have a lot of other assignment, as I imagine. I, for one, have certainly let things slide in the past that ended up biting me, for whatever reason, malice not included.
Sufficiently advanced ignorance is indistinguishable from malice.
(but malware authors usually cover their tracks better)
guy works for a Chinese media company and he's essentially trying to slip a backdoor into Debian systems.
malice & typical CCP behavior IMHO. The responses from the maintainer are unacceptable and he should have his privileges stripped
> pressured
Maybe incentivized? $1000? $10000? Would be interesting to hear from the developer himself.
>nor do I think that they gain any advantage of it
I guess the companies receiving all this clipboard traffic are absorbing operational costs to humbly provide this surreptitious service to the world for free, and the package maintainer only wants to help them realize their mission.
We truly live in an utopia!
Willful negligence is, at some point, malicious.
No. The simplest answer is that they’re deliberately and maliciously exfiltrating data. The other explanation requires more hoops.
Why can't reasonable people disagree here? Surely if the utility of some features might outweigh the security concerns for some people. Making features opt-in instead of opt-out significantly changes their discoverability and usage metrics. On the whole, a translation system that has a feature to translate selected text seems hardly surprising. Similarly, using an online service to improve translation quality and reduce local resource usage also seems reasonable.
Fundamentally, always-online, home-phoning features are the norm, and it should be up to OS distributions to manage security postures such as allowlists for network access. Think something along the lines of "StarDict wants to connect to dict.cn. Allow/Deny?".
> Think something along the lines of "StarDict wants to connect to dict.cn. Allow/Deny?".
That is what opensnitch provides, as do some other detection tools.
https://wiki.debian.org/PrivacyIssues#Detection_tools
> Why can't reasonable people disagree here?
They can, but framing this as a mere disagreement is disingenuous: One approach might slightly inconvenience someone, while the other (as was taken here) inflicts irreparable damage.
> Fundamentally, always-online, home-phoning features are the norm,
No. Although common on certain platforms, they are not a fundamental norm in software, nor should they be.
In particular, we're talking about Debian here.
There are dozens of chrome extensions that translate (read: submit to untrusted server) on hover / highlight / context menu / textarea edit / etc. It is implied, that user acknowledges this functionality and accepts the risk. This includes untrusted server (because that's how they proxy requests to Google/Bing/Yandex Translate without exposing API keys).
Security illiteracy? Yes. Malicious intent? Probably no.
Does being security illiterate equal malicious? Debatable.
A moderately popular Chrome extension is frequently bought for tens of thousands of dollars for various purposes, frequently malware injection. They contact extension makers.
I think the bar for trust in terms of evil intent is on the floor.
No reasonable person expects privacy when using Google and/or Google provided products / software.
When you use Debian, you have a reasonable expectation of privacy.
People who handwave that away or say it's not as bad as something else either have an agenda or are ignorant about the history of Debian.
Not sure if I would call it malicious but I would call it gross negligence.
Such a response is not considered a valid defence under GDPR. You cannot sign away your right to privacy any more than you can sign away your right to life.
> You cannot sign away your right to privacy any more than you can sign away your right to life
You can literally do both in the EU with informed consent.
No, you can't.
Informed consent is (1) always going to be specific and (2) ends when the legal base for procession is no longer supported.
Struggling to see the relevance of both constraints when it comes to assisted death.
I'm not going to fault you for that, but no, you really can not sign away your right-to-life even with assisted death. The process is explicitly tooled around this to ensure that people's rights are not violated. I am not saying that there will never be a mistake made here or even that that has not possibly already happened but in principle your right-to-life is not violated by this procedure, and I realize that I will not be able to convince you otherwise.
That requires a complete re-thinking of your moral framework if you are not familiar with the concept.
Just like for some people gay marriage is inconceivable and results in them being ready to man the barricades and for others it doesn't even move the needle. And then there is abortion and bodily autonomy. Large swathes of humanity are not going to be able to understand the remainder when it comes to those subjects, they all arrive at their own conclusions through a mixture of tradition, religion, philosophy and cultural exposure (media, mostly) as well as peer pressure.
I've long ago decided that the only party that will hopefully be able to get all of those right using an objective frame of reference will be born a few thousand years from now, assuming humanity will make it that far.
> you really can not sign away your right-to-life even with assisted death. The process is explicitly tooled around this to ensure that people's rights are not violated
I’m saying that on a practical level the difference is unobservable. Part of your right to life, in this formulation, is your right to sign it away.
The terminality of a right to life makes it a poor comparison to privacy, which has no comparably-irreversible end state like death.
> I’m saying that on a practical level the difference is unobservable.
To you.
Please stop this sophistry. Assisted dying is in no way comparable to "signing away your right to life". Even if you want to reduce it to such black and white phrasing (which, quite frankly, makes you come across as an asshole), it's actually asserting ultimate control over your own life. At no point in that process are other people allowed to perform acts not specifically authorized by you.
i agree. if in 2025 ppl dont understand plaintext of user data to places on the net is bad, they should not write code nor be maintainers of oss software -_-.
how many times does everyone need to be totally compromised by some shitty software before people start to care?
innocent individuals each days are suffering hacks and malicious interactions. people are losing their livelihoods. companies are getting shutdown... what more need to happen?? :S
> i agree. if in 2025 ppl dont understand plaintext of user data to places on the net is bad, they should not write code nor be maintainers of oss software -_-.
LLMs are only going to make this worse. We're going to see a plethora of vibe coded slop everywhere.
But think of the money saved!!
Malicious intent written in the package description? I would think that really unlikely.
I think it's just a cultural difference. Sogou, a super popular Chinese input program for Windows iOS and Android does the same with everything you type and nobody cares.
I'd say that having terms of service that document your shady behavior whilst at the same time not making this obvious in the UI in any way is a tried and true (corporate) malware pattern.
Just because Microsoft did it that doesn't make it a valid defense, in fact it shows the opposite (after all, they too did not have the best interests of their users at heart). The fact that the recipient of the data sits on the other side of the GFW and that clipboards can contain very interesting data you really should wonder about the intentions of the author, they do not get the benefit of the doubt. In fact, open source software that to all intents and purposes looks like it runs locally but pumps your (private) data out without your consent is a very large red flag to me: it gains access to data that otherwise likely would never be found in the wild. At a minimum this is a fairly serious GDPR violation.
I think so too. It's cultural difference, and ignorance at most. I doubt the maintainer has control over that two random dictionary websites, or was tasked by them to do this or anything like that. They are just a different person, and they didn't give a fuck.
That doesn’t even address the problem! The package description does mention the scan feature, but not the automatically-send-it-to-a-server-in-plain-text feature.
Sure, if you read the description and the list of plugins and correctly guess how this plugin is implemented, then you can deduce some of it.
I install stuff from Debian's repos for 2 reasons. Convience & trust. And while people do complain when maintainers modify packages behavior, I think people would rather have the send my clipboard contents to someone else to be opt-in. Instead of violating their trust!
If this level of modification is required for a package to fit in with the distro's philosophy, maybe better not to include it at all.
I think the answer might be to codify some of these assumptions.
It might help set things apart from say ubuntu, which doesn't engender the same amount of trust such as opt-in.
I do agree with your point, specially when it is not the first time a package maintained by that guy does non-expected behavior like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010165 (Inappropriate package, modifies other package's (conf) files, should be removed from archive).
I disagree that "modifying other packages' conf files" is a problem. Conf files in general are there for the user to modify, and as the maintainer points out, it shouldn't matter if the user uses vi, joe, emacs or this specific tool to modify them.
The problem in this case is that the package modifies generated files belonging to another package. Making it about conffiles is bad phrasing by the bug submitter.
> If someone started reading all the package descriptions and READMEs we're meant to be thoroughly familiar with when Trixie was released a few days ago, they'd still be reading them.
That used to be viable back in the late 1990s and early 2000s when I first used Debian. It would take an afternoon of going through all the packages in dselect (does anyone here still remember dselect?) and marking the ones you wanted to install, and around the same amount of time going through every option on the kernel's menuconfig to precisely tailor the kernel to your specific hardware configuration (things were much less dynamic back then).
Nowadays, there are simply too many packages and kernel configuration options to go through (also, does anyone still use dselect?).
"If someone started reading all the package descriptions and READMEs we're meant to be thoroughly familiar with when Trixie was released a few days ago, they'd still be reading them."
Another option might be to reduce the amount of software one is "blindly"^1 using and relying upon
For example, I have been making own Linux distribution, not following Linux from Scratch (although that is a useful reference)
This is for both learning but also reliability and robustness purposes (where "robustness" includes ability to recover quickly from losing everything)
IME starting from scratch gives a better appreciation for the "inconveniences" that maintainers must endure
"Inconvenience" may be putting it mildly
Certainly, the inconvenience varies depending on the software
Some software builds even on the most deficient/broken installations
Other software is absurdly difficult to compile, often due to minor oversights, sometimes due to obivous carelessness
The wild inconsistencies from one project to another is itself part of the inconvenience
The ease with which software can be compiled by me, and presumably anyone else, on any computer, including underpowered ones, with minimal dependencies, is among the factors I consider when choosing whether to rely on any particular software
1. Here "blindly" means the user has zero curiosity about where it comes from or how it works
No comment on this particular software or the Debian maintainer
I have up on X11 many years ago
I never liked that Debian maintainers make subjective, opinionated changes to other peoples' software, especially since it seems like the majority of Debian users do not compile from source
Also, someone looked at the package and the description, that is why this issue has been raised.
"RTFM!" comments comes in flavors and bears nuances. In this case, as another commenter has pointed out, the answer smells fishy.
I have been told to "RTFM!" countless times in many places. Some of them were legitimately the correct answer in that context, in hindsight. Some were knee-jerk reactions like this.
Debian's discussion culture might be a little edgy sometimes, but this has nothing to do with Debian.
> of course a dictionary program will include code to talk to dictionary-providing web sites.
I wouldn't say that is just a given, if I've apt-get installed a dictionary I might expect that is the whole thing on my machine. It's not like we haven't had dictionaries in physical books for centuries... It seems like stardict is very much an online thing, which I suppose could be legit, but the whole thing does seem like a trap.
I's a generational thing. I would guess that someone who expects applications to phone home, on the off chance that they are actually otherwise local, is likely someone pretty young who hasn't lived in a world of locally installed software that doesn't talk to anything.
If we search for the author's bio, that seems to check out. They are a well-credentialed CS person; obviously they know that dictionary programs such as translation pop ups can have offline dictionaries, and mentions that. But they are a person of their time with an according set of "of courses".
Today, an application being locally installed and works with offline data is like a a statement of quaint chivalry, promulgated by a few remaining Don Quixotes of computing. (It saddens me to say. So much that this analogy brings me insufficient amusement.)
For many languages, there simply isn't a comprehensive dictionary file that could be redistributed legally as part of a free-software offline dictionary application. You either settle for a few thousand words put together by a handful of volunteers, or you redistribute a commercial dictionary illegally, or you have to connect to an online service to provide sufficient coverage legally.
I could buy the idea of the plugin system itself being desired (e.g. maybe I even want english definitions from Merriam-Webster or something because I like their style more than the open source database) but I think that's separate from what an app does by default. Especially on something like Debian, one should expect a FOSS-first approach whenever reasonable, and for >99% of users the reasonable default is a local dictionary.
Wiktionary is massive with 1.4M English entries [1] (3x the size of the Merriam Webster's Unabridged dictionary [2], though with a lower average quality), and CC-BY-SA-licensed[3]
[1]: https://en.wiktionary.org/wiki/Wiktionary:Statistics [2]: https://www.merriam-webster.com/help/faq-how-many-english-wo... [3]: https://en.wiktionary.org/wiki/Wiktionary:Copyrights
Yes, the abundance of English data is why I felt the need to point out that this isn't the case for other languages. (Also, the raw count from Wiktionary can be misleading if you don't take into account that there are many low-effort entries for different forms of the same word.)
Dictionaries are small! It's insane to think that a dictionary requires network access. If it did, why would I install it locally??
> Today, an application being locally installed and works with offline data is like a a statement of quaint chivalry, promulgated by a few remaining Don Quixotes of computing.
But a dictionary package has no valid reason to be online.
Wouldn't someone's expectation instead depend on the nature of the application, and what data it needs? My expectation is that an application does not access the network unless it requires a resource only available from the network. I would totally expect a "Yelp" application to make network requests as part of its core functionality. Yelp is an online service, and in order to use it, you have to talk to the network, and you're generally requesting data that might often change, so you need fresh copies. Same for an Internet browser, or ftp or git (for remotes) or things like that. I would not expect a spell checker to need to access a network because it can all be done locally and the spelling of words doesn't change often enough to need a fresh dictionary from the network over and over. And I certainly would not expect the software to send data to the network. I would also not expect a calculator application to request math function from the network or send my equations to a network service so that the network service could provide a result.
> I's a generational thing
... Is it? Dictionary apps have been working like this for more than twenty years. Babylon Pro of which stardict is pretty much a clone was doing this with already millions of users in the year 2000! Kindles work like that!
Even if it's "legit", it shouldn't be using unencrypted HTTP.
Why? Should it use the dict protocol, then?
Because without HTTPS it's trivial to MITM that clipboard content if they're always sending it via http.
People in your coffee shop on the same WiFi could read it.
I get some people don't realize that's how TCP/IP works and the firesheep stuff all happened 15 years ago. But a bit worrying to see a frequent HN contributor challenging that.
That's why we now push for Https everywhere.
>People in your coffee shop on the same WiFi could read it.
WEP has been deprecated for over 2 decades.
That has no effect on the owner of a malicious access point. HTTP over WPA2 is plaintext again the moment the AP decrypts it.
you may be surprised at the number of unsecured WiFi networks there are.
I see them in 2025 in captive portals, public libraries, and when traveling abroad.
Not all guest Wi-Fi uses a PSK. In general, assuming all networks will already be encrypted along each hop to the server is a losing assumption for users.
Https everywhere is a good start, it keeps the other plebs at the coffee shop out of your business. But it's still open to anyone with enough power to coerce a CA, which is the more concerning sort of adversary anyhow. So yes, https everywhere, but let's not stop there.
Yes, but we have widely deployed efforts like certificate transparency, and cert pinning.
The first makes such attacks widely known events, browsers report by default, and it s provable. It’s very rare.
The second allows apps to only trust specific certs or CAs, ignoring system root of trust.
I just want to clarify HTTPS in practice is quite secure.
I'll not let go of my distaste for roots of trust in any form, but you likely have a point. I'll have to learn more about this transparency thing.
How about HTTPS?
That stood out to me as well. It's a sad world when people expect even simple functionality to be a live service.
The venerable ding does well with a local dictionary - and it's packaged in Debian too
https://www-user.tu-chemnitz.de/~fri/ding/
But only english-german, sadly
At some point I started running gui apps without network access, first with firejail and then bubblewrap. This was before flatpak became a thing. I still use collection of bash scripts that built up over time to run applications in sandbox.
"words" is nothing but a list of words. It does not contain definitions for those words, which is what one expects from a dictionary.
I wonder where one files a bug report that it's misusing "dict" under "words"
Hmm, you are correct.
Dumb question... Could you do a per-word bloom filter to do online spell checking without actually disclosing the words you're checking?
a bloom filter look up is by hash, and given the relatively small set of words in english, it would be pretty easy for the server to reverse the hash sent to it. Thus a bloom filter wouldn't be very private.
Additionally, a typical spell checker feature is to provide alternative, correct, spellings, rather than just telling you whether a word is correctly spelled.
I bet there's some cool way to do this with zero-knowledge or homomorphic cryptography though!
There’s also a way simpler way: send a hash prefix to server, get a list of matches. Google Safe Browsing does this with URLs, for example.
haveibeenpwned.com does this for passwords too. I doubt you could make it work for all the smaller words though, let alone offer corrections.
You should be able to do a K-means type thing. Where your query is an entire group, and you grab the field from the chunk locally.
But you might still be able to use some frequency sampling to predict the words used, unless those chunks are very very carefully constructed.
> a bloom filter look up is by hash, and given the relatively small set of words in english, it would be pretty easy for the server to reverse the hash sent to it. Thus a bloom filter wouldn't be very private.
The typical use of a Bloom filter is to have it locally as a prefilter, not to send hashes to the server.
> I bet there's some cool way to do this with zero-knowledge or homomorphic cryptography though!
The code for which would almost certainly be larger than a fully local dictionary for any human language.
> a typical spell checker feature is to provide alternative, correct, spellings, rather than just telling you whether a word is correctly spelled.
I personally don't use that one, for me the red underline is enough.
There are two scenarios I believe, first accidentally sending a (decent) password, and second the server not learning what you actually look up.
For the first case, sending a hash would prevent the server from learning a password that is not in the dictionary, something like password5 would hash to gibberish.
For the second, the server needs to know what to actually send back. I believe Google's malicious website check works (or used to) by truncating a hash an then just sending the answer for some 128 or so websites and have the browser figure out which of them the user wanted to visit. That creates some deniability over witch website you actually visited and should be also usable to prevent the server from learnering what you actually looked up.
So yes, I think you could design a more secure Protokoll. Though general security disclaimer the people trying to read your letters probably spend more time attacking than I spend writing this post.
Just want to mention that the feature in question here is for translation, not spell checking.
>> of course a dictionary program will include code to talk to dictionary-providing web sites.
Maybe to download a dictionary, but not to provide the same services that the dictionary program provides locally.
This sort of crap makes me sure I’ll be employable forever.
I may not be on top of the latest trends, but at least I understand how computers work and what they can actually do.
Somewhat related, I was quite surprised when I discovered that my Samsung phone was sharing ALL my clipboard with all my other Samsung devices, including passwords copied into the clipboard, and even preserving the history. I can't remember if the sharing was enabled by default or I opted in by accident. I assume it also goes through their servers to reach my other devices. I could disable the sharing, but still can't turn off the clipboard history, even switching to a different keyboard, the Samsung keyboard still captures the clipboard and saves the history, when I switch the keyboard to Samsung everything is there... I guess my next phone won't be Samsung.
Yes, and we know at least Samsung TVs sell your details and what you watch to marketers and everyone.
Samsung’s privacy policy is the same for phones and TVs.
I usually suggest not to create or login with a Samsung Account on Samsung devices. It's just another opportunity for a company to get at your data.
I noticed this happening through KDE connect, where passwords copied on Linux show up in Android's clipboard history, is there a way to block passwords from being transported around like that without completely disabling clipboard sharing altogether?
KDE connect lets you disable/configure individual plugins, just disable the "Clipboard sync". I don't think it can by itself figure out that you're copying a password, at least across UI toolkits. FWIW most toolkits and browsers don't actually copy from a password input anyway.
You might want to disable KDE's clipboard history too btw, or at least find a solution that doesn't involve copying passwords. Either use the selection instead of the clipboard, or use password filling through non-clipboard channels.
Querying a local dictionary on each clipboard seems okay; having a feature to request remote dictionaries is okay; making it easy to combine both is dubious but understandable (would be better off as a special flag); but having them combined by default? That's pretty much malicious.
It's talking about querying youdao, which is more translation service. Offline translation < online translation, i.e. I don't want to fallback to local google offline translate language package unless I have no data. I don't use stardict, but it should be completely expected functionality if translating more than words like dictionary.
This entire article should be, Chinese translation program sends clipboard data to it's own website and chinese translation services, but on http.
It's really difficult to not assume malice with something like this. From the maintainer:
> The stardict has "Scan" function, when user enable this function, after user select some text, it will trigger stardict do translate for this selected text... Why the user selects some confidential data to query dictionary?
Would be funny if they couldn't tell that the text in a foreign language is confidential... maybe it's stamped "秘密".
"Sir, we have intel, the enemy is having translation server errors."
The Wayland framing at the end strikes me as misleading. This gets it exactly right:
> Or maybe StarDict would have started asking for special permissions to let it work on Wayland, and users would have accepted those defaults the same way they currently do.
Yes, that’s what it would do. Its installer might even configure that special permission automatically, without user intervention.
Malware’s gonna mal. Wayland might help defend against some things, but it’s not going to defend against packages installed as part of the distro.
It is not misleading, Wayland is better than Xorg in this particular respect.
But the other concern is part of the systemic problem. Consider that the data that was transmitted was sent in the clear!
> StarDict ... while running on X11, using Debian's default configuration, it will send a user's text selections over unencrypted HTTP to two remote servers.
> Any user who did read the description of the package, and who knew what the YouDao plugin would do, might nevertheless expect the resulting communication to at least be encrypted. But the plugin actually reaches out to its backend servers — dict.youdao.com and dict.cn — over unsecured HTTP. So, not only are these servers sent any text the user selects, but anyone who can view traffic anywhere along its path can see the same thing.
It's extra misleading, because "Wayland" isn't a thing when it comes to policy like this. Unless a compositor implements some sort of user approve/deny UI when an app requests access to the clipboard, apps on Wayland can snoop on the clipboard just as easily as on X11. I haven't run GNOME or KDE in Wayland mode, so maybe they do implement something like that, but none of the wlroots-based compositors I've tried do.
>This would normally not be much cause for concern; of course a dictionary program will include code to talk to dictionary-providing web sites.
Hey, an area I finally know something about. It depends on what you're trying to do.
The slimmed down version of a Finnish dictionary I provide in `tsk` [1] weighs in at around 30 MB, for about 250,000 Finnish words. It's small enough that I embed the whole dictionary directly into the binary and reconstruct the prefix search on the fly every time the user starts the app.
However, the much larger database which contains things like lemmatization and etymology information easily balloons up to many, many gigabytes in size. My problem domain is providing Truly Instant Lookup, keystroke by keystroke, so I can't really get around this level of memoization. The work to figure all this out was sufficient that I decided to make future versions a paid product instead [2].
Most other use cases would just call out to a server, because it's silly to think most people are going to download a giant database for that use case alone. A hybrid approach could also make a lot of sense, eg cache the most common 10,000 words locally and call out for the next 1.5 million, which are statistically extremely rare.
[1]: https://github.com/hiandrewquinn/tsk
[2]: https://taskusanakirja.com/ (offline for now until I get Digicert to certify my downloads wholesome for Windows resale)
Some context for ppl who are not paranoid, it's a very old software and not very maintained since very long time ago. I'm pretty sure HTTPS was not common at the time. And the selection scanning a very common and wanted feature in many alternatives for windows, browsers, etc.
If there's anything we can learn from it - don't use obsolete software.
While I have a lot of respect for the effort that goes into Debian, I always disliked this kind of "maximalism" from the package manager. Oh, the user wants "foo"? Let's install every software that might be even remotely useful somehow in combination with foo! Oh there is a network daemon in there? Fantastic, let's start it immediately!
I know that there is a flag to disable the installation for "recommended" packages. I just think the default is a disservice here.
I'll politely disagree.
First of all, "Recommends" is reserved for packages which enhance the functionality of the package you're installing. Without these the package will not break, but some very useful functionality might be disabled.
The package-class you're talking about is "suggests", IOW, "these packages might also be useful for you, wanna look?" section. These are not installed by default already.
On the other hand, apt and aptitude provides previews before doing something. You don't have to accept them. In aptitude's case, you can fine tune before the final commit, even.
There's a tension. Minimalism vs. user utility. Somebody told in Debian 13 release comments that "Debian will never be a end-user friendly distro". Now, you're saying that packages shouldn't install recommends by default.
What should Debian be? "An IKEAesque DIY distro", or "A more user friendly, yet very stable and vanilla distro". I vote for the latter, personally. Plus, as I told before, advanced users are free to use what they want to change.
If you want to change the default, the configuration files are at /etc/apt/conf.d/. If you want to disable feature for once, it's --no-install-recommends.
Well, as a user of one of the more "IKEAesque" distros, I guess I have made my choice ;)
And that's perfectly fine, it just means I don't align with Debian on this one. And that freedom is what Linux is all about, I guess. So it seems it's working as intended :)
Edit: And I totally get that users might often want that kind of maximalism. It's just not for me. Although starting network daemons by default might sometimes be a bridge too far, or the case described in the article here.
While I'll argue that Debian's network daemons come with very sane defaults and an accompanying AppArmor profile to prevent both network disruptions and attack surface increases, I'm certainly not with the developer of StarDict. That thing smells malicious.
...and this is what Debian Testing is actually for. To catch these types of issues.
Of course, people are free to select what they resonates with them. I'm not against more DIY distributions (I'm also contemplating using a LFS VM to explore things even further, but time is an issue), and I'm not against your personal choices. I just wanted to note the tension, and share my observations about Debian.
I agree that recommends makes sense but this is a bullshit argument:
> On the other hand, apt and aptitude provides previews before doing something. You don't have to accept them. In aptitude's case, you can fine tune before the final commit, even.
You can't expect the average user to understand the entire dependency tree and read the description of dozens of random packages that the average program pulls in. RTFM is not a valid excuse for bad defaults.
I don't expect average user to read an entire dependency tree. However, apt and aptitude does a relatively good job of explaining their actions' reasons.
Let me rephrase:
IOW, if you don't like how your system behaves, read the documents. Otherwise, I argue, current defaults is good for the benefit of the newcomer and average Linux user. If you are at a point where you are caring which package is doing what, you're leaving "average user / beginner" realm.In the case of StarDict, as I noted elsewhere, I think the developer's answer is fishy, or ill-informed at least.
Why does "caring what a package does" mean that someone is no longer a beginner?
All the people I know care what their software does.
From my experience, newbie users are generally more interested in the end result: Their intended packages are working, and what that package is doing. They are not yet interested in all the libraries required and whatnot.
As they get familiar with their systems, they get interested in what makes the particular package or software tick. Then, the digging starts. At that point they are already pretty proficient with their package managers, and start to learn their systems inside out. At that point they're not beginners since they can do targeted tinkering.
Except very rare circumstances, I didn't see anyone to dive to the deep end directly.
I guess sou just have a weird definition of "what a software does" means. Because to it is exactly about the end product.
If wondering about why some libraries are installed as a part of an application, and having a desire to learn the function of a library in that context is a "weird" definition of "wondering about what software does", then yes.
Libraries does matter. =)
This is a classic tension between convenience and security - Debian's "recommends" defaults were designed for a pre-cloud era when network connectivity wasn't assumed and local functionality was prioritized over potential security boundaries.
Actually the default value of `APT::Install-Recommends` had been false, and it was changed to true in Debian 6.0 Squeeze (2011-02-06). I didn't like the change at the time because my Debian and Ubuntu systems suddenly installed more packages by default. However, now that I think of, the distinction of recommended packages and suggested packages was blurry before the change, because both were opt-in. Auto-installing recommended packages, while allowing the user to opt out is a better default I guess. But I still turn off auto-installation of recommended packages in the systems I manage.
I don't have a problem with --install-recommends being the default. I think it's a fine distinction to have Recommends be "most of our users will want these" and "this package provides some niche feature that most users won't need".
However, like you, I do have a problem with maintainers abusing the Recommends: field to further their own world domination plans. There is no valid reason that installing an archive tool should mandate a specific init system (looking at you, file-roller and gnome team in general).
The other extreme where you are missing expected functionality because it's optional isn't any better. The problem is not that recommended dependencies are installed by default, it's that package recommendations should perhaps be more conservative. Note that Debian already differentiates between recommended dependencies (which most users should want) and suggested dependencies (related functionality or enhancements that are not relevant for every user).
For me it's my most used super long command line flag.
For a brief moment `--break-system-packages` surpassed it, then I discovered `pip` accepts abbrev flags so `--br` is enough, and sounds like bruh.
> --break-system-packages
You can avoid that clusterfuck using `uv tool install`. E.g. `uv tool install pre-commit`.
It's also not hard to just manage a damn virtual environment yourself.
That doesn't really work for tools that you want to be available everywhere.
There are numerous privacy issues in distros, some known, most probably unknown, some examples from Debian:
https://wiki.debian.org/PrivacyIssues
Luckily there are things like opensnitch that can block some of these issues:
https://github.com/evilsocket/opensnitch
Your link is about privacy issues in upstream software that Debian hasn't sufficiently worked around yet. The main advantage of the Distro model (as opposed to developer-maintained package ecosystems) is exactly that there is someone protecting you from questionable software "features".
I don't think Debian intentionally shields you from privacy-invading software. Other distros may differ on this point.
Debian does not mandate anything about privacy in its Policy Manual (which are the standards for selecting and packaging software that maintainers must adhere to): https://www.debian.org/doc/debian-policy/search.html?q=priva...
There's also no insistence on privacy in the Debian Social Contract or DFSG (not that these would be appropriate places for it, they're mainly about licensing)
> I don't think Debian intentionally shields you from privacy-invading software.
Don't they change the Firefox defaults for more privacy?
They do indeed, probably other packages have patches too.
> I don't think Debian intentionally shields you from privacy-invading software
There is a culture of valuing privacy though, including patching out privacy issues. Especially since a lot of Debian folks are from Europe, with corresponding GDPR knowledge.
I know that the lintian warnings pointing out privacy issues in HTML documentation do get a lot of patches.
Also, opensnitch is packaged as a mitigation.
You are right about the policy problem, Debian really needs to do something about that.
There is at least a privacy policy for Debian services.
https://www.debian.org/legal/privacy
Who protects you when the packagers decide to trust a shady CA (adding it to the root store) because it's used by the distro's infra?
Is this supposed to be some kind of gotcha argument? Against what?
Not exactly the same thing, but see https://en.wikipedia.org/wiki/GNU_IceCat#Additional_security....
Agreed, but it is definitely not enough, which is why some Debian folks packaged opensnitch.
Are you saying it's an ordinary behavior? There's nothing coming close in your links, especially in Debian.
That is interesting.
There is nothing in that list anything like as bad as this. The next worst is Chromium which is no surprise.
Am I the only one that gets incredibly angry when I read things like this? This is unacceptable on every level.
You're not alone. He/She needs a pi in the face bill gates style.
The easiest solution seems to be to patch it to use offline dictionaries. merriamwebster.txt is 24MB, not a big deal.
stardict --install en_US hi_IN ta_IN
For a trilingual person, just 100MB of storage. Problem solved no?
Edit: it's a full dictionary with all sorts of information. Example entry:
ABANDONED A*ban"doned, a.
1. Forsaken, deserted. "Your abandoned streams." Thomson.
2. Self-abandoned, or given up to vice; extremely wicked, or sinning without restraint; irreclaimably wicked ; as, an abandoned villain.
Syn. -- Profligate; dissolute; corrupt; vicious; depraved; reprobate; wicked; unprincipled; graceless; vile. -- Abandoned, Profligate, Reprobate. These adjectives agree in expressing the idea of great personal depravity. Profligate has reference to open and shameless immoralities, either in private life or political conduct; as, a profligate court, a profligate ministry. Abandoned is stronger, and has reference to the searing of conscience and hardening of heart produced by a man's giving himself wholly up to iniquity; as, a man of abandoned character. Reprobate describes the condition of one who has become insensible to reproof, and who is morally abandoned and lost beyond hope of recovery. God gave them over to a reprobate mind. Rom. i. 28.
I don't understand why the whole thing isn't local. A comprehensive Chinese dictionary has less than 400k words. Even at 1k per word that's less than 400MB.
It's just poor design to make something require a network connection when it could work offline locally.
Then we should have a copy-left dictionary first.
If I would be deciding, I would kick-ban StarDict immediately from the distribution, and scrutinize i) the maintainer for all the packages he has ever touched, ii) StarDict authors for allowing such a default behavior in their system.
Apple did something similar in 2015:
CVE-2015-3774
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3774
https://lists.apple.com/archives/security-announce/2015/Aug/...
You had to three-finger press to trigger it, though. Similarly, it used unencrypted HTTP. I reported it and it was fixed to use TLS.
The dev defending this unencrypted behavior is really wild, though.
Most Chinese sites do not use HTTPS. In fact, TLS 1.3 traffic seems to be completely blocked within China's internet.[1] The decision to use plain HTTP is only strange from a Western viewpoint. Note: I am not defending this behavior. I still remember the era of ISPs injecting content into webpages. But it's important to keep in mind our subset of the world does not reflect the rest of the world.
[1] https://news.ycombinator.com/item?id=24093932
It does reflect the rest of the world; China is the extreme outlier here.
Also, accessing GitHub from within mainland China works, so TLS is not completely banned.
> StarDict on Wayland doesn't have this problem, because Wayland prevents applications from being able to capture text from other applications by default.
StarDict on Wayland has a different issue, it causes a segfault.
Sat, 02 Aug 2025: Bug#1003710: stardict crash in gnome with message Segmentation fault
https://www.mail-archive.com/debian-bugs-dist@lists.debian.o...
Yeah, I don't really know much about Wayland but.... That does not sound correct to me... Wayland has a copy/paste protocol, and my 5-minute web search indicates that it works much like the X11 copy paste protocol, each application takes care of what will be sent when pasted. then some other application requests a paste, the display server connects the two they negotiate a format and the "copied" data squirts across. that is to say Wayland applications can totally capture text from other applications.
Now if the article meant to say Wayland applications are unable to capture arbitrary text via mechanisms other than then the copy paste protocol I would say fair enough, but it sounds like the problem application is using the normal X11 copy paste protocol. so I don't see how that statement is relevant.
Besides, capturing text from other applications is very much required for various utilities. It's as much of a security feature in Wayland as turning off your computer and never turning it back on is.
There is a separate, privileged, interface that this kind of utility can use.
Meanwhile, the other 99% of applications don't need unlimited permissions.
Those privileged interfaces cover known use cases but don't allow for novel tools - or even full functionality of existing tools in many cases.
You also underestimate how many programs make use of functionality that could be abused in some way. And unless you lock all those interfaces down it's all security theater. Who cares if the display protocol disallows copy paste snooping when there are a million different ways to get the the memory of other processes or the files that they store sensitive information in. And such a locked down ecosystem is antithetical to free and open computing.
I don't use my computer to be secure, I use it to get shit done and and to have fun. I'm not going to accept approaches to security that interfere with that any more than I will accept the same in real life. There aren't any bars over my windows because we have functioning police to deter criminals. I don't need lab tests done for all the food I buy because we have regulations that ensure food sold is generally safe to eat. I go outside without body armor and weapons even though someone could theoretically kill me. 100% security is always a tradeoff for quality of life.
I like it when novel tools ask me to do novel things. Malware is a novel tool.
But then StarDict would still be sending your selections out.
Personally I think the X11/Wayland distinction is moot, given this appears to be an explicit feature of StarDict, and it seems more likely it just hasn't been ported to Wayland yet.
My personal security tolerance means that I have multiple levels of firewalls and blockers: network, dns, device, and browser. It's also why I find myself scanning my DNS traffic (pihole), and running OpenSnitch.
Whether malicious or not, to me isn't the point. The point is that I, as an individual deserve the illusion of control over my data and communication. I have neither the time, nor inclination to read all release notes. Furthermore, as someone who has spent enough time writing code - I recognize that humans make mistakes and don't always update them with salient details. All the automation in the world, and AI (yes, I've tried AI for release notes) just doesn't help.
"If user don't like one of these plugin, he can disable it by himself." f.u.
Whatever is making plain HTTP requests in 2025 should be a cause of concern. Wouldn't it be nice to have a low resource daemon watching for common pitfalls alerting users so we eliminate or minimise classes of problems like this?
I think lots of windows antivirus come with features like this? Perhaps with vast crystalized kno eledge nowadays we can afford to create OSS system level package that offers some level of protection.
I might actually do it, any down side?
How would you like to be the guy that reported this 10 years ago and had the bug closed on some technicality:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960
Given enough eyeballs, all bugs are closed as WONTFIX.
It's not a technicality, the package was removed from Debian so there was no reason to keep the bug report open. And it was reopened by a debian developer when the package was reintroduced a year later.
That's not an excuse for why it wasn't dealt with until now but what you are suggesting didn't happen.
This post caught my eyes immediately because I have been sort of benefiting from StarDict project. Although I do not use it directly. I have been using sdcv, a CLI tool that reads StarDict dictionary. It’s minimal and serves me well.
Anyone else see the old UA string in strace out:
Also the \r\n in the output is irregular too.Signature, a distinctive signature that looks like.
> Part of the justification for moving to Wayland over X11 is to make security vulnerabilities relating to one application spying on another more difficult to introduce.
Yea, because, how else am I going to run shady poorly maintained dictionary software that ignores system settings from a hostile country? What kind of world are we living in with X11?!
The software could just as well hook into your downloads folder and transparently "translate" any downloaded text or PDF file for you. In which case the method by which pixels arrive on your screen would not be relevant.
How is this an X11 vs Wayland issue and not a distribution hygiene issue? Why is this package even a part of the distribution? In the desire to force one desktop system to stop existing, for whatever reason, I think they've missed the broader point.
>The software could just as well hook into your downloads folder
correct which is why wayland is only one piece in improving security, you still need proper sandboxing
By the time you have something that allows you to safety run malware you have a usability nightmare.
Flatpak'd wayland applications are super usable and they prevent the clipboard spying and the download folder shenanigans. You can edit permissions straight from KDE settings.
Of course, you can't safety just run malware in flatpak.
Qubes OS is the solution. It's indeed less convenient than ordinary GNU/Linux but still quite usable. My daily driver, can't recommend it enough.
I agree with you, this is not an X11 issue, it's a "why are we letting software like this in the repository" issue. The kind of lax attitude towards security I'd expect from a random AUR package, not in the Debian repo.
It's been in Debian for more than 20 years (see changelog here: https://tracker.debian.org/media/packages/s/stardict/changel...). It's not clear to me if said "autosend off clipboard contents" has been in there the whole time though.
Data leaking bug reported as early as 2009: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534731 , so it's not looking rosy.
Which is interesting (as according to the LWN article) it seems like the general issue of what is sent is an ever-present one for StarDict, as apparently the earlier issue was around the defaults for all dictionaries, whereas the new issue is around a specific plugin.
Personally, if I was using (or a maintainer of) a dictionary tool which autoreads the clipboard (or any dictionary tool), I'd be checking what it is doing and considering whether it is what I would want to use.
For sure. I hope that due to the noise, they finally clean this up for good.
You basically need to call a vote or ask the tech committee to rule otherwise if the maintainer says it's fine.
It's not really a bug if it's an advertised feature you don't like, so security team cannot do much in theory.
That's a bad policy then.
Write a new one and post it on debian-vote and see if it gets approved :)
> But the plugin actually reaches out to its backend servers — dict.youdao.com and dict.cn — over unsecured HTTP.
What year is it?
I assume it must be 2015 at most because my first job in 2008 ran everything, including images, on HTTPS. But I can imagine some last holdpouts 7 years after that.
Can someone recommend a completely local English-language dictionary for Debian?
I recently found wordnet through an offline dictionary/thesaurus program and thought it was a pretty neat project. https://wordnet.princeton.edu/
For my use case I was more interested in the data than the application and so never installed it and am unable to comment on how usable it is, but will include a link if you want to look. https://sourceforge.net/projects/artha/
> According to Debian's package popularity contest statistics, only 178 people have StarDict installed
A problem for those 178 people... But on a global scale this isn't really a concern.
Not everyone participates in the popularity context. By some estimates about 1% of users do: There are about a quarter million popcon responses in Debian's recent popcon graphs. Absolute number of users is hard to estimate but I find one estimate of 20-50 million Debian users. So taking 1% as a lower bound, at least 18k people use StarDict in Debian. I don't know how to guess the number that use StarDict in another OS.
In my Windows, it wouldn't be a problem. The firewall I use would pop up for any new program that tries to connect somewhere.
But Linux doesn't have a per-program firewall.
... and even if it did, there's no way to do popups/questions from the kernel,
... and even if there was, most programs would just run curl or wget or openssl. That would mean a popup for each and every connection attempt through those programs.
Windows does certain security things better than Linux OSes, which makes it such a shame that Microsoft keeps shipping more and more stuff with Windows that undermines all that work.
Opensnitch is really good on Linux
> of course a dictionary program will include code to talk to dictionary-providing web sites.
It is funny to read this considering all the rage when say Siri does this.
Should some open source contributors & maintainers be considered an APT group and tracked thecsame way?
Its a key stealing malware? Damn good I dont use it
I honestly don't think x11 is the primary problem. The package maintainer not thinking it's a big deal to send this data over http by default wouldn't be a good situation on Wayland either. They wouldn't get the clipboard but they're still not responsible. I presume this program also has full access to the filesystem.
it looks like a serious "privacy violation" for English-only users. But for many ESL or non-English users out there, the "translation" is a must.
On Windoes, I remember some translation programs go extreme, they hijack all GDI calls and scan for all strings on GUIs trying to translate and replace them inline. Local dictionary were pretty limited so many of them use online services. What happens when user input something "sensitive" on the GUI?
Well they goes straight to the translation service.
Translation isn't the problem, sending data over the network by default is. Data is leaked to Chinese dictionary servers even if you're translating between European languages using a local language according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960.
With the GDI hijacking programs you usually download them for specific languages with the knowledge they're internet connected.
> Data is leaked to Chinese dictionary servers
stardict is a Chinese software and the bug you listed says it "leaks" data to stardict.cn which is one of its official website.
https://stardict-4.sourceforge.net/index_en.php
Btw looks like the stardict.cn is dead today
> with the knowledge they're internet connected
Yeah that's pretty much the whole argument.
I do agree that programs should not send data in an arbitrary way. Clear text over public network is not OK
> But for many ESL or non-English users out there, the "translation" is a must.
As an ESL user, I vehemently disagree. You're only going to need translations as long as you keep relying on translations. Like it or not but English is the lingua franca of the computing age and you're doing yourself a disservice if you don't learn it.
> English is the lingua franca
Yes, so to learn English, ppl need some kind of "translator" tool, no?
The most comprehensive one (but very old) out there is stardict.
I cannot comment on how useful these tools are or not since I started using computers in English (there were no translations to my language back then) without any such tool or without knowing any English. I had the of speaking another Germanic language but I would say if you know some basic you can use computers without any tool assistance and learn English quickly.
No, you don't need a translator tool to learn other language. Certainly not one that automatically translates everything you copy.
Once you know the basics (which a translator won't teach you) the most effective way to become proficient is practice, which is the opposite of relying on a tool to translate things for you.
English-only users need translation too, there are lots of web resources out there only in non-English languages. I found the Bergamot offline translation tool embedded into Firefox helps a lot for that these days.
Docs is obviously designed to be misleading. If I would design a malware, this is how I would do it. Plausible deniability. Don’t fool yourself. Kick this shit, and people who develop it, out of debian asap.
Why is nobody talking about how this software sends text to servers in china over an unencrypted connection?
Meanwhile on Android:
- The clipboard can not be read by backgrounded applications
- Apps by default are unable to use HTTP
Meanwhile on Wayland: > StarDict on Wayland doesn't have this problem, because Wayland prevents applications from being able to capture text from other applications by default.
Seems irrelevant to me. I shouldn't need to defend against software provided by the official repositories. The entire point is for those to be trustworthy.
Also Wayland breaks a lot of stuff. It's certainly a move in the right direction on the whole but I wouldn't blindly interpret something like this as a win.
You are cherry picking. The next statement says that the scan feature doesn't even work on wayland. Lol. That's worse than working + buggy. (security bugs are just bugs. Nothing special about them)
> That does mean that it breaks StarDict's scan feature, though.
No, Wayland is clearly better here. Not allowing an app to do a potentially stupid privacy compromising thing is better that allowing it by default and providing no way to block it.
Better does not necessarily mean good though, that Mac approach of block by default but allow users to enable these things for specific apps on settings would be a great improvement.
The privacy compromising part is _not_ in the 'reading selection' part. It is in the part where it sends it over http to dict.cn. The solution is therefore, obviously, to replace dict.cn with an offline dictionary. Not what wayland does, which is blocking reading selections in the first place. That is brain damaged.
In the X11 case, I can uninstall the app and install one that uses an offline dictionary and gives me a scan feature. That very much is a way to "block" it. Wanting a scan feature is not wrong. It's my computer. I want it. In the Wayland case, I cannot do _anything_ about it. The X11 situation is thus obviously better.
It's not like "define current selection" is some niche feature either. It's a default feature in macOs, iOS and Android.
You either do it the macos way or the windows/x11 way. You cannot half-ass something in between. That is just security theatre and is utterly retarded. Every wayland release until it makes a macos-style permission system (I dont care whether the default is accept or deny) is pure cancer. And every distro/DE that pushes wayland onto you until that point is also cancer.
</rant>
I'm not sure how Wayland specifically prevents the privacy issue on its own (it can't block network calls), it seems it's down to not implementing the required Wayland calls, but I would be surprised if there was no portal or DBus or similar IPC to get the clipboard on Wayland (which is called out in the package description as noted by the maintainer). The issue is what the app plugin does with the clipboard data, while it's not something I want, I can see people wanting automatic lookups of words.
I think in a similar way to how xz attack required integration via systemd to exist, this is really more about defaults and integrations (which the last message from the maintainer acknowledges and seems to be fixing). https://xkcd.com/2044/ is as always an ever-present problem.
As far as I know Wayland does not protect you from Chinese malware being distributed by Debian maintainers.
Android has its fair share of issues as well. For a recent issue, take a look at the localhost tracking, wherein "Meta devised an ingenious system that bypassed Android’s sandbox protections to identify you while browsing on your mobile phone — even if you used a VPN, the browser’s incognito mode, and refused or deleted cookies in every session":
https://news.ycombinator.com/item?id=44235467
It's by design that apps on Android can talk to each other. It doesn't require a sandbox escape to do. Usually it's done via binder, but it also works through shared memory, unix sockets, network sockets, or pipes.
I get that. Well, not in the linked Facebook case, seeing how much legal attention they have attracted, but in general. And I think that the X server's design is the same. What StarDict did was using an intentional part of the design, not a hack, or exploiting vulnerability. Which is why the Android comparison doesn't stand.
And it is by design that anyone can read the X11 cilpboard so I sm not sure I get your point.
My point is it's the browser app's responsibility to add extra security before reaching out to private / loopback addresses when it wants extra privacy.
Android already provides a way to sandbox apps from one another, so if people don't want social media apps talking with other apps they can already separate them.
Which Android versions ask for permission before an app can make HTTP requests? I know it's something the app has to declare in the manifest, but other than obscure ROMs every normal version of Android just allows network usage without asking the user.
Android itself doesn't enforce it, but starting with Android 9, you have to opt in to HTTP requests rather than opt out. Most app developers don't even know about this so their applications (and the ads packaged within) cannot do plaintext HTTP calls using the normal system API.
Still doesn't prevent an ad library from bundling libcurl and doing HTTP calls manually, of course, but it's a sane default.
A society that balances cause and effect! Money is also balanced! Money flows perfectly through multiple lifetimes! Being respected ultimately leads to balance!
What?
This article smacks of paternalism.
Part of the fun of free software is that it might do terrible things. Debian is not a distro that promises you a walled garden run by an iron-fisted tyrant who beats programmers into submission so they'll respect your privacy
Nothing in Debian will install StarDict invisibly. Only you install StarDict. Only you run StarDict.
Wayland is not a panacea. If you want StarDict to translate everything you highlight/clip, you will tell Wayland to let StarDict do that. If Wayland can't do that, it's bad, paternalistic software. There is Android and iOS for idiots who want to be bossed around by their device and have no real freedom.
The real problem are these HTTP lookups by default, which is the fault of the packager, and Debian as a whole for not prodding them into fixing it.
This bug was already reported and fixed as CVE-2009-2260. Then StarDict was kicked out of Debian, and when it came back, so did this bug. The most recent re-reporting of this bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806960 raised in 2015) was fixed a few days ago by removing the dict.cn plugin, 2 days after Vincent Lefevre raised this issue on oss-security-list. He also raised CVE-2025-55014 for another dictionary plugin that sends HTTP requests, which has also been fixed by removing that plugin.
Both plugins should be removed from Trixie as of today, and more appropriately, all the "network dictionaries" are now in their own package (stardict-plugin-network-dictionary), not installed by default (stardict-plugin suggests rather than recommends it):
Changelog: https://salsa.debian.org/debian/stardict/-/blob/debian/trixi...
Control: https://salsa.debian.org/debian/stardict/-/blob/debian/trixi...> Part of the fun of free software is that it might do terrible things
Yeah you lost me here
Freedom is the freedom to say rm -rf /* and accept the consequences.
If you want to give someone else control over what you can and can't do with your machine, iOS is over there -->
False dichotomy.
Why should I expect that merely installing a dictionary will silently opt me in to sending everything in my clipboard to some third party?
You don't need some strawman tyrant to want it to require a user opt-in if that's what you really want to do
You can expect that any software might do anything, either because of a bug or because it's intentional, and you won't know until you see it happen. It's why the major FOSS licenses say things like THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
You can want software to be well behaved, and in most cases it is. But if you want some level of assurance that the software is behaved as you'd like it, some requirement in law that the software is not allowed to exist unless it meets your requirements, or the platform it runs on is neutered so it literally can't do the thing you don't want it to do -- that's where the tyrant comes in.
Again, false dichotomy. If Debian's maintainers don't put things in the package manager with dodgy behavior, that's not a walled garden like iOS
Not having to check your cereal for razor blades is also a freedom
You're asking Debian to check out all aspects of a program and hold them liable if it does something you don't like, or their volunteers does something you don't like.
That's not what Debian is doing. Debian is asking for volunteers to package the world's free software, also written by volunteers. They have their own checklists, your "dodgy behaviour" concerns aren't on it. Confirming the software meets your expectations depends on you evaluating it. If it doesn't, you can then volunteer your time to write them a bug report, which they might or might not accept and fix.
They did. The article exists. The package manager behavior was changed accordingly. It doesn't automatically include that plug-in. My understanding was you scoffed at the "paternalism" and said part of the fun is that there might be terrible behaviors. Others disagree.
Indeed there were terrible behaviours, and they were fixed. My scoffing is at people who believe these behaviours should never have happened, or it shouldn't be possible.
Unless there is a omnipotent tyrant, there will be the possibility that you encounter terrible behaviours, and the possibility that those who could fix them, don't. You can try advocating to the maintainer that they should fix it, you can even try leading a campaign against the maintainer. If they still disagree, you can fix it yourself, with the source they gave you, and you can publicise your fixed version, which people might adopt over the other version if enough people agree with you. That is the fun!
Their reaction reminds me of when the Raspberry Pi Foundation tried gaslighting us.
RPi Foundation hires a cop and brags about how cop used RPis to spy on people. People got upset. RPi Foundation acts clueless and says vegetarians and vegans were upset because they posted a picture of meat.
Now Debian is less concerned with their core tenets and more concerned with winning popularity contests, as can be evidenced by their dropping of i386 support, for instance.
Instead of seeing an issue like this and raising an alarm, examining how this possibly happened, and discussing ways of making sure it doesn't happen again, they're like, "eh, so what?"
Debian, which for ages was the last big holdout of Linuxes becoming corporate, seems to have a bleak future.