Quality shitpost

I didn’t say they didn’t. But if a site is blocking you, that’s the site admins configuring that, not Cloudflare.

Do you have “Allow Loginfallback” enabled in the YouTube plugin?

I’m able to use it at the moment, could be either my fallback settings or they’re doing a staged rollout of what breaks things.

I’m not sure why you’re trying to bring that up when this comment of yours is what I’ve been responding to the entire time:

Nope. Cloudflare use a complex set of fingerprinting tools that determine security scores. It’s literally social credit system for web user agents and the site admits have little control over that.

Cloudflare does force nor opt in site admins to use the score. You said that site admins have little control over that. That is not true, because site admins do not have to use the score when configuring WAF. If they do not configure blocking based on score, they do not block the scored traffic at any point, no matter the score.

Your comment before this one said:

You control the score but not how its calculated. My score is incredibly high just because I’m on Linux with Firefox - how important is that to you as an e-commerse site admin?

So I said that the score doesn’t matter if you don’t block based on score. Since my client with an e-commerce site isn’t configuring any WAF rules based on the determined score, then it isn’t important to me (as a site admin plus their Cloudflare administrator), because it’s not a factor at all.

Now, if you were to enable the rule to block based on score then it could certainly affect users, because it was configured to do so. It comes down to proper configuration of the tools provided. If I were going to use the WAF rule based on score (again, I don’t do this, because I use other rules to check for malicious traffic), I would configure it with a managed/interactive challenge and not block them entirely. Cloudflare provides you with a percent metric based on how often this challenge is passed.

I said that in my original comment:

just not over the calculation itself

If you don’t use the score, it’s not a factor. I don’t use the score at all for my clients. You are not required to use it.

It’s literally not limited. If you don’t put a WAF rule based on the score then it doesn’t get blocked based on the score. It’s that easy. I’ve got clients and my own site on Cloudflare, so I know how it works. You don’t even need the pro subscription to do that.

While true that there are security scores, the site admins set which score (if any) to block at. So, they do have control over that. Same goes for the bot fight mode as well. So, site admins do have control over whether or not to block based on the associated score, just not over the calculation itself unless configured otherwise.

I’m using a VPN with my cloudflare reverse proxies right now. That blocking is configured by the website owners, not Cloudflare.

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.

Android is not designed the same way as a desktop operating system. For example, Android is designed to sandbox all applications and never require kernel level access. This means that if one app is malicious, as long as you haven’t granted it extra permissions, it’s much more difficult for it to affect any other apps. If you root, you’re breaking that level of defense. Android simply wasn’t designed for users to need or regularly use root, whereas Linux was built from the ground up with that expectation.

Root also makes applying security patches a challenge. Android doesn’t have a standard package manager like desktop Linux. This means that users with rooted phones are less inclined to go through the pain of updating. I haven’t rooted in a long while, but I can confirm that when I did root, I tended to avoid it for far too long. Anyway, the way Android’s incremental OTA updates work is by comparing partition hashes. When rooted, this hash gets changed and you can no longer install OTA updates.

Further, root on Android can (and as far as I recall, does) affect verified boot, meaning if you want verified boot, every time you reboot you lose root. Android verified boot detects changes to system partition and either doesn’t boot or reverts the changes. If you turn off verified boot, you cannot know if your system has been modified in a malicious way.

Put a slightly different way, Android’s security model is entirely different than the security model of something like Linux. Linux expects you to need sudo/root for certain tasks, and other protections are built around that. Android does not expect you to ever need root, so it’s not a consideration in its security design.

By rooting, you’re not just bypassing manufacturer restrictions, you’re bypassing Android’s security design entirely. It’s much more secure to just install a debloated, degoogled OS that can do verified boot.

Now, if mobile Linux ever takes off, then I’m sure it would be more like a desktop distro and less like Android.

I’m sure it’s already started, with Bitcoin addresses to pay.

Holy shit, what a trashy website. The AI eagle is a nice touch.

Also, of course they had to list that it can be revoked. Is someone gunna pay their $1 or $5 mil and then immediately upon entry get sent to the ICE camp?

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.