[HN Gopher] StarDict sends X11 clipboard to remote servers
___________________________________________________________________
StarDict sends X11 clipboard to remote servers
Author : pabs3
Score : 448 points
Date : 2025-08-12 04:08 UTC (18 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| pabs3 wrote:
| 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
| fsflover wrote:
| Are you saying it's an ordinary behavior? There's nothing
| coming close in your links, especially in Debian.
| account42 wrote:
| 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".
| GrayShade wrote:
| 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?
| account42 wrote:
| Is this supposed to be some kind of gotcha argument?
| Against what?
| GrayShade wrote:
| Not exactly the same thing, but see https://en.wikipedia.
| org/wiki/GNU_IceCat#Additional_security....
| amiga386 wrote:
| 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)
| fsflover wrote:
| > I don't think Debian intentionally shields you from
| privacy-invading software.
|
| Don't they change the Firefox defaults for more privacy?
| graemep wrote:
| That is interesting.
|
| There is nothing in that list anything like as bad as this. The
| next worst is Chromium which is no surprise.
| CGamesPlay wrote:
| 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?
| netsharc wrote:
| Would be funny if they couldn't tell that the text in a foreign
| language is confidential... maybe it's stamped "Mi Mi ".
|
| "Sir, we have intel, the enemy is having translation server
| errors."
| porridgeraisin wrote:
| 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.
| Elucalidavah wrote:
| 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.
| maxglute wrote:
| 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.
| charcircuit wrote:
| Meanwhile on Android:
|
| - The clipboard can not be read by backgrounded applications
|
| - Apps by default are unable to use HTTP
| cdmckay wrote:
| 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.
| fc417fc802 wrote:
| 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.
| porridgeraisin wrote:
| 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.
| badgersnake wrote:
| 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.
| porridgeraisin wrote:
| 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>
| aragilar wrote:
| 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.
| diath wrote:
| As far as I know Wayland does not protect you from Chinese
| malware being distributed by Debian maintainers.
| gkbrk wrote:
| 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.
| jeroenhd wrote:
| 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.
| npteljes wrote:
| 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
| charcircuit wrote:
| 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.
| jeltz wrote:
| And it is by design that anyone can read the X11 cilpboard
| so I sm not sure I get your point.
| charcircuit wrote:
| 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.
| npteljes wrote:
| 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.
| CamouflagedKiwi wrote:
| > 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.
| yjftsjthsd-h wrote:
| Dumb question... Could you do a per-word bloom filter to do
| online spell checking without actually disclosing the words
| you're checking?
| markasoftware wrote:
| 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!
| shakna wrote:
| 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.
| account42 wrote:
| > 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.
| bmacho wrote:
| > 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.
| notpushkin wrote:
| 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.
| chuckadams wrote:
| haveibeenpwned.com does this for passwords too. I doubt
| you could make it work for all the smaller words though,
| let alone offer corrections.
| Sesse__ wrote:
| > 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.
| CGamesPlay wrote:
| Just want to mention that the feature in question here is for
| translation, not spell checking.
| yk wrote:
| 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.
| hdjrudni wrote:
| Even if it's "legit", it shouldn't be using unencrypted HTTP.
| sam_lowry_ wrote:
| Why? Should it use the dict protocol, then?
| rootnod3 wrote:
| How about HTTPS?
| mattmanser wrote:
| 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.
| __MatrixMan__ wrote:
| 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.
| dannyw wrote:
| 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.
| __MatrixMan__ wrote:
| 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.
| charcircuit wrote:
| >People in your coffee shop on the same WiFi could read
| it.
|
| WEP has been deprecated for over 2 decades.
| ants_everywhere wrote:
| 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.
| kstrauser wrote:
| That has no effect on the owner of a malicious access
| point. HTTP over WPA2 is plaintext again the moment the
| AP decrypts it.
| zamadatix wrote:
| 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.
| kazinator wrote:
| 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.)
| yorwba wrote:
| 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.
| zamadatix wrote:
| 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.
| piperswe wrote:
| 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
| ryandrake wrote:
| 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.
| pxc wrote:
| 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.
| mayama wrote:
| 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.
| account42 wrote:
| That stood out to me as well. It's a sad world when people
| expect even simple functionality to be a live service.
| waterhouse wrote:
| ~> wc -cl /usr/share/dict/words 235976 2493885
| /usr/share/dict/words
|
| One might even expect a program to use a common Unix
| preinstalled dictionary.
| dkiebd wrote:
| "words" is nothing but a list of words. It does not contain
| definitions for those words, which is what one expects from a
| dictionary.
| waterhouse wrote:
| Hmm, you are correct.
| delfinom wrote:
| I wonder where one files a bug report that it's misusing
| "dict" under "words"
| wat10000 wrote:
| 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.
| pantalaimon wrote:
| The venerable ding does well with a local dictionary - and it's
| packaged in Debian too
|
| https://www-user.tu-chemnitz.de/~fri/ding/
| mkesper wrote:
| But only english-german, sadly
| phkahler wrote:
| >> 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.
| bmacho wrote:
| Am I the only one that gets incredibly angry when I read things
| like this? This is unacceptable on every level.
| pcdoodle wrote:
| You're not alone. He/She needs a pi in the face bill gates
| style.
| themafia wrote:
| > 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.
| guappa wrote:
| 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.
| account42 wrote:
| That's a bad policy then.
| guappa wrote:
| Write a new one and post it on debian-vote and see if it
| gets approved :)
| akimbostrawman wrote:
| >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
| lupusreal wrote:
| By the time you have something that allows you to safety run
| malware you have a usability nightmare.
| fsflover wrote:
| 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.
| const_cast wrote:
| 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.
| npteljes wrote:
| 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.
| aragilar wrote:
| It's been in Debian for more than 20 years (see changelog
| here: https://tracker.debian.org/media/packages/s/stardict/ch
| angel...). It's not clear to me if said "autosend off
| clipboard contents" has been in there the whole time though.
| npteljes wrote:
| Data leaking bug reported as early as 2009:
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534731 ,
| so it's not looking rosy.
| aragilar wrote:
| 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.
| npteljes wrote:
| For sure. I hope that due to the noise, they finally
| clean this up for good.
| avhception wrote:
| 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.
| rfoo wrote:
| 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.
| IshKebab wrote:
| > --break-system-packages
|
| You can avoid that clusterfuck using `uv tool install`. E.g.
| `uv tool install pre-commit`.
| zahlman wrote:
| It's also not hard to just manage a damn virtual
| environment yourself.
| bayindirh wrote:
| 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.
| avhception wrote:
| 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.
| bayindirh wrote:
| 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.
| account42 wrote:
| 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.
| bayindirh wrote:
| 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.
| ioasuncvinvaer wrote:
| 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.
| bayindirh wrote:
| 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.
| ioasuncvinvaer wrote:
| I guess sou just have a weird definition of "what a
| software does" means. Because to it is exactly about the
| end product.
| bayindirh wrote:
| 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. =)
| account42 wrote:
| 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).
| ethan_smith wrote:
| 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.
| barosl wrote:
| 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.
| tremon wrote:
| 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).
| sugarpimpdorsey wrote:
| > 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.
| jacquesm wrote:
| Such responses to me are proof of malicious intent.
| avhception wrote:
| While I think the response was not well thought out, it's
| still a far cry from "proof of malicious intent".
| account42 wrote:
| 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.
| vpribish wrote:
| 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.
| jacquesm wrote:
| 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.
| JumpCrisscross wrote:
| > _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.
| rangerelf wrote:
| 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.
| sejje wrote:
| > That sentence right there would kill their userbase
|
| No, it wouldn't. People don't take privacy very
| seriously.
| devmor wrote:
| If this were about a Windows or MacOS program, sure.
|
| The overlap between Linux desktop users and digital
| privacy concerns is pretty large.
| bornfreddy wrote:
| This is Debian, of course they do.
|
| But it wouldn't kill their userbase because nobody reads
| the package descriptions anyway.
| ASalazarMX wrote:
| 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
| CorrectHorseBat wrote:
| 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.
| jacquesm wrote:
| 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.
| npteljes wrote:
| 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.
| npteljes wrote:
| 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.
| blackhaz wrote:
| But it cannot be adequately attributed to ignorance, so no,
| Hanlon's razor does not apply. There is an obvious security
| breach.
| npteljes wrote:
| 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.
| jacquesm wrote:
| 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.
| npteljes wrote:
| 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.
| ploxiln wrote:
| 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.
| tremon wrote:
| It cannot be ignorance if they have been fully aware of
| this behaviour. As it stands, it's either maliciousness
| or negligence.
| poemxo wrote:
| 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.
| npteljes wrote:
| 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.
| jeltz wrote:
| 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
| npteljes wrote:
| 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.
| guappa wrote:
| Can the problem be fixed without making the software
| useless?
| jacquesm wrote:
| 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.
| guappa wrote:
| In that language...
| tremon wrote:
| Since it has been shown to be possible in other
| languages, why wouldn't it be?
| npteljes wrote:
| 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
| sim7c00 wrote:
| 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.
| guappa wrote:
| Does this service exist?
| rangerelf wrote:
| 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?
| bornfreddy wrote:
| 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".
| ASalazarMX wrote:
| The bad actors have become too good at acting like well-
| meaning klutzes.
| Gibbon1 wrote:
| 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.
| Terr_ wrote:
| Right, there are times where the "algorithm" falls over
| because of pathological inputs.
| vorgol wrote:
| > pressured
|
| Maybe incentivized? $1000? $10000? Would be interesting to
| hear from the developer himself.
| npteljes wrote:
| >nor do I think that they gain any advantage of it
| ASalazarMX wrote:
| 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!
| frumplestlatz wrote:
| Willful negligence is, at some point, malicious.
| chuckadams wrote:
| Sufficiently advanced ignorance is indistinguishable from
| malice.
|
| (but malware authors usually cover their tracks better)
| dingnuts wrote:
| 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
| rusk wrote:
| 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.
| JumpCrisscross wrote:
| > _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.
| jacquesm wrote:
| 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.
| JumpCrisscross wrote:
| Struggling to see the relevance of both constraints when
| it comes to assisted death.
| jacquesm wrote:
| 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.
| JumpCrisscross wrote:
| > _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.
| jacquesm wrote:
| > I'm saying that on a practical level the difference is
| unobservable.
|
| _To you._
| tremon wrote:
| 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.
| Lockal wrote:
| 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.
| jeltz wrote:
| Not sure if I would call it malicious but I would call it
| gross negligence.
| DonHopkins wrote:
| >Security illiteracy? Yes.
|
| Security illiteracy is admitting you were wrong and
| changing it when somebody points it out.
|
| >Malicious intent? Probably no.
|
| Are you graciously making excuses for malicious intent
| without considering all the facts? Probably yes.
|
| >Does being security illiterate equal malicious? Debatable.
|
| Refusal to admit there is a problem and fix it, or carrying
| the water for people who refuse to admit they made a
| mistake, is deliberate maliciousness, not security
| illiteracy. Not debatable.
| Lockal wrote:
| Illiterate is "inability to read and write" by
| definition. I know people who submitted bug reports
| requesting: "hi, I want to use your API, please add
| wildcard origin header", after getting explanation they
| propose "ok, JUST add my domain, I'm an opensource
| contributor, trust me". They ask to remove security
| features, recognizing them as security features, but only
| caring about their convenience (like "don't enforce 2fa",
| "don't warn about untrusted links"). They don't know
| about defense in depth and even if you explain them, they
| will skip your explanation, because they can't read.
| guappa wrote:
| The fix is to remove the package...
| jacquesm wrote:
| And to scan all of the other packages for phoning home
| without very explicitly informing the user about it and
| kicking them out if they don't.
| guappa wrote:
| https://packages.debian.org/search?searchon=names&keyword
| s=o...
| oblio wrote:
| 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.
| johnklos wrote:
| 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.
| thegrimmest wrote:
| 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?".
| foresto wrote:
| > 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.
| sim7c00 wrote:
| 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
| thewebguyd wrote:
| > 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.
| jacquesm wrote:
| But think of the money saved!!
| bayindirh wrote:
| "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.
| jraph wrote:
| "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
| tomsmeding wrote:
| For the uninformed: this is a quote from The Hitchhiker's
| Guide to the Galaxy.
| Sesse__ wrote:
| You mean, for those who couldn't be bothered to click the
| link under a joke.
| Y-bar wrote:
| 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.
| jraph wrote:
| Thanks for giving the reference right here. I should have
| in addition to the link!
| m463 wrote:
| the reference was available with a minor full-text search
| of the internet.
| wat10000 wrote:
| 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.
| fodmap wrote:
| 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).
| tremon wrote:
| 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.
| chainingsolid wrote:
| 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!
| zahlman wrote:
| 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.
| m463 wrote:
| 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.
| juujian wrote:
| Also, someone looked at the package and the description, that
| is why this issue has been raised.
| cesarb wrote:
| > 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?).
| qwertox wrote:
| "If user don't like one of these plugin, he can disable it by
| himself." f.u.
| est wrote:
| 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.
| jeroenhd wrote:
| 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.
| est wrote:
| > 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
| account42 wrote:
| > 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.
| est wrote:
| > 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.
| account42 wrote:
| 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.
| jeltz wrote:
| 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.
| sugarpimpdorsey wrote:
| 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.
| account42 wrote:
| 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.
| qwertox wrote:
| > 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...
| account42 wrote:
| 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.
| WhyNotHugo wrote:
| There is a separate, privileged, interface that this kind of
| utility can use.
|
| Meanwhile, the other 99% of applications don't need unlimited
| permissions.
| aragilar wrote:
| 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.
| account42 wrote:
| 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.
| chuckadams wrote:
| I like it when novel tools _ask_ me to do novel things.
| Malware is a novel tool.
| somat wrote:
| 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.
| cik wrote:
| 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.
| hiAndrewQuinn wrote:
| >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)
| Inityx wrote:
| > But the plugin actually reaches out to its backend servers --
| dict.youdao.com and dict.cn -- over unsecured HTTP.
|
| What year is it?
| jeltz wrote:
| 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.
| blackhaz wrote:
| 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.
| sbinnee wrote:
| 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.
| DonHopkins wrote:
| >The reality is that Linus's law ("given enough eyeballs, all
| bugs are shallow") only holds up if people are looking -- and if,
| once they have looked, and have reported things, the people who
| have taken up maintenance of the software actually agree that
| there is a problem.
|
| The reality is that Linus is not to blame for "Linus's Law",
| because Eric S Raymond made it up and misleadingly attributed it
| to him, and it's unmitigated bullshit (just like so many other of
| ESR's fallacious racist, sexist, homophobic, Islamophobic
| beliefs), which was refuted a long time ago by HeartBleed and
| many other incidents.
|
| Theo De Raadt pinpointed the irony of trusting ESR's theatrical
| security claptrap about "many eyes":
|
| "My favorite part of the "many eyes" argument is how few bugs
| were found by the two eyes of Eric (the originator of the
| statement). All the many eyes are apparently attached to a lot of
| hands that type lots of words about many eyes, and never actually
| audit code." -Theo De Raadt
|
| https://news.ycombinator.com/item?id=35940773
|
| >tptacek on May 14, 2023 | parent | context | favorite | on: The
| Cathedral and the Bazaar (1999)
|
| >Just taken on its merits, I think a case can be made that this
| is one of the most overrated pieces of technical writing of the
| last 25 years. What's true in it isn't interesting ("the
| importance of having users", "release early release often") and
| what's interesting isn't true ("Linus's law" being perhaps the
| most notorious example). Much of the insight is taken directly
| from Brooks. The whole piece has as its backdrop the development
| of Fetchmail, which is not a well-regarded piece of software.
|
| >What's notable about Cathedral is its timing; it did capture the
| zeitgeist of what was an important moment in the computing field,
| the moment where we transitioned from 386bsd-style hobby projects
| to an industry run on free and open source software. But Raymond
| isn't the reason why any of that happened, and much of his
| description of that moment is faulty; the rest of it is just a
| retrospective of the engineering decisions involved in the
| writing of a midlist mail processing utility (fetchmailrc syntax,
| password encryption, the now-largely-irrelevant distinctions
| between MDAs and MTAs).
|
| >Even the high-level organizing notion of "cathedrals" and
| "bazaars", which should have been a lay-up, hasn't really proven
| out.
|
| https://en.wikipedia.org/wiki/Linus%27s_law#Validity
|
| >Validity
|
| >In Facts and Fallacies about Software Engineering, Robert Glass
| refers to the law as a "mantra" of the open source movement, but
| calls it a fallacy due to the lack of supporting evidence and
| because research has indicated that the rate at which additional
| bugs are uncovered does not scale linearly with the number of
| reviewers; rather, there is a small maximum number of useful
| reviewers, between two and four, and additional reviewers above
| this number uncover bugs at a much lower rate.[4] While closed-
| source practitioners also promote stringent, independent code
| analysis during a software project's development, they focus on
| in-depth review by a few and not primarily the number of
| "eyeballs".[5]
|
| >The persistence of the Heartbleed security bug in a critical
| piece of code for two years has been considered a refutation of
| Raymond's dictum.[6][7][8][9] Larry Seltzer suspects that the
| availability of source code may cause some developers and
| researchers to perform less extensive tests than they would with
| closed source software, making it easier for bugs to remain.[9]
| In 2015, the Linux Foundation's executive director Jim Zemlin
| argued that the complexity of modern software has increased to
| such levels that specific resource allocation is desirable to
| improve its security. Regarding some of 2014's largest global
| open source software vulnerabilities, he says, "In these cases,
| the eyeballs weren't really looking".[8] Large scale experiments
| or peer-reviewed surveys to test how well the mantra holds in
| practice have not been performed.[10]
|
| >Empirical support of the validity of Linus's law[11] was
| obtained by comparing popular and unpopular projects of the same
| organization. Popular projects are projects with the top 5% of
| GitHub stars (7,481 stars or more). Bug identification was
| measured using the corrective commit probability, the ratio of
| commits determined to be related to fixing bugs. The analysis
| showed that popular projects had a higher ratio of bug fixes
| (e.g., Google's popular projects had a 27% higher bug fix rate
| than Google's less popular projects). Since it is unlikely that
| Google lowered its code quality standards in more popular
| projects, this is an indication of increased bug detection
| efficiency in popular projects.
|
| Datamation: Does Heartbleed Disprove 'Open Source is Safer'?
|
| https://www.datamation.com/open-source/does-heartbleed-dispr...
|
| >Taken together, Segglemann's and de Raadt's comments also
| suggest that assuming no special effort is needed to discover
| bugs is a mistake. Perhaps more attention needs to be paid to
| formal reviews and software testing than FOSS traditionally has
| managed. The fact that FOSS development often involves remote
| cooperation does not mean that log-in test or in-person testing
| sessions could not be added to many project's development cycle.
|
| >What Heartbleed proves is that FOSS needs at to examine the
| unexamined assumption it has held for years. Greg DeKoenigsberg,
| a vice president at Eucalyptus Systems, summed up the situation
| neatly on Facebook: "we don't put enough eyes in the right
| places, because we assume [bug-detection] will just happen
| because of open source pixie dust -- and now we're paying the
| price for it."
|
| ZDNet: Did open source matter for Heartbleed?
|
| https://www.zdnet.com/article/did-open-source-matter-for-hea...
|
| >Open source does not provide a meaningful inherent security
| benefit for OpenSSL and it may actually discourage some important
| testing techniques. Also, panhandling is not a good business
| model for important software like OpenSSL.
| angled wrote:
| A great comment, but your brief mention of fetchmail brought
| back a flood of memories of .fetchmailrc's and watching dots on
| screen as I downloaded my mail from POP3 servers over all sorts
| of horrible baud rate modems, before I sensibly switched to
| sending and retrieving my email via UUCP.
| zahlman wrote:
| [flagged]
| DonHopkins wrote:
| [flagged]
| paffdragon wrote:
| 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.
| nullify88 wrote:
| 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.
| dannyw wrote:
| 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.
| yonatan8070 wrote:
| 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?
| eadmund wrote:
| 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.
| heresie-dabord wrote:
| 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.
| londons_explore wrote:
| > 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.
| frumiousirc wrote:
| 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.
| amiga386 wrote:
| 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...
| stardict (3.0.7+git20220909+dfsg-8) unstable; urgency=medium
| * remove stardict_youdaodict.so plugin from stardict-plugin
| package, Closes: #1110370 * split network-dictionary
| plugin to a new binary package stardict-plugin-network-dictionary
| * add d/NEWS.Debian -- xiao sheng wen
| <atzlinux@sina.com> Mon, 11 Aug 2025 10:46:11 +0800
| stardict (3.0.7+git20220909+dfsg-7) unstable; urgency=medium
| * d/stardict-plugin.install:not install stardict_dictdotcn.so,
| Closes: #806960 * d/rules:Added --disable-dictdotcn
| option, dictdotcn is not provid server now -- xiao sheng
| wen <atzlinux@sina.com> Wed, 06 Aug 2025 14:09:39 +0800
|
| Control:
| https://salsa.debian.org/debian/stardict/-/blob/debian/trixi...
| 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}),
| anonymars wrote:
| > Part of the fun of free software is that it might do terrible
| things
|
| Yeah you lost me here
| amiga386 wrote:
| 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 -->
| anonymars wrote:
| 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
| M95D wrote:
| 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.
| ziml77 wrote:
| 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.
| const_cast wrote:
| Opensnitch is really good on Linux
| st3fan wrote:
| > 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.
| st3fan wrote:
| Why is nobody talking about how this software sends text to
| servers in china over an unencrypted connection?
| computator wrote:
| Can someone recommend a completely local English-language
| dictionary for Debian?
| somat wrote:
| 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/
| johnklos wrote:
| 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.
| hoppp wrote:
| Its a key stealing malware? Damn good I dont use it
| pbohun wrote:
| 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.
| slanterns wrote:
| Then we should have a copy-left dictionary first.
| 737min wrote:
| Should some open source contributors & maintainers be considered
| an APT group and tracked thecsame way?
| sneak wrote:
| 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.
| koito17 wrote:
| 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
| utbabya wrote:
| 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?
| kingforaday wrote:
| Anyone else see the old UA string in strace out:
| User-Agent: Mozilla/4.0(compatible;MSIE 5.00;Windows 98)
|
| Also the \r\n in the output is irregular too.
| neverrroot wrote:
| Signature, a distinctive signature that looks like.
| asveikau wrote:
| 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.
| aakkaakk wrote:
| 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.
___________________________________________________________________
(page generated 2025-08-12 23:01 UTC)