Keyoxide: aspe:keyoxide.org:KI5WYVI3WGWSIGMOKOOOGF4JAE (think PGP key but modern and easier to use)

  • 0 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: June 18th, 2023

help-circle

  • Wayland and GPU stuff should be very good in endeavor, better than most systems I have seen, better than openSUSE leap and mint certainly. I don’t know fedora however.

    Endeavor has its own base repo, but also the regular arch stuff like aur. The AUR is probably the best source for all those programs that are usually missing in your repo, and since the base stuff is stable in endeavor there is no problem if some random program needs a special version or a manual install sometimes, it won’t affect anything else.
    The AUR is not the main package source for endeavor.
    I don’t know your hardware, but the combination of up to date system components, endeavors focus on just working, and all the shit in the aur (to my understanding flatpak is currently quite useless for drivers) sound like it should just accept any hardware at least as well as other linux distros.

    On a sidenote for flatpaks. There is this long running conflict between stability, portability, and security. The old-school package systems are designed to allow updating libraries systemwide, switching-in abi compatible replacements containing fixes. On the other hand, you have appimage, flatpak, …, which bring their own everything and will therefore keep running on old unsafe libraries sometimes for years before the developers of all those specific projects update their projects’ versions of all those libraries.






  • which also references an effort to use the media to quietly disseminate Google’s point of view about unionized tech workplaces.

    Bogas’ order references an effort by Google executives, including corporate counsel Christina Latta, to “find a ‘respected voice to publish an op-ed outlining what a unionized tech workplace would look like,” and urging employees of Facebook, Microsoft, Amazon, and Google not to unionize.

    in an internal message Google human resources director Kara Silverstein told Latta that she liked the idea, “but that it should be done so that there ‘would be no fingerprints and not Google specific.’”

    From the article posted by 100_kg_90_de_belin.

    Google seemingly does care about their internal image, so they will only make their actions obvious when they fire you for bogus reasons after wanting to join a union.
    Quite nasty in that they give you no hints about how extreme their efforts on this are. They monitor internal employee tools like they are cosplaying the NSA, but you wouldn’t know before you are fired out of the blue.



  • That isn’t really going out of your way, it is the base mode of how the fediverse works. Looking at something on a different instance.
    Plenty of people just use mbin and see this, without any action at all.
    The point is that as it stands right now, there are already basically no restrictions. The only thing perhaps missing is the knowledge that you can simply copy paste a link into fedia or another mbin instance to view upvotes.

    You can open an issue on mbin about it, to restore a semblance of restriction. But currently as it stands, all restrictions are about as fallen as they could be.

    You can ofc argue that we shouldn’t open another equivalent hole in lemmys webui and api, so that you can in the future remove the ability from mbin.

    I would in turn argue that this system has always been egregious, and that in the same sense as banning encryption you never hit those you want to hit using incomplete restrictions. Regular users are led to believe their votes are private, while the worst dataminers or trolls will always have their instances to query all of that info.
    And how could you inform people that their votes are public without at the same time telling them how to get access to that info?

    If mbin removes the info, you will get another fediverse software showing it. You will get fediverse activity pub log info pages, specific vote info pages, it will never end.
    Has reddit ever managed to kill the 200ᵗʰ removeddit clone?

    Please instead put your effort into changing the way lemmy federates, the only way to fix this is to make vote details private, between only a select few instances. An mbin dev in the other thread mentioned PeerTube as an example implementation where you could remove vote details like that.


  • This would solve some of the problems. If only 2 instances know about the votes, post instance and sublemmy instance, you can reasonably expect to get most instances to never release that info. It would allow either the sublemmy or post instance to manipulate around in the votes, but most manipulation would be detectable by the respective other instance.

    It would open the door however to manipulating around with internal posts made from the instance in a sublemmy on the instance. And it would allow the post instance to drop votes selectively, though I think that is possible currently all the same.

    Votes being sent to both the sublemmy and the post instance simultaneously would make manipulation a lot harder. And for cases like internal posts, you could add another involved “judge instance” that receives the vote details directly from source, and is merely there to confirm the total. Instances that hand out non-independent “judge instances” could be labeled as untrustworthy in the lemmy community.

    So you end up with a list of instances per post that votes are reported to, to which you add the post instance, sublemmy instance, judge instance, and maybe some more.

    In terms of implementation, I think the activitypub protocol needs an origin for votes, right? I would say an instance can just report the votes coming from a stock of obviously fake accounts, like “masked_upvote_1” to _999999 … and “masked_downvote_1” to _XYZ.
    About the votes, I am not sure. It could be done as a lemmy-internal feature where lemmy instances and other instances knowing of the lemmy protocol send the info to all the relevant instances, while any votes from external instances only arrive at I guess the post instance and that then forwards it on to all other instances. This way the checking doesn’t work for software unaware of that lemmy specific vote implementation, but everything is still compatible.

    You could then even for those lemmy-external votes add an interface on the judge instance, that would confirm via pm if your vote has arrived.

    Do you think this could work?


  • In my case I would like them to be private, but currently they are not. I don’t think it is good to try to hinder the visibility into a fundamentally transparent system.

    I don’t see a technical way to make votes private either, that doesn’t prevent bad actor instances abusing the vote system. As an admin of an instance I could just add 5-10 votes to all of my interactions whenever I feel like it, and noone would be able to tell it didn’t come from legitimate users on my instance. The accounts of vote origin are needed as proof, hence moderators on lemmy having access to them.

    Do you perhaps have any idea how this could be accomplished?