I completely agree. If only Windows also had WinKey+C/X/V as shortcuts, it would make so much sense in other Windows software too. Same with ALT+TAB and ALT+F4, CTRL+SPACE etc, these should also be handled by the win key. Then the Win/Cmd key would be assigned to OS functions, and the rest of them could be assigned to application functions, providing a clean separation.
Ctrl is different. Alt and Win don't cancel themselves when released, they are modal, and modal sucks. Ctrl is the only safe key besides Fn, so repurpose Fn if you must.
"Lightweight" here doesn't stop it from proper cryptography. In this case, the qualifier doesn't take away from the original meaning, just focuses it on a subset. Like "public-key cryptography".
Nothing stops us from qualifying "cryptography" with an adjective to refer to a specific part of it, while still referring to full-fledged cryptography. See the Wikipedia article for examples.
Those qualifiers in front of cryptography are very different from lightweight. Lightweight doesn’t convey a good meaning in general and that is the main issue.
I haven’t looked at the lightweight crypto proposals though but if NIST is proposing it I am optimistic. If the proposals from various cryptographers around the world made through all the process it’s pretty good.
This is now besides the original point, which was that in cryptography's case, "lightweight" would work like "alternative" works for "alternative medicine".
However if we shift the focus to marketing, lightweight works nothing like that in that regard. They use it to imply that the product is fast, lean, to the point, contains nothing unnecessary, has fewer, but solid options, energetic, aspiring. Implying that the other products are heavier, bulkier, cumbersome, bloated, slow, overcumbered, overly complex.
It's already used in for example LDAP, which I don't think anyone scoffs at (well, with regards to the lightweight qualifier), and lightweight software has its own wiki page, implying that the usage of the term wrt/ software is widespread enough to be notable. They write that this means "a computer program that is designed to have a small memory footprint, low CPU usage, overall a low usage of system resources".
All this to write that lightweight conveys a good meaning indeed. About the only widespread negative usage I can think of is when people call others "lightweights", implying that they performed below expectations.
I hear you, but they could have chosen performant crypto or low power crypto or some variant like that. For many lightweight reminds them of low effort ciphers. I see your point though
For me if it comes from NIST, I trust it (even with their past shenanigans) because I know the process they use and also they only produce these standards to be used for federal governent software. So they will do a good job.
I agree with you, this is not an X11 issue, it's a "why are we letting software like this in the repository" issue. The kind of lax attitude towards security I'd expect from a random AUR package, not in the Debian repo.
Which is interesting (as according to the LWN article) it seems like the general issue of what is sent is an ever-present one for StarDict, as apparently the earlier issue was around the defaults for all dictionaries, whereas the new issue is around a specific plugin.
Personally, if I was using (or a maintainer of) a dictionary tool which autoreads the clipboard (or any dictionary tool), I'd be checking what it is doing and considering whether it is what I would want to use.
Android has its fair share of issues as well. For a recent issue, take a look at the localhost tracking, wherein "Meta devised an ingenious system that bypassed Android’s sandbox protections to identify you while browsing on your mobile phone — even if you used a VPN, the browser’s incognito mode, and refused or deleted cookies in every session":
It's by design that apps on Android can talk to each other. It doesn't require a sandbox escape to do. Usually it's done via binder, but it also works through shared memory, unix sockets, network sockets, or pipes.
I get that. Well, not in the linked Facebook case, seeing how much legal attention they have attracted, but in general. And I think that the X server's design is the same. What StarDict did was using an intentional part of the design, not a hack, or exploiting vulnerability. Which is why the Android comparison doesn't stand.
My point is it's the browser app's responsibility to add extra security before reaching out to private / loopback addresses when it wants extra privacy.
Android already provides a way to sandbox apps from one another, so if people don't want social media apps talking with other apps they can already separate them.
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.
Hanlon's razor applies here, I think. It's just ignorance, not malice. I doubt the maintainer has connection, or was pressured by these two random dictionary websites to include this - nor do I think that they gain any advantage of it.
People need to be on the lookout though, the xz incident showed that FOSS is indeed vulnerable.
Not only is it outdated, the Nolnah's razor (reverse form of Hanlon) is more likely to be true nowadays: "Never attribute to incompetence that which is adequately explained by malice".
Wholesale violations of legal and social norms as the secret sauce that will give your company a leg up? Sure if we get caught the stockholders will have to pay to keep our asses out of jail. But we'll get to keep our share of the loot.
use TLS enabled dictionary service. if there is none, you dont want this feature. at all. make sure they click through something or explicitly enable is even hard as you cannot assume a user understands the impact. they might not understand what it means to send their data over plaintext, or what someone can do with it.
I don't want this feature with TLS either. Sometimes I copy passwords from my password manager to paste into the intended app. I don't want everything that enters my clipboard sent to a third party.
Will the existence or lack thereof excuse the absolute lack of security and privacy this package exhibits? And the lack of interest from the developer?
I think that in today's polarized world, it's very much needed. I think we need to look at each other's fallibilities and failures, and not hate each other for it. But the issue needs to be taken care of, especially since it's known since 2009. It's ridiculous that everyone let if fly for so long.
Yes, but it is a tricky situation when a common tactic is to pretend to be ignorant. For example by "just asking questions". We need more patience and respect in this polarized world but at the same time there are a minority of malicious actors who intentionally abuse any assumption of good faith given
The federal government "exercise[s] exclusive Legislation in all Cases whatsoever, over such District (not exceeding ten Miles square) as may, by Cession of particular States, and the Acceptance of Congress, become the Seat of the Government of the United States."
I definitely consider it a security breach. But I do still think it's ignorance. Debian maintainers let it slide since 2009, so for at least 16 years now (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534731) - are they also malicious? I just think that not enough fucks were given.
Debian maintainers in 2009 did not let it slide, they did fix it in 2009 ... but it came back, twice! (and it seems not many cared about StarDict in 2015 to fix it promptly that time)
> the same kind of problem was reported by Pavel Machek in 2009 and again by "niekt0" in 2015. The 2009 bug was solved by patching the application's default configuration to disable networked dictionaries. That appears to have worked for a time, but the YouDao plugin, which was added in 2016, does not respect the configuration option. The 2015 problem was not fixed until August 6 of this year (although the package was removed from Debian for unrelated reasons for a few months from 2020 to 2021). That fix just removed the stardict_dictdotcn.so plugin, which also sent translation requests to dict.cn and was later subsumed by the YouDao plugin, from the package.
It isn't rare at all for bugs to surface many years later and that doesn't mean whoever was responsible for maintenance to be malicious, it is if the bug was planted on purpose, and there are some examples of that (the xz library saga, for instance). Of course, you could argue that that too was incompetence but that's not how this works: lack of oversight by others does not imply malice on the part of those others for failure to catch the issue.
Stuff like this can fly under the radar for a long time because lots of people will assume how it works without actually verifying that it really works like that.
I completely agree. Also, these people have a lot of other assignment, as I imagine. I, for one, have certainly let things slide in the past that ended up biting me, for whatever reason, malice not included.
I guess the companies receiving all this clipboard traffic are absorbing operational costs to humbly provide this surreptitious service to the world for free, and the package maintainer only wants to help them realize their mission.
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.
Yes, I do feel strongly about attributing malice to someone who I think didn't warrant it. Especially do I think that they are not malicious, because of the fact that they don't admit to their doing as a security hole, but as functionality. And I do care about security a lot - if this was on my software repository, I'd frankly pull the package until it's fixed.
>why it's not malicious to write and distribute a program that sends passwords and other sensitive information over unencrypted http in 2025
One of the reasons is that it has been like that since at least 2009, so for 16 years.
I'm not defending the bug. It's a glaringly stupid thing to do, and distribute, and it questions the competency of everyone involved. I do maintain that it's not malicious intent.
reply