Regarding the system partion and verified boot, it’s the fact that it isn’t the only thing one would do with root that breaks verified boot. You totally could package su in the ROM and ship it, but if a user installs something else to the system with it, it is very likely that the verified boot hash would change, unless I’m missing something.

OTA, as of right now, needs to hash the device to prevent system corruption. I don’t think it’s a very simple problem to solve, or surely there would be a ROM out there that does fix it with root. A better fix would be a package manager, but that’s not going to happen with AOSP.

Regarding #1, it’s fundamental to AOSP, and not any particular ROM. Similar to the OTA issue above. It’s not just graphene (which, technically, you can root fyi, but I really would not do so, as again it defeats the purpose of running a verified boot secured phone).

#2 is debatable, because it’s also highly dependent on the distro and configuration. As an example, immutable distros (which are actually closer to Android than non-immutable distros) make it so sudo/root isn’t needed very often, if at all. Fedora CoreOS, for example, can run package updates on a schedule without user intervention, use rootless containers, and do verified boot. It can be deployed from a single file and validate itself after the fact, meaning a user would never be prompted for a password at any point. Obviously that’s not a 1:1 because it isn’t made for PC usage, but other distros based on Fedora Silverblue and the like can be more secure than standard Linux for similar reasons. Everything is generally sandboxed (flatpaks and containers) and root is rarely, if ever, required.

That being said, if you’re not concerned, there isn’t anything stopping you aside from your phone’s manufacturer, which I’m sure you’re aware of. I’m fine just knowing that I could do it, and much prefer the security benefits of verified boot and proper sandboxing above all else. I don’t trust Google to properly patch zero days related to rooted phones, let alone patch the ones that affected non rooted devices.

Android does not have the same security model as desktop Linux. I made a comment about this above (which you probably can’t see due to .world being defederated with who I replied to), but if you don’t want to go to my comment history, it’s summed up as three or so main issues.

Rooting breaks OTA updates since it modifies your partition hash, meaning rooted users tend to leave security holes open way too long. Android does not have a package manager for you to be able to update these issues individually.

Android does not expect users to have root access, so they do not even consider it in the design. Android sandboxes apps, and apps can only generally have permissions that you grant, with no direct access to the kernel. However, rooting adds an entirely new attack surface for which there are no protections whatsoever. Desktop Linux, on the other hand, does expect users to need root level access from time to time. That’s what sudo is for, but you should not confuse this with switching your user entirely to root and doing everything as root. There’s a reason that’s not recommended on Linux: it’s dangerous. The same thing applies to Android. On top of that, Linux has other tools and protections designed to make running as sudoer safer, and Android has none.

Finally, it breaks your ability to use proper verified boot. If your system partions silently get malware installed, there’s generally no way for a user with a rooted phone to notice. Verified boot protects against this, but because rooting (along with whatever else you’re running as root) changes your partition hashes, it will either stop booting or revert your changes.

If mobile Linux ever takes off, it will likely be very similar to desktop Linux and be designed with root in mind.

Pixels are (currently) the only phones that allow for all of the following at once:

• Proper verified boot
• Bootloader unlocking (this is most important for any custom ROM installation, regardless of ROM)
• Hardware memory tagging
• Full hardware isolation
• Hardware key attestation
• Ability to disable USB data (and also USB entirely) at the hardware level
• Everything else on this list

In short, it’s simply because Pixel currently has the most hardware level security features of any Android phone (on top of bootloader unlocking), for now. The Graphene team is allegedly in talks with an OEM to produce a phone specifically designed for it, which may be just as or even more secure. Time will tell.

I feel the need to mention that I’m not trying to shill for Graphene and especially not Google. Depending on your threat model and goal, Lineage or similar might be just fine for you. I just don’t think there’s anything more secure than GOS at the moment, and if that is important to you, along with minimizing bloat, it’s a great choice. I do highly recommend avoiding root and instead just get something that you can unlock the bootloader for, and then install a degoogled ROM. Just make sure you don’t accidentally buy a permanently locked phone, make sure it says unlocked somewhere in the listing.

