FP3 custom rom development based on released source code

[JeroenH]

True, but they lean heavily towards GApps. The microG variant of LOS is not hosted on LineageOS.org; it isn’t an official variant.

/e/ has a vibrant community, and it is the only Android (or well, AOSP) distribution I’m aware of which includes microG. The enthusiasm for /e/ in the Fairphone community (due to FP2 port) was high.

A poll is a way to have every user’s voice count, no matter how good their argument is constructed. Question is, what should be included in such a poll? It is a bit unfair to add entries afterwards.

[pigpig]

First of all, we need to know if we focus on gsi or “full” custom ROM. Then we’ll need to do a repo for the patched updates (and maybe a little apk) or try to port a custom ROM

[JeroenH]

Right. What are, objectively, the pros and cons of each? I suppose the cons of GSI is that it does includes GApps? (But then the one you currently use does not?)

Honestly, I’m not sure how I can make an informed decision on such a poll.

[smurf]

IMHO if we can use GSI then we should.
There’s no point in re-inventing the wheel for each phone variant, which is IIUC why GSI exists in the first place.

[pigpig]

GSI :

Pros:

• Easy to do, actually already available (we don’t have to re-invent the wheel as @smurf said) ;
• Lot of ROM available ;
• Treble, and GSIs have been created for that purpose (and updates frequencies).

Cons:

• Any update (if there is any) on the vendor part of the system will be hard to manage ;
• All the gsi, or at least most a them, Some wanted gsi ROM (LOS, /e/,…) are unofficial support. They are in dev (debug) mode. Maybe we can fix this ;
• Need a rooted device. For the moment ;
• As mentioned by @corvuscorax, the qualcomm lib are still used, which is possibly a privacy issue.

Full Custom ROM :

Pros:

• We control all the system partition ;
• (For some ROM) Once done, it will be possible to make it an official support ;
• (If it is possible) use free alternative to proprietary bin.

Cons:

• We have to maintain it (shouldn’t be a huge problem, some users already maintain LOS on other phones) ;
• Need to work hard on it.

Tell me if I forgot anything.

Someone know if LOS and /e/ are planning to support officially gsi (like Bliss, Resurrection, etc.)?

[corvuscorax]

If we look at it from a privacy perspective ( Telemetry, Spyware, list of privacy threats on FP3 Android 9 )
I think the main reason people would want a custom ROM without gaps probably is privacy - otherwise simply rooting the device would be enough.

However gaps are unfortunately not the only spyware on the phone. At least with the google spying you sort of know where it goes, and google at least gives you some control over the data they collected through the google account. Also it’s kinda “under control” as disabling the google-play-services - or denying network access to google play services - as well as a hand full of other nosy apps ( keyboard, location services, ‘find my device’, …) - actually turns that off. (A VPN based firewall can do that, don’t even need root)

But unfortunately, like probably 90% of devices now, FP3 is a Qualcomm phone, and the qualcom stuff is rooted much deeper in the system - mostly on the vendor partition. There is spyware on the phone that are not apps but a system service running - some of it even with root privileges.

And as a privacy aware user I would like to get rid of that crap. But a GSI solution that keeps FP3’s vendor partition untouched won’t allow that. It would replace google’s frontend with LOS and remove the gapps, but the “rootkit” installed by qualcomm is still armed (worst case scenario)

This isn’t trivial, since qualcomm’s “security features” are deeply interlinked with DRM featurs the phone has. using stuff like the QSEECOM lib and the matching kernel driver, etc… - all provided by proprietary libraries. This is a cesspool that gets deeper and deeper when you go in the direction of cell-modem and firmware.

And I really don’t know what to do there. It’s possible that some of the spy-features are part of proprietary libraries the phone won’t even work without, since they control critical hardware features.

As such I don’t really know what to say with the poll. A LineagePort using GSI would certainly neat and quick but since it leaves the qualcomm vendor stuff in place, it would kinda be like putting a band aid over a wound, without removing the splinters of depleted uranium first.

But FP3 can’t be the first qualcomm phone that people had this problem - and discussion with. Is there a list of the different features - QSECOM, video libs, drm stuff, modem userspace stuff, etc… listing

• what they do
• if they are required for the phone to work (or can just be ommitted / replaced by a software only variant)
• if there is an open source alternative
• etc…

[JeroenH]

Can one not disable those Qcomm services with adb? Like, you boot up the system (without networking), mount with USB debugging, and disable them right away.

You could argue if you cannot trust Qcomm then it is end of story. Who knows what they backdoored (intentionally or not) and how, after all? If that is your threat assessment, it makes more sense to use a non-Qcomm SoC.

[Dosenheini]

You could argue if you cannot trust Qcomm then it is end of story. Who knows what they backdoored (intentionally or not) and how, after all? If that is your threat assessment, it makes more sense to use a non-Qcomm SoC.

There are no free baseband processors, as i know.

[smurf]

Simple answer: If you disable the Qcomm stuff, your phone won’t have a radio any more.

AFAIK people who know how to selectively disable these things do not talk to the free software community. And we do not have the expertise, time, or tools to do any of that.

