Meanwhile on Android:

- The clipboard can not be read by backgrounded applications

- Apps by default are unable to use HTTP

Meanwhile on Wayland: > StarDict on Wayland doesn't have this problem, because Wayland prevents applications from being able to capture text from other applications by default.

▲

fc417fc802 6 days ago | parent | next [-]

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 6 days ago | parent | prev | next [-]

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 6 days ago | parent [-]

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 6 days ago \| parent \| next [-]
		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 6 days ago \| parent \| prev [-]
		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 5 days ago | parent | prev [-]

As far as I know Wayland does not protect you from Chinese malware being distributed by Debian maintainers.

▲

npteljes 6 days ago | parent | prev | next [-]

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 5 days ago | parent [-]

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.

▲

npteljes 5 days ago | parent | next [-]

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.

▲

jeltz 5 days ago | parent | prev [-]

And it is by design that anyone can read the X11 cilpboard so I sm not sure I get your point.

	▲	charcircuit 5 days ago \| parent [-]
		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.

▲

gkbrk 6 days ago | parent | prev [-]

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 6 days ago \| parent [-]
		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.