I am dismayed at the current scenario of basically nothing but the pixels being supported for rooting (not the fault of the community). Also a bit saddened by how easily everyone has accepted it.
If I don’t go the pixel route, I will probably purchase a cheap OnePlus mobile next year with at least kernel version 5.10. By next year, KernelSU should be more mature, and if you know about KernelSU, you know that passing SafetyNet is not a problem. I’d run microG in the work profile and put my apps there, and also debloat the pathetic excuse of ColourOS (or whatever Oppo uses). Fuckwads couldn’t even keep the damn tool open to unbrick devices (which is why development stopped). By next year I just need to figure out how to install patches with a modded kernel.
Sorry that doesn’t answer your question since you need a mobile now. I’m just quite annoyed at the state we are in. I really hope linux mobiles take off in the near future and I don’t have to deal with such nonsense.
Ah, I didn’t manage to recollect your mention of NextDNS in your post. There’s no need to change anything regarding your DNS settings in such a case; it won’t take much of your battery.
Here’s a related discussion on the /e/OS forum: community.e.foundation/t/…/48982. Note that the domain mentioned in the discussion is izatcloud.net, however, for your purposes you can consider it the same as the domains you’re seeing.
What can /e/OS do?
The SUPL-A/GPS case is well-know for a long time. Though it’s probably a low impact case in term of user’s privacy, we are evaluating how to prevent or mitigate it in /e/OS.
Options we have today:
Block SUPL requests using /e/OS’ Advanced Privacy tracker control. But that would probably kill the A/GPS service, making the GPS location service very, very slow.
Proxy SUPL requests to anonymize their originr. That’s an option but it can be blocked if we send too much traffic to the SUPL servers. This would likely happen because /e/OS has a lot of users, and would have an impact in term of service continuity.
Figure out how /e/OS users can use Advanced Privacy IP scrambling features to fake SUPL calls origin IP address.
…?
You might want to try option 1 and check. Please revert back to this comment after attempting to do so, so that others can benefit from this idea.
XTRA uploads the following data types: a randomly generated unique ID, the chipset name and serial number, XTRA software version, the mobile country code and network code (allowing identification of country and wireless operator), the type of operating system and version, device make and model, the time since the last boot of the application processor and modem, and a list of our software on the device
They just forgot to mention that this data is sent with no encryption (except in the xtra3grc.bin format, hope that they’re exclusively using that now…). Of course it should be blocked. But it’s necessary to allow one of those 3 domains in order to make the GPS work properly.
On 4th and 5th generation Pixels (which use a Qualcomm baseband providing cellular, Wi-Fi, Bluetooth and GNSS in separate sandboxes), almanacs are downloaded from https://qualcomm.psds.grapheneos.org/xtra3Mgrbeji.bin which is a cache of Qualcomm’s data. Alternatively, the standard servers can be enabled in the Settings app which will use https://path1.xtracloud.net/xtra3Mgrbeji.bin, https://path2.xtracloud.net/xtra3Mgrbeji.bin and https://path3.xtracloud.net/xtra3Mgrbeji.bin. GrapheneOS improves the privacy of Qualcomm PSDS (XTRA) by removing the User-Agent header normally containing an SoC serial number (unique hardware identifier), random ID and information on the phone including manufacturer, brand and model. We also always fetch the most complete XTRA database variant (xtra3Mgrbeji.bin) instead of model/carrier/region dependent variants to avoid leaking a small amount of information based on the database variant.
Note sure if e/OS/ has taken as much care as Graphene has to make the requests more private. Then again, they don’t claim to be the most private OS, just De-Googled.
Since we’re talking specifically about network traffic, let’s clarify the scope of the problem for reference.
You want to see what is being sent outside, to the wide internet from your network, and how might you be compromised by this traffic.
The logical method would be to snoop on this information. The question is, how would you do that?
There are network analysis tools, including DPI, that might be able to help you in this journey. Suricata/Snort and Splunk are three such applications, although perhaps you’d also like to consider an application suite like Security Onion.
The second problem is, how do you get the outward facing traffic to analyse it? The easier way to do this is to utilise port-mirroring - mirror the traffic through your WAN-facing port into an analyser to check just what is it that you’re sending out. Note that this will likely require extensive effort and time since everyone has different traffic they would like to check, and coming up with robust checks is entering the field of security professionals.
As you know, most x86 computers have a backdoor installed in hardware. This is either the Intel ME or AMD PSP (if you know what this is and are worried about your privacy, I suggest looking at AMD’s OpenSIL initiative slated to release in 2027).
This is a problem since these backdoors utilise the same hardware NIC of your computer but act as a completely different system (different MAC, encrypted traffic using different keys, and a different style of traffic).
The problem manifests like so: one would reasonably expect to find the traffic from said processes in the traffic that one analyses, however, how would one find them (perhaps through logging their MAC address)? It is possible that Intel already uses dynamic MAC addresses, which makes it harder to find them - although, in theory, one should be able to script this.
Now that you’re enraged about such atrocious behaviour on your network, let me point you towards the fact that people who run mini PCs as routers with x86 processors in them (for OPNSense/PFSense) should also be running into this problem, theoretically. It is a bigger issue for them however, since in their case the network edge itself is reasonably compromised. How are you sure that the ME/PSP processor isn’t going to mask its traffic from the port-mirroring setup you have got running? How can one be sure of the capabilities of such proprietary systems and how they can mask their traffic?
I know people will come up with “but they don’t spy on you! It needs to be explicitly turned on to spy on you!” and “get a thinkpad bro, modify the HAP bit!”, however, both arguments don’t hold much weight considering the hardware readily available to the common user (bit of a fallacy, but we’ll go with it). The point stands; such behaviour shall not be tolerated in a self-aware user’s network, and needs to eradicated the second the user gets a whiff of such mischief playing out. I hope my note has ignited a willingness in you to prevent such rabid deanonymisation attempts to one’s self in this age, and will spur you to fortify your network to prevent such malice from breaking anonymity and trust on hardware.
We don’t know if they do, but they certainly can. Especially if you are on x86. I’m sure Android (which comes from OEMs) and iOS devices spy on you.
No, you have no respite unless you switch to custom. The good part is that this process is much easier than before (especially on the desktop), and will keep getting easier. Graphene already has their Web installer when you plug your mobile into your computer and let it do its job. Installing Linux is the easiest it has ever been, and I would argue that this trend has creeped into even the more advanced distributions like Gentoo/Funtoo (their guide is extremely well written and easy to follow + forums).
The only thing you are losing is time. If you don’t have the time, then no, you should stick with the easier ROMs/Distributions. I would never espouse using Windows/MacOS/OEM Android/iOS unless forced to by circumstance.
They’re IEMs, and earphones are a colloquialism. Nobody is stuck up if they call it an IEM, if someone doesn’t know we extrapolate for them. I don’t see the problem.
I am an IEM enjoyer (used to own Softears but don’t need them anymore), and I use Debian.
Apologies for not answering earlier. I have since switched over to podman generate kube and podman play kube for managing my podman infrastructure. This plays in well with my plans since I can’t be dependent on systemd going forward. Thank you for your help.
With that said, I wanted to ask another question: when I try to run a container with podman run debian, it automatically pulls the debian container without a problem, however how is it that when I type podman pull docker.io/debian/debian it requires auth?