If you’re sufficiently concerned about this stuff then please do not buy a phone with that chipset in the first place. The Purim people are working on a free/libre phone. Buy one of these instead, and help them. That’s a better use of everybody’s time.

[smurf]

There are no free baseband processors

That’s basically correct, for a lot of inconvenient reasons.

However, it’s possible to shield the baseband away from the “real” phone so that it’s just another device you talk to with a well-defined command set, not an intrusive set of processes that run on your CPU concurrently with Linux and which could, if you’re unlucky / somebody some government wants to spy on/harm / ?!?, read and modify your device at will.

[k4y0z]

qcom blobs are also used for encryption and modem.
There is lots of (userland)-qcom opensource available through CAF but they still depend on proprietary blobs, much like many linux wifi-drivers depend on proprietary firmware-blobs.

[pigpig]

We can try to get rid of the worst/useless of them ?
Then we can do a magisk module to uninstall the one we can, or install an alternative if it is exists ?

I still have :

• com.qualcomm.qti.optinoverlay
• com.qualcomm.qti.qms.service.connectionsecurity
• com.qualcomm.qti.qms.service.trutzoneaccess
• com.qualcomm.timeservice
• com.qualcomm.qti.qms.service.telemetry

@corvuscorax did some test on the other thread.

[corvuscorax]

I don’t know what services exist and what they do. Some of them are apps, and can be easily disabled/uninstalled with adb, but some are not.

The one case which was confirmed to spy (it sends periodic requests to the cloud - unencrypted - to a HTTP server while leaking phone specific data through user agent string - allowing tracking of phones) is what my firewall identified as “GPS daemon” (android.gps)

the firewall normally identifies apps by user ID, since each app has its own user. gps daemon isn’t an app, it’s a hardcoded “known” user ID, and there are several qualcom programs running with that user ID. unfortunately, without root, i couldn’t even identify which one of them sent the network requests. this needs further investigating.

I, personally, would be happy to just reliably disable the known and identified spyware. getting rid of all proprietary libs probably somewhere between futile and too much work to be feasible, but at least identifying and removing those that are known to “talk home” is IMHO a necessity.

[pigpig]

Now we have root, it is possible to dig deeper. Did you try to mitm and bypass the certificate pinning ? Also, I don’t know if the bins which aren’t apps do certificate pinning.

Which app did you disable (thinking about telemetry ^^) ? Did you notice any behavior change ?

Also, the afwall wiki already has some system app info (no qualcomm relative)

From this XDA thread, it seems possible to disable :

• com.qualcomm.qti.qms.service.telemetry
• com.qualcomm.qti.qms.service.connectionsecurity
• com.qualcomm.qti.optinoverlay

Most of the other apk are gone with LOS

[corvuscorax]

I disabled com.qualcomm.qti.qms.service.telemetry and com.qualcomm.qti.qms.service.connectionsecurity without any problems.
I did not try mitm for the TLS encrypted stuff, since most of it could be blocked succesfully by-app (or the app simply disabled)
The one which I couldn’t block (the gps daemon requests) are not encrypted, (plain HTTP) so intercepting the request was trivial.
The purpose of the request is legitimate, it downloads a GPS almanach from qualcomms servers in order to allow devices to get GPS lock more quickly. the issue is that the HTTP request leaks device specific information using the UserAgent string (all documented in the other thread) which can be used to fingerprint the device.

This is especially annoying because its unencrypted HTTP, so not only can Qualcomm fingerprint the device, but so can anyone who intercepts that traffic.

I will investigate that a bit more once I have rooted my device

Edit: This old vulnerability is related:
https://www.cvedetails.com/cve/CVE-2016-5348/
its for an older version, but the same service. So not only does this leak information about your phones whereabouts (fingerprint, IP address can be tracked at least with city-accuracy) to qualcomm and anyone who’s listening to the traffic, but it also provides a security risk by spoofing potential responsses.

[pigpig]

Nice work !
I don’t know if the gps with LOS has the same behavior. Maybe a patch or a hook can get rid of this leak of data

[corvuscorax]

or a selective IP tables rule I think a lot of privacy concerns could be mitigated if qualcomm-specific libs and services can somehow be sandboxed in an environment where they can’t do any harm. (chroot, isolated network, maybe a proxy for selective network access if needed)

[pigpig]

Yes but I meant, if the request is legitimate, it’ll need to reach the server ^^. So we can hide same data (e.g. the USER-AGENT).

[JeroenH]

There is no good reason why that almanac data is not opt-in, and why it is not served over HTTPS. Not only can the data be read, it can be modified as well.

[calvofl0]

@corvuscorax

But unfortunately, like probably 90% of devices now, FP3 is a Qualcomm phone, and the qualcom stuff is rooted much deeper in the system - mostly on the vendor partition. There is spyware on the phone that are not apps but a system service running - some of it even with root privileges.

I don’t fully understand. How deep? Do you also suspect software running on a layer deeper than the kernel, or only software from the vendor partition running on top of it, that could be theoretically blocked with a properly configured firewall?