Banking, usable gps navigation with live traffic, workout tracker that can read and log gps and data from my Polar H10 and smartwatch.

For me, it’s something to use a Mi Band and banking apps. The rest would probably be doable on GNU phone as well.

(I only said “GNU”, since both operating systems already use the Linux kernel.)

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: https://community.e.foundation/t/qualcomm-chipsets-data-collection-linked-to-the-a-gps-service-in-e-os/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:

1. 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.
2. 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.
3. Figure out how /e/OS users can use Advanced Privacy IP scrambling features to fake SUPL calls origin IP address.
4. …?

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.

And here’s the Wikipedia article on what is it that the Qualcomm chip is trying to gather: https://en.wikipedia.org/wiki/Assisted_GNSS

Just a heads up - Been following UT for some time and the major for me is that there is currently no VolTe support. Major bummer for US folks. There’s workarounds, at least for pixel3a but its not 100% reliable.

Also SMS / MMS can be troublesome as well. Can’t download images while on WiFi??? Group MMS doesn’t work.

Great system, works well but I can’t make it my daily driver

deleted by creator

“Just”

I think unless the HAP bit is specifically set to 1, Intel ME is still active on consumer boards, just without an interface for the OS to interact with it. Not sure if someone has hacked an OEM UEFI/BIOS to interact with it, but I have seen a different MAC address from my PC on my network before, and this is without any virtual adapters. This is the only explanation I can come up with.

For what it’s worth, I did specifically say ecosystem because the TPM is just one component, which is required to authenticate the remote wipe. Also the drivers are installed automatically with most modern operating systems, it’s not like you install your own south bridge driver, for example. Linux of course notwithstanding.

I’ve seen it used successfully numerous times. Someone steals one of our laptops, rips the drive out, installs vanilla windows, and boom it reboots and performs a wipe.

Regardless, system-on-a-chip are just that, systems; they can absolutely make remote calls without user interaction, just as intimated by the comment you originally replied to.

Why so much hate towards GrapheneOS? The thing is carefully planned and executed. About Calyx… just don’t forget that you won’t get a secure boot… anyone who gets you phone can temper with your boot.

I don’t really remember strcat “lying”, yet there are some evidence of him being… Let’s say unstable. GrapheneOS, tho, is another story as it’s trying to improve the android’s privacy/security model instead of simply not making things worse. For example, they are behind hardened malloc - for security, and have storage & contact scopes (i.e. letting the user choose which files/directories exactly an app can access) - for privacy. While the former feature has been adopted by a few other roms and even desktop Linux distributions, the latter I’ve seen only on graphene so far, which is quite a shame. Same goes for sandboxing play services

I bought the ancestor of GrapheneOS (CopperheadOS) for 500 bucks. I paid for two reasons:

1. I wanted support
2. I wanted the OS to be installed by the people behind the project, so that I could be certain it wasn’t tempered with, and didn’t have to rely on PKI, or PGP from random people. After all, it was meant to be secure. To that end, I even used a trusted courier.

Now AFAICT, the team back then was composed of two people: James Donaldson and Daniel Micay. James was the CEO and running operations, while Daniel was the CTO, and focusing on hardening.

Taking care of operations, James was the one who installed the software on my phone (I got confirmation of that fact from James himself). When I received it, it worked perfectly. It was great. I got to enjoy a nice, allegedly very secure OS for a few months.

Then, suddenly, after an OTA update, the microphone stopped working. The fact that it happened immediately after an update prompted me to believe that the OS update broke something.

I reported this to David Micay himself. To my surprise, he didn’t seem concerned at all, and refused outright to even take a look at the code changes in that update, without either having my phone or several MB of logs from the phone. In fact, he strongly implied it must have been user error (i.e. my fault), or hardware failure (i.e. Google’s fault).
The possibility of he himself having introduced a bug, or of his stack having produced a partially failed build, seemed absolutely inconceivable to him.

It was necessarily someone else’s fault.

Neither option was acceptable to me. I wasn’t about to pay for another courier, especially to send a product to be processed without any guarantees, to someone who obviously didn’t give the tiniest fuck; and I surely wasn’t going to send several megabytes of personal, confidential information, to someone who just flat out insulted me, and arrogantly implied that the Google hardware would likely fail sooner than his software (fun fact, that “Google hardware sucks” phone still perfectly works today).

So, instead, I immediately bought another phone, installed lineage on it, and that other phone still works perfectly to this day (microphone included!). Albeit with a pretty weak battery.

Unsurprisingly, some months later, David was canned from the CopperheadOS project. However, to my horror, he destroyed the signing keys in the process. So there was then no way anymore of eventually getting a fix for his bug (I was hoping that, at some point, knowingly or not, he would somehow introduce a change that would fix the bug. After all, this is how the bug first occurred, so it wasn’t unreasonable to hope it could also be how it would be fixed, given that no other fix would happen).

Therefore, the very expensive license was useless to me. I really wish James would have re-signed the software during deployment, and made updates available signed with that same key, therefore preventing David from destroying the entire value of all sales.

Indeed, said keys could only be trusted if the install had been done by CopperheadOS Ltd (and if the device was kept by a trusted supervisor at all times after). In any other case, there could have been tampering, since the bootloader had to remain unlocked.
And leaving the keys with the Ltd was the semantically correct thing to do, for all intents and purposes:

• If James was so untrusted that the keys would have to be destroyed upon David leaving, he would have been untrusted before too, so letting James run all operations would have been a grave security oversight.
• If James wasn’t untrusted, keys could have been transferred securely, or replaced via an update.

So, pretending to have destroyed the keys “To EnShUeH sEcUrItEh!!!1” was quite clearly a fallacious reason.
What evidently happened is that David was butthurt, sought revenge, and didn’t give the slightest fuck about the damage to other people.

I kept my CopperheadOS phone as a reminder never to trust this dev again. Never to trust anything he has control over. Never to trust any company he works for.

And I salute your indubitably pertinent judgment. I wish I had had the same wisdom, I would have saved a bunch of money in not buying the most expensive paperweight I have ever bought.