https://bugs.kde.org/show_bug.cgi?id=464142
--- Comment #3 from Pedro V <voidpointertonull+bugskde...@gmail.com> --- I'm just somewhat guessing, especially trying to guess what could have been your issue, not agreeing with how it currently works, and that's also why I'm not really experienced with it because I don't really view it as secure either, I just see the logic how it makes sense that bidirectional sharing results in chained propagation, and users preferring convenience over security are likely okay with it. Generally KDE Connect doesn't really seem to be too security focused (yet), pairing establishes an overly trusting configuration by default. Still, what you likely experienced isn't really what I'd conclude as A and C trusting each-other, they can't do anything without B proxying, so the issue is with the lack of finer grained control/permissions instead of a security bug existing. What could have happened: - A notices clipboard change, sends new data to B - B gets new data, writes to clipboard - B notices clipboard change, sends new data to C - C gets new data, writes to clipboard Technically there could be an option to explicitly break chaining by making sure the clipboard changes coming from KDE Connect itself are not propagated, but I still believe that the earlier proposed solutions are the right way. The issue isn't really any different than what would you have with other P2P solutions. For example if Syncthing is used to share a directory from A to B, and B would share it with C, then you'd still have the same issue, and the solutions there are pretty much similar to what I proposed: - There's no "automatic" data sending in the sense that you can choose to use another directory first, and only copy the result to the shared one when you are ready to share. Clipboard is quite different, so an optional explicit send operation would be more sensible there as you can't choose to use an alternative clipboard if you don't want to send, you just want to copy around information locally. - Directories can be set as "Send & Receive", "Send Only", or "Receive Only". You can't actually have a receive only directory shared with 2 completely unrelated senders due to the resulting conflicts, but in this case the clipboard is simpler, you could set up B to only receive from A and C without sending to them, so the other hosts would be able to send new data, but they would never receive any. Also, alternatively just like manual sending, manual receiving could be possible, it may as well be an optional automatic prompt popping up allowing new clipboard content to be accepted if the user wishes to do so. Still, these are just proposals how could it be better, but many users might be okay with the current complete trust approach already even if it's not appealing for us. Look at this "A <-> B <-> malware"-kind of example on a completely different platform: https://www.youtube.com/watch?v=xZBDmI9fdbs Of course others also having the same problem doesn't make it right, just pointing out that it's not considered a bug, it's a permissiveness issue arising from the coarse grained control of just either propagating widely, or not using the functionality at all. -- You are receiving this mail because: You are watching all bug changes.
