• 0 Posts
  • 179 Comments
Joined 2 years ago
cake
Cake day: June 15th, 2023

help-circle


  • Why do you assume they haven’t warned Mozilla in advance?

    Also, Mozilla was fully aware that what they were doing is in breach of GDPR. I find it extremely hard to believe that the makers of Firefox are not fully familiarized with it by now.

    Last but not least Mozilla is doing this for financial gain. It’s selling pur data to advertisers. Why should we excuse it? It’s a very hostile act.

    If Mozilla has hit rock bottom and has been reduced to selling our data to survive then that’s that. We’ll find another way and another FOSS browser. Accepting it is not an option.







  • lemmyvore@feddit.nltoLinux Gaming@lemmy.mlNeed distro advice
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    6 months ago

    Similarly, a flower pot falling on your head is not a hypothetical, it just hasn’t happened to you.

    But does it mean you should wear a helmet every time you go outside?

    To begin with, the probability of keylogging being used in an attack against you is abysmal. Not because it can’t be done, but because it’s a complicated, inefficient attack, and if the attacker can run code on your machine there are much better ones.

    Secondly, keylogging is still possible on Wayland, if the malicious code can attach to the relevant processes. Such as a vulnerability in your browser, which also happens to be a place where you type passwords and CC numbers a lot.

    Third, as Wayland evolves it will have to develop better IPC features. You can’t have a functional desktop with zero communication. And we’ll be back to square one.

    Fourth, desktop communication is not even that sensitive. 99% of it is stuff like “window id 0x09123 was maximized”.

    Last but not least, if keylogging were a real issue, don’t you think it would have been addressed in the 40 years that X11 and Xorg have been around? It’s fascinating how some people think that Wayland was the first to discover this previously completely unknown threat that threatens to doom us all.


  • lemmyvore@feddit.nltoLinux Gaming@lemmy.mlNeed distro advice
    link
    fedilink
    English
    arrow-up
    2
    ·
    6 months ago

    keyloggers is because it allows an attacker to perform privilege escalation by recording your sudo/root password and automating an attack

    So does putting a script called sudo in your PATH.

    Keylogging is one of the lamest, most inefficient methods of attack. If you can run code on someone’s machine there are so many other things you can do.

    The fact Wayland has wasted so much time and complicated things so much focusing on a non-issue is mind-blowing.

    The majority of users do not use such tools and should probably use Wayland.

    Don’t worry, this is not the only thing holding back Wayland adoption.


  • lemmyvore@feddit.nltoLinux Gaming@lemmy.mlNeed distro advice
    link
    fedilink
    English
    arrow-up
    2
    ·
    6 months ago

    Do you sandbox each and every process? Do you whitelist everything each process can do? Every file it can access, every which way it can use the network, every bit of CPU and RAM and hardware resource it can use?

    If you don’t do that, why do you want to impose upon me a complete block of inter-window communication, which I use for desktop automation, and which has basically zero security impact in the wild?

    I don’t mind Wayland having security features, but why are they so heavy-handed and non-optional? Things like firewalls, AppArmor, cgroups, they’re all customizable. Why is Wayland all or nothing?


  • lemmyvore@feddit.nltoLinux Gaming@lemmy.mlNeed distro advice
    link
    fedilink
    English
    arrow-up
    3
    ·
    6 months ago

    Again, if you have malicious code running on your computer it can do lots of things. It can access your files, the network etc. You have to keep an eye on security vulnerabilities all the time anyway, which thanks to FOSS is easier. You’re pigeonholing on keylogging but there are lots of ways that malicious code can hurt.

    Windows has chosen to go the route of allowing malware in and dealing with the fallout later. It didn’t work out so great. UNIX and Linux have been on the side of not allowing malware in at all if possible.

    If you want to use a system that restricts access to all apps to all resources all the time you can, but I think you’ll find it very limiting and inconvenient. But it would be your choice.

    In the meantime, if my choice is to disregard the purely hypothetical threat of keylogging, I should be able to do that, especially since breaking inter-window communication also breaks all desktop automation.

    And that’s why I don’t use Wayland: it broken desktop automation and it won’t give us a choice in the matter, for the sake of one, randomly selected, purported security issue.







  • But you don’t have to develop anything. There are plenty of ready-made excellent tools you can just drop-in. The main fallacy is that what Github does is actually useful, or that the pieces it integrates are useful. 90% of Github is subpar for any given purpose. Consider all the possible types of software being developed and all the different release flows and support/issue flows, how could they possibly be shoehorned into a one-size-fits-all? Yet people try their damnest to do exactly that.

    To do software development you need (A) issue tracking, (B) a clear release flow, and © a deploy mechanism that’s easy to use. A is a drop-in tool with lots of alternatives, B is unrestricted since Git is very flexible in this regard, and C is typically included with any cloud infrastructure, unless you’re doing on premise in which case there are also drop-in tools.

    A, B, C are three distinct, orthogonal topics that can and should be handled separately. There’s no logical reason to shape any of them after the other. They have to work together, sure, but the design considerations of one must not affect the others.


  • It depends a lot on the setup you have, how many people, release flow etc. Issue tracking depends on the kind of software you do and whether you want a programmer-only flow or a full support flow.

    Deploy pipelines will usually depend on the infrastructure, cloud solutions usually can integrate with several and there’s also common solutions and even FOSS ones, like Terraform vs OpenTofu.

    Git frontends are a very mixed bag, generally speaking their main purpose is to hide Git as much as possible and allow programmers to contribute changes upstream without knowing much beyond the nebulous “PR” concept. Basically they’re mostly useless other than enabling people to remain dumb. A good Git tutorial and a good history visualization tool (git happens to include one called gitk out of the box) will do so much more to teach people Git, and there’s really no substitute for communication – using annotations to discuss pros and cons for a PR is badly inadequate.


  • Again, like OP said, those are typically distinct functionality: issue tracking, source control, deployment etc. GitHub bringing everything into one platform is atypical and obviously done for the goal of centralization. The more stuff you add to a platform the harder it makes it to leave or replicate.

    But no, technically speaking you don’t need to have all of it in one place. There’s no reason for which you must manage everything together.

    I don’t even understand why people like GitHub so much, its source management sucks. The fact it still doesn’t have a decent history visualization to this day is mind-boggling.

    Look for ways to do things separately and you will find much better tools. GitHub’s “one size fits all” approach is terrible and only holds because people are too lazy to look for any alternative.