Notices by Mika (irfan@sakurajima.social), page 2

@liztai@hachyderm.io hmmm kinda curious thought what it'd taste like, as a fan of Tempoyak dishes lol

@liztai@hachyderm.io do u have a link? Been wanting one for so long each time I see a really nice one on YT but they're all American/Canadian n not avai here. Got one on Shopee that seems okay, just haven't pulled the trigger yet.

@liztai@hachyderm.io my sis said the same but shes a scaredy cat so i didnt take her seriously haha i shd give it a watch

@BeAware@social.beaware.live yes I totally agree. The priority for me is still for instance-level blocks and mutes + user-level blocks and mutes to work reliably. This suggestion would be premature to look into or worked on if said priority hasn't even "matured" just yet.

@BeAware@social.beaware.live if users being able to override an instance block/mute for their account alone will disrupt these enforcements/moderation for everyone else on the instance (so not really for their accounts alone), which I guess is possible, then it's certainly not what I would want.

The "best" scenario I'm looking for is that for instance maintainers to still enforce blocks/mutes for all of their members, but with the only difference being users could perhaps granularly add exceptions to what is blocked/muted for them (not others). So for example if their instance blocks/mutes federation with Threads/Meta, but they alone would want to still federate with Threads/Meta.

As of right now, users could only add to the block/mute list for themselves, not override or add exceptions to what's enforced by their instance.

Moderation in #Fediverse currently works this way (as far as I can tell):

- Instances could enforce their instance block and mute list. This gets passed down to all members of their instance.

- Users could have their own block and mute list of users or instances. This only applies for them, on top of the home instance's list.

This works great for the most part, but previously there have been plenty of discussions/arguments of instance members perhaps not agreeing to certain blocks/mutes enforced by instance maintainers - in cases such as this, since individual members have no power to "override" these rules for their account (i.e. to federate with users of another instance that's been blocked by their instance maintainer), their only choice as the last resort is for them to move to another instance.

I imagine it'd be great if it works this way instead:

- Instances could enforce their instance block and mute list. This gets passed down to all members of their instance by default.

- Users could have their own block and mute list of users or instances. This only applies for them, on top of the home instance's list.

- However users could also override the home instance's list granularly, if they would want to for example, federate with an instance that's been blocked by their home instance.

As someone who's not really delved into the workings of the Fediverse/#ActivityPub or any of the projects using it all too much, this "feature" suggestion might totally be technically nonsensical or maybe expensive though for it to make sense or be possible to achieve. Just thought this might be an improvement for what I think is already an excellent moderation system that we have here.

#Google Is Killing #RetroDodo & Other Independent SitesThis article really makes me highly consider changing my search engine of choice, once again. I've tried to do so in the past, but only for a short time cos frankly, other search engines are shit compared to Google. Now though I feel is the perfect time to revisit this quest, since I can't imagine how shitty a search engine can be at this moment to be as bad as Google.

If I'm to switch though, I'd very much prefer it to be #FOSS, though I doubt I've heard of one noteworthy. Any recs?

🔗 https://retrododo.com/google-is-killing-retro-dodo

There's a huge backdoor (#CVE -2024-3094) allowing remote SSH access (as far as I can tell at this moment) caused by a util called #xz affecting a ton of systems (#Linux and #macOS, well not really) and it's causing quite a huge panic. I honestly don't know much about it just yet, but just sharing some pieces to read about the huge vulnerability.

The person who had maliciously planted this vulnerability into xz-utils, Jia Tan, has made at least 750 contributions to the project over the past 2 years. They even have direct push access to the code repo, allowing them to have pushed commits with forged authors. Being "free" from this vulnerability is not as simple as reverting to a previous version due to just how much and how long they've contributed to the project, and people are rightfully suspicious that this Jia Tan person might have hidden other backdoors in xz.

Unlike most other vulnerabilities, it's a lot harder to pinpoint versions affected by this but the most likely case is most systems out there, including Macs, have xz installed on their system that are impacted - which at this moment, the info being thrown around is any version past 5.3.1 (latest is 5.6.1).

🔗 https://access.redhat.com/security/cve/CVE-2024-3094

🔗 https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094

🔗 https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

🔗 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024