> 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...”
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).
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.
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.
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.
"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.
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 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).
> 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.)
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.
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.
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!
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 malicious intent! The developer isn't a kid, they're releasing the software for world wide use. It's a simple thing, do not send private data to remote servers without explicitly asking the user!
There definitely seems to be a cultural difference when it comes to privacy expectations from Chinese companies and western companies. Doesn't mean it's okay to do this kind of thing in a Debian package, of course, but I can understand how this could've happened.
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?
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.
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.
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).
> 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.
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".
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.
>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.
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.
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.
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.
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.
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.
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":
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.
> 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.
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 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.
but it does suggest there were a number of people who might have been broadcasting their text selections to the internet for several years. Given that people copy and paste passwords from their password managers, or select the text of sensitive emails and documents during the course of editing, that should be a significant cause for concern.
I don't know what "significant" means in this case, but a password is worth something only to those who know what the password is for and are willing to find out. I'm pretty sure all those seemingly popular "editing" plugins that read everything on the screen to send to a cloud service for "AI assistance suggestions" do far worse... and given what I've seen people do with accidentally pasting things into Google, it likely already knows a lot more than you thought it did.
I'm sure if people discovered that a Debian package offering "AI suggestions" would send the clipboard over unencrypted HTTP to two Chinese servers, it would make a similar noise.
Actively listening to the clipboard, and immediately, automatically sending the content elsewhere is akin to keylogging, spyware, plain and simple. It's a questionable practice even after accepting a huge popup, not to mention that the functionality is practically buried in TFA case.
OK, so you have the username and password. But what about where to use the credentials? Is that also copy-pasted from somewhere?
It's like coming across a key someone dropped on the road. You don't even know what it's for.
Of course all this assumes that there's even someone paying any special attention to the probably huge volume of data that these services are going to get.
I have seen people paste their seed phrase into the URL bar in Chrome, which will send it to Google for auto-complete. Even the access log itself is going to contain compromising information in that case, since that is sent a part of the query string.
> 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
Such responses to me are proof of malicious intent.
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.
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.
7 replies →
While I think the response was not well thought out, it's still a far cry from "proof of malicious intent".
4 replies →
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.
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.
2 replies →
"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.
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.
Nowadays you could use an LLM to provide a summary.
Except that the description does not tell you that it ships off your clipboard unencrypted to Chinese servers.
You're fired!
1 reply →
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).
> 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.)
Even if it's "legit", it shouldn't be using unencrypted HTTP.
Why? Should it use the dict protocol, then?
2 replies →
The venerable ding does well with a local dictionary - and it's packaged in Debian too
https://www-user.tu-chemnitz.de/~fri/ding/
That stood out to me as well. It's a sad world when people expect even simple functionality to be a live service.
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.
One might even expect a program to use a common Unix preinstalled dictionary.
"words" is nothing but a list of words. It does not contain definitions for those words, which is what one expects from a dictionary.
1 reply →
Dumb question... Could you do a per-word bloom filter to do online spell checking without actually disclosing the words you're checking?
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.
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!
4 replies →
Just want to mention that the feature in question here is for translation, not spell checking.
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.
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.
[flagged]
It's malicious intent! The developer isn't a kid, they're releasing the software for world wide use. It's a simple thing, do not send private data to remote servers without explicitly asking the user!
5 replies →
There definitely seems to be a cultural difference when it comes to privacy expectations from Chinese companies and western companies. Doesn't mean it's okay to do this kind of thing in a Debian package, of course, but I can understand how this could've happened.
That's like saying Afgans have a different idea of consent.
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."
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.
1 reply →
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.
1 reply →
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`.
> 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.
2 replies →
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.
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".
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?
2 replies →
That is interesting.
There is nothing in that list anything like as bad as this. The next worst is Chromium which is no surprise.
Are you saying it's an ordinary behavior? There's nothing coming close in your links, especially in Debian.
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.
>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)
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.
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.
> But the plugin actually reaches out to its backend servers — dict.youdao.com and dict.cn — over unsecured HTTP.
What year is it?
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.
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.
> StarDict sends X11 clipboard to remote servers
Just like any modern web browser. /s
When you copy a password from a text editor, or some text from a webpage, does Chrome or Firefox send this to their servers?
Not even /s makes sense here.
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.
3 replies →
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
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.
> 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.
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.
2 replies →
>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.
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.
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.
1 reply →
but it does suggest there were a number of people who might have been broadcasting their text selections to the internet for several years. Given that people copy and paste passwords from their password managers, or select the text of sensitive emails and documents during the course of editing, that should be a significant cause for concern.
I don't know what "significant" means in this case, but a password is worth something only to those who know what the password is for and are willing to find out. I'm pretty sure all those seemingly popular "editing" plugins that read everything on the screen to send to a cloud service for "AI assistance suggestions" do far worse... and given what I've seen people do with accidentally pasting things into Google, it likely already knows a lot more than you thought it did.
I'm sure if people discovered that a Debian package offering "AI suggestions" would send the clipboard over unencrypted HTTP to two Chinese servers, it would make a similar noise.
Actively listening to the clipboard, and immediately, automatically sending the content elsewhere is akin to keylogging, spyware, plain and simple. It's a questionable practice even after accepting a huge popup, not to mention that the functionality is practically buried in TFA case.
> a password is worth something only to those who know what the password is for
I also copy-paste my username from KeePass, so you'd pretty quickly get everything
OK, so you have the username and password. But what about where to use the credentials? Is that also copy-pasted from somewhere?
It's like coming across a key someone dropped on the road. You don't even know what it's for.
Of course all this assumes that there's even someone paying any special attention to the probably huge volume of data that these services are going to get.
4 replies →
I have seen people paste their seed phrase into the URL bar in Chrome, which will send it to Google for auto-complete. Even the access log itself is going to contain compromising information in that case, since that is sent a part of the query string.