No, it does not have any more access than any other app, as it work on unrooted devices too.
That said, it has to be compiled for older Android SDK level because newer levels prevent apps to run executables they downloaded on their own and not bundle with the APK, even isolated. Android may disable compatibility with the older SDK some day but for now it works.
sorry, it was my understanding that Android apps have lower level access to the Android OS than iOS apps allow, that essentially iOS apps are sandboxed? And that this was what was allowing Termux to do everything it did in Android.
I could talk about things better in Linux whole day. But besides popularity (so being preinstalled, proprietary software availability, being presented from childhood) is there a single reason to use Windows? Backwards compatibility, accessibility? Maybe?
> they have no way to stop an attacker from loading up the broken firmware to exploit your device
You mean the attacker having a physical access to the device plugging in some USB or UART, or the hacker that downgraded the firmware so it can use the exploit in older version to downgrade the firmware to version with the exploit?
Sure. Or the supply chain attacker (who is perhaps a state-level actor if you want to think really spicy thoughts) selling you a device on Amazon you think is secure, that they messed with when it passed through their hands on its way to you.
The state level supply chain attacker can just replace the entire chip, or any other part of the product. No amount of technical wizardry can prevent this.
Modern devices try to prevent this by cryptographically entangling the firmware on the flash to the chip - e.x. encrypting it with a device-unique key from a PUF. So if you replace the chip, it won't be able to decrypt the firmware on flash or boot.
The evil of the type of attack here is that the firmware with an exploit would be properly signed, so the firmware update systems on the chip would install it (and encrypt it with the PUF-based key) unless you have anti-rollback.
Of course, with a skilled enough attacker, anything is possible.
> You mean the attacker having a physical access to the device plugging in some USB or UART
... which describes US border controls or police in general. Once "law enforcement" becomes part of one's threat model, a lot of trade-offs suddenly have the entire balance changed.
Example of evil maid attack. On laptops prevented automatically by secure boot or manually by encryption and checking fingerprints, not by bricking whole device.
Would switch to PostmarketOS tomorrow if there was any fully supported hardware (camera, 4G calling, etc.). All programs/apps I use are FOSS and standardized anyway.
> handling mobile devices' changing IP addresses as it hops from one subnet to another
We could create TCP/UDP alternative that would handle mobile IP addresses or even make traffic take multiple of those paths at once (look up MPTCP). But we cannot apply it in real scenarios mostly because of middleboxes (like CGNAT) messing up and limiting the messages that should be taken care of on the endpoint.
Right now, there is another battle between AT&T's CGNAT (entire customer base) and Yahoo's NEW login authentication mechanism.
Web browser visiting Yahoo Mail is poorly comparing your external IPv6 with your home's IPv4 and rejecting your login.
This problem gets worse for Linux users as more and more websites (DirecTV) start to use the NEWEST Yahoo login authentication until AT&T somehow starts disbursing IPv6 inside your LAN, ... or something.
So "NAT" security is technically being compromised by Yahoo's JavaScript.
I’m not sure what you mean by this. In other words, there is code that is specifically written for ipv6 handling which in some cases isn’t tested as thoroughly as ipv4. Less of an issue as ipv6 adoption grows but it’s non zero. I don’t like the address format, I prefer NAT by default, routing by prefix, like everything ipv6 offers I don’t feel comfortable with even without that. But it’s the most technical reason I don’t like it, the rest is a personal/vibes thing.
> And please stop with that 'computers security', we all know here it does not exist (NAT or not), it is a fantasy. Saying otherwise is engaging in bad faith.
So you are willing to message me your credentials then?
Also with IPv6 with NAT you definitely have this security, but with IPv4 without NAT you MIGHT have that security...
Disabling security features makes them disabled. Also security of NAT is a side effect because of that the devices behind it are not connected to the internet just tricks them into thinking they are.
That said, it has to be compiled for older Android SDK level because newer levels prevent apps to run executables they downloaded on their own and not bundle with the APK, even isolated. Android may disable compatibility with the older SDK some day but for now it works.
reply