PoorPocketsMcNewHold @ PoorPocketsMcNewHold @lemmy.ml

https://keyoxide.org/692723271195C9955EC6EB51F3A4127659095327

---

Read more

Posts

0

Comments

118

Joined

5 yr. ago

Thanks for the tip ! To be fair, I haven't even checked the result and missed on it.

It still create an attack vector, as it allows a potential extra method to get access to it, in addition of potential hardware exploits that i shared to gain root. Yes, you can minimize the risks correctly, but the user is the only real barrier against it, not the software anymore. The less potential way to exploit your phone, the better it is. You shouldn't rely on thinking that such feature is fully attack-proof.

Stop it [send] Mom [send] This is [send] your warning [send] ⚠️ [send] ... [send] Did you even read Mom ? [sent 53 photos]

Aggree with common sense, but more difficult to establish with some people.

The actual Magisk prompt that ask you if you want to give root to such app. This UI layer.

Although, i suppose it could be countered by explicitly refusing all requests or enabling a biometric confirmation

Just logical. If you gain the privilege to modify system bits, then it just open the potential for attacks abusing root access. And it has been done already. You are just removing one step for them. https://www.bleepingcomputer.com/news/security/loki-trojan-infects-android-libraries-and-system-process-to-get-root-privileges/ https://www.bleepingcomputer.com/news/security/highly-advanced-spydealer-malware-can-root-one-in-four-android-devices/ https://www.bleepingcomputer.com/news/security/new-abstractemu-malware-roots-android-devices-evades-detection/ https://promon.co/security-news/fjordphantom-android-malware/

Only big manufacturers can really pay to control entirely the hardware inside it, and allow you to modify it. Checkout Fairphone for example. They've been forced to stop hardware security updates due to their chip manufacturer, who refused to continue supporting it, despite them trying to support their devices for plenty more years. This explains the choice with Google.

Sadly, can't be re-locked. Would have loved to get a Motorola if it was.

That's the main issue really, as it open the possibility to manage your device for anyone getting hold of it. Probably some debug attack methods also with it.

Proove us that you can get better security while remaining able to be fully modified with other phones and brands. https://www.privacyguides.org/en/android/#divestos

https://www.reddit.com/r/GrapheneOS/comments/13264di/comment/ji54e19/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button

If you have the UI layer able to grant root access, it has root access itself and is not sandboxed. If the UI layer can grant it, an attacker gaining slight control over it has root access. An accessibility service trivially has root access. A keyboard can probably get root access, and so on. Instead of a tiny little portion of the OS having root access, a massive portion of it does.

In the verified boot threat model, an attacker controls persistent state. If you have persistent root access as a possibility then verified boot doesn't work since persistent state is entirely trusted.

A userdebug build of AOSP or GrapheneOS has a su binary and an adb root command providing root access via the Android Debug Bridge via physical access using USB. This does still significantly reduce security, particularly since ADB has a network mode that can be enabled. Most of the security model is still intact. This is not what people are referring to when they talk about rooting on Android, they are referring to granting root access to apps via the UI not using it via a shell.

Here's an actual FOSS cross-platform alternative with Windows, Mac and Linux (Need to be manually compiled and still experimental) https://screen-play.app https://gitlab.com/kelteseth/ScreenPlay

Try helping ScreenPlay support Linux, it's probably the closest alternative other than that kde-plasma reverse engineering port of Wallpaper Engine. You just need to compile it manually. https://screen-play.app/ https://gitlab.com/kelteseth/ScreenPlay

Beat the main purpose of GrapheneOS. Open the phone to a broad lot of security issues.

https://source.android.com/docs/core/display/material

It is... such an odd way to call it that way, in addition of the already present Material You, if true. https://source.android.com/docs/core/display/material

Doesn't answer OP question. OsmAnd doesn't use or support Material 3 / Material You design system.

Remind me of an another educational free game about WWII BBC 1943 Berlin Blitz

You can still decide to transfer your account later on, so starting on mastodon.social isn't too bad. https://guide.toot.as/guide/move-mastodon-server/#1-guide-configuration Even if i would suggest to change it, as it kind of beat the decentralization aspect to it, i believe ~80℅ users are just on this default instance. The official website has it's own list of suggested servers per interests and some rules here : https://joinmastodon.org/servers You can search via a minimum maximum character limit here : https://mastodon.help/instances/en

By default, Mastodon servers can access all other servers. It's just the admin who can decide to block other instances on a blacklist for all the users on the instance they use. You can also just block yourself instances or users if you want. As long you don't take a political, shitposting, or fascist one which are often blocked on a lot of instances.

Indeed. YACB : Yet Another Call Blocker and SAI : Should I Answer