You shouldn’t need sudo for a traceroute, so that’s something special on your system.
It’s kind of like ping, it uses raw sockets and does need special privileges, but some distros make those SUID binaries so normal users can use them anyway.
deleted by creator
They have no business collecting any data in the first place. If I wanted my data collected I’d be using Chrome like everyone else. I’m not choosing to use their buggy ass inferior and slower browser for any of Mozilla’s services, I’m choosing it because I want to support non-Chromium browsers and regain my privacy.
There’s no point whatsoever to using Firefox if it’s just a worse Chrome.
Nope. The protocol is way too public for shadowbanning.
You can be banned by other instances than your home instance, when that happens no new post/comment from you will federate to that instance in particular but the others still sees it as normal.
For example, I could ban you on my instance, and I wouldn’t see anything from you ever again, but my instance would be the only instance to see that ban.
If you get banned from LW or lemmy.ml then a lot of people won’t see you so that could definitely feel like a shadow ban, but there’s nothing shadow about it you can see it in the mod log.
It doesn’t have to be Mastodon or a social platform. It could just be a news/blog kinda deal that happens to support ActivityPub and people can subscribe to it to get it on their feeds.
Because phones are a mess of out of tree patches specific to that phone model with zero hope of being upstreamed into the Linux kernel without a cleaner rewrite because it’s not good, it’s made to work and nothing more. They do stuff like just copy pasting the drivers into the project for the next chip, make some changes, and now you have several versions of the same driver for a whole bunch of slighly different chips. The community can’t keep up with that or make it generic enough.
It’s improved but companies like Qualcomm also used to basically drop the code to the manufacturers when the chip launches and then move on with little maintenance for the code and stop maintaining the code once the chip is not produced anymore. Manufacturers don’t have the expertise to maintain that forever nor the will, so you end up with a kernel that keeps aging and isn’t keeping up with Android and the community hasn’t been successful in integrating it all either.
Google’s been pushing hard for this to improve but they’re the only ones to even care. Samsung and others would much rather sell you a new phone.
There’s also the problem that phones don’t really have a BIOS, the kernel is expected to just know where the devices are via the device tree. So each phone needs a specially built kernel for it too.
Projects like LineageOS often manage to push those phones a couple versions longer but eventually interest dies as well because of kernel pains.
Good luck with “exhaustive” because people have different unique reasons to come to the fediverse. It would be a very long list.
For the average user I’d approach it with points that affects everyone:
It’s harder to onboard and figure out by the common people but it would be the final platform switch. You may move instances over time but you will never be left looking for a new platform because the old one enshittified. You just move to an instance that hasn’t, done.
SSO has already been mentioned, but expanding on that for those that aren’t familiar:
When you have a big organization with lots of people that needs to access maybe dozens of sites to do their work, it quickly becomes a nightmare to manage. You’d have to invite the user on dozens of sites, you can’t easily control their access, it’s easy to forget about some accesses. You have to care about users using a good enough password, make sure to sign up with their work email, etc.
Enter SSO. The company maintains a central directory for their users, where they can enforce password policies, enforce the use of 2FA authentication, and can out users into groups which grants them access and permissions to external services. So they can make say, a “developers” group and it gives you access to a testing AWS environment, read only access to logs in DataDog, access to some settings in Cloudflare, etc. They put your user into that group and you automatically get access to all that.
Of course at that point, you don’t have a password for any of those sites. But you need a way to log in. So that’s why the login process is multistep: you first enter your email and submit that. From there, the site can determine if you belong to an SSO organization and redirect you to the SSO flow where you’ll authorize the log in and your company can also grant or deny the access to that site through your company email account. And then you’re in, no password required because supposedly you’re already logged in to your company email or logged in as a side effect of logging in to a company computer.
If you have a regular account, then the site can prompt you for your password, and optionally your 2FA code. They could just put all 3 fields on the same page, but at that point you don’t know if the user needs a password, or if they need an MFA code as well.
Plus, if you don’t have an account at all, it can then show you a registration page to enter the rest of your details, so you don’t even need a separate registration flow either.
Same, even with the custom API key. Guess we’re gonna have to spoof the user agent too.