I posted this elsewhere, but CAPTCHAs have always been used to train models, and have always had to improve themselves even before LLMs blew up. This article was posted from a site with an .ai tld, and seems to be doing the whole Sam Altman “I’m scared of AI, AGI is right around the corner! I certainly don’t have a vested interest in making you think it does more than it actually does”

So, if I click the block button (which, trust me, I plan on doing regardless of your answer), you think that it somehow prevents others from seeing you be this dumb?

If someone walks away from you in person after you tell them the dumbest thing they’ve heard all day, does that somehow mean they’re censoring you?

Please post your browsing history so I can see it. Unless you’re trying to hide stuff?

Do you need root? It’s a big security risk, for multiple reasons.

You can always just get a used pixel (no further money to Google), and install a custom ROM that allows your bootloader to relock after installation. I personally prefer Graphene for this, but I believe Lineage also allows you to do so. They both have no bloat from the start, and GOS has sandboxed Google Play and Lineage has the ability to use microG iirc.

GOS can be installed via chromium based browsers, even from another phone. Security wise, there’s nothing more secure at the moment.

It definitely didn’t help that I bought a Pro B50 which shipped yesterday. My bad, everyone.

You can use Graphene’s web installer in a chromium based browser, even from another Android phone if you have one. So they don’t necessarily require a full blown PC. You can even do it from your steamdeck, if you were so inclined.

Larry Tesler, inventor of the cut, copy, and paste commands, dies at 74

I’ve always referred to them as Jesus Jumpers

Kirk probably wouldn’t be dead right now if Trump wasn’t elected, I fully believe that in some way or another

Huh? Did you even read the whole thread? They’re linked above.

They could put a banner in the network settings warning users about these security issues while they get them fixed, that doesn’t require fixing any inherited code. In the GitHub issue linked, there’s at least one upset user because they had no idea this was even a problem.

What about the pwned users of Jellyfin that have unknowingly had security holes for 5 years because Jellyfin doesn’t care enough to even put a banner in their settings to say it’s not secure?

I mean, that’s fine, but it’s still an issue and a risk that would cause me to want to use VPN for remote viewing. It doesn’t seem like security is Jellyfin’s priority at the moment, not that it’s Plex’s either, but it’s not to a place where it’s worth it to switch from a security standpoint, personally.

I’d love to switch. I would do it right now, but the problem is that Jellyfin’s security isn’t better if you open it up to the internet. For example, I’d have to set up a VPN for my remote users for proper security, and most of my users are in other states, not technically inclined, and watch on their TVs. I’d have to at least support a raspberry pi for them, or some sort of site to site VPN, and if it goes down, I’ll be expected to fix it. On top of that, if I do a simple raspberry pi based VPN, it would be made even more complicated since they’d want it to work with their smart TVs.

Again, I really want to switch. But Jellyfin needs to fix their security issues before I can. I’m also happy with the way Plex is reporting this, it’s above the standard “your data is lost” notifications.

Edit: here’s a link to the related GitHub issue I’ve been following: https://github.com/jellyfin/jellyfin/issues/5415

And @[email protected] has a great thread explaining more: https://lemmy.today/comment/18923504

Ah, I stand corrected. That’s probably why I’ve never been charged, 2.5k is a lot for my use.

Which part? If you’re wanting to use cloudflare pages, it’s relatively straightforward. You can follow this and get up & running pretty quickly: https://www.hongkiat.com/blog/host-static-website-cloudflare-pages/

If you’re asking about the tarpits, there’s two ways (generally) to accomplish that. Even if you don’t use cloudflare pages to host your site directly (if you use nginx on your server, for example), you can still enable AI tarpits for your entire domain, so long as you use cloudflare for your DNS provider. If you use pages, the setup is mostly the same: https://blog.cloudflare.com/ai-labyrinth/#how-to-use-ai-labyrinth-to-stop-ai-crawlers

If you want to do it all locally, you could instead setup iocaine or nepenthes which are both self hosted and can integrate with various webserver software. Obviously, cloudflare’s tarpits are stupid simple to setup compared to these, but these give you greater control of exactly how you’re poisoning the well and trapping crawlers.