Q) "Wait, on their FAQ page I see that they don't want to include the patch for security reasons. Is this ROM unsafe?"
A) "No. LineageOS' developers hide behind the "security reasons" shield, but in reality they don't care enough about the freedom of their users to risk to upset Google by giving them an alternative to the Play Services... Moreover, to further strengthen the security of our ROM, we modified the signature spoofing permission so that only system privileged apps can obtain it, and no security threat is posed to our users."
This is such a petulent attitude towards what sound like well-founded objections to the outright spoofing of Google signed apps that I'm just plain out already.
Also, using the phrase "no security threat is posed to our users" in ANY context is blindingly arrogant, and pretty irresponsible to boot.
They gave an explanation of the security issue, along with a (rather unhelpful) link to LineageOS' stance on the matter and explained which defenses they employed to keep it secure (put it behind a permission prompt that is only available for system apps)
This seems reasonable to me. How is this more dangerous than, e.g., giving an app permission to continously track your physical location?
One is replacing signed system components, the other is volunteering to share whereabouts with a third party.
The biggest concern with this is that Google has the resources (and pressure) to get something so central to the security model correct. I've no inside information on how Google develops Play Services, but I imagine they have quite stringent policies with regards to testing and peer review.
The actual functionality of Play Services is only one part of the work that goes into delivering it to your phone, and it's a lot of trust to place in anyone to get something like that right (considering the personal, security-sensitive information we keep on our phones now).
My point was that the FAQ was a big red flag for me in thinking that the developers grasp this aspect of what they're proposing here.
Your comment about the petulant FAQ item was on point: it's possible to develop an alternative fork without taking such a childish attitude toward discourse with the original project.
On the other hand, I think your implicit trust in internal Play Services policies may be a little over-egged. Google definitely has some great security teams (Chrome/Chromium's security team have made some good contribs to the web, Project Zero is also cool, if a little externally-focused) but this is by no means universal. Android's been a bit of a sore spot in this regard generally (particularly in comparison to Apple).
How is comparing the security of Android, which is a far more open and diverse platform, to Apple, a walled garden, fair at all? And let's not forget about how Apple happily gives backdoor access to apps like Uber.
Sure, Apple makes their own life easier in terms of security by applying draconian restrictions on the freedoms of their own users. But this and the fact that things are not as easy for Google to do effective security doesn't make it any less true that they aren't doing it.
Again, Apple's Uber backdoor isn't really relevant - I never implied Apple were benign, just that Google's security record is imperfect, and compares poorly.
The openness and diversity of Android's platform isn't a wholesale excuse for not securing users.
You can't use the remote APIs you need to deliver the same local APIs that are required to run modern apps without spoofing the signatures of applications - otherwise google's remote APIs would forbid access. This is where security measures are also inherently DRM-ish, and to deliver the experience typical end users expect using free software (free-er than stock android) it's necessary to circumvent it. One could argue that such circumvention is illegal. I hope no one deems it to be so.
"Don't start me on Stagefright and Mediaserver, I could rant for 2 or 3 hours non-stop! Seriously, the code over there is crap, and has insane concepts, like aborting the whole mediaserver (and all related media decoding of all other applications running at the same time), when it parses a file with attributes it does not know, instead of skipping the file. We discovered some issues in Stagefright (busy loops, device reboots, mediaserver crashes) quite early, but we never thought about submitting them."
They're dismissing risk as a non issue since they've displaced responsibility on the user. Their system isn't more secure because it is reliant on the user. Time and time again it's been shown that the user is the weakest link which is why some many of these types of systems are in place.
> Their system is explicitly for people that don’t trust Google.
Yes, and LineageOS is not. LinesageOS has an interest in maintaining the ability to run Google blobs and accepting such a patch might potentially harm that interest.
Instead of accepting that, this project acts all butt hurt and whines that LinesageOS's position is inconceivable.
NO! LineageOS has no agreement with Google to provide Play Services. In order to do that you have to literally pirate play services and install them on LineageOS. That, IMHO is a far greater concern than allowing a SYSTEM app (one that is built into the framework) to pretend to be google play services.
> Yes, and LineageOS is not. LinesageOS has an interest in maintaining the ability to run Google blobs and accepting such a patch might potentially harm that interest.
Maybe I'm being a little pedantic, but my point is it's not LineageOS that makes that call. LineageOS does not distribute gapps and is not in any agreement with google that would possibly adversely impact users' ability to run gaps due to such agreement being revoked were LineageOS to act against googles interest. CM on the other hand likely would have been either directly or indirectly when it was buddied with one plus (which is when this went down).
There are a lot of subtly incorrect statements in this thread and I'm trying to help clarify because I find this discussion interesting and important.
And there are people who do want those blobs. LineageOS has chosen to err on the side of caution and not allow a patch that might prompt Google to take action.
So what you're saying is that you believe the real reason this patch wasn't merged is because google might take action, and the security concerns are not as relevant? One might even call them a... shield?
Someone built a location API or crypto API or whatever so that apps can use that data.
If there is a permission that violates the trust between the system and an app using aforementioned APIs all bets are off. This is similar to why rooted devices are bad for security.
I understand why this seems alarming to a bystander. But if you're still dubious go read the Gerrit reviews--it's pretty clear the CM team was unwilling to accept the patch because "it allows one app to impersonate another" not because it presents a security hole. The patch went through multiple iterations ending on one that means users would literally see a prompt:
"microGapps is requesting permission FAKE_SIGNATURE to ..."
The point is that it's not a security concern _if the user allows it_. By definition.. it's tautologically impossible to classify such a scenario as a security concern if the user selects "this is not a security concern" when asked if they're concerned about about allowing microGapps to fake the google play services signature.
The microGapps team then asked "how would you propose we land on a solution so that we can provide an alternative to gapps while still checking the [x] security box? The CM team failed to provide any sort of compromise stating that allowing one app to impersonate another is not a feature they were willing to support on their platform.
So you see, it's not security that was the issue. The issue is that the CM team was unwilling to give users the freedom to allow the system to work as they want. What's infinitely ironic is that CM used to ship with root. It was the community fork "for the community by the community". It's not hard to correlate their sell out with their rollback on providing support for apps that need root and then irrational stance on letting some other thing be google play services.
The uGapps team is frustrated, but it's not petulant. It's very valid.
LineageOS provides the root flashable zip for any of their ROMs.
I will read more into the security claims and concerns, and may be persuaded, but at first blush I support not spoofing application signatures, as this is the same sort of chain of trust that package managers and app stores are built on.
As a consumer, I appreciate that LineageOS with Google services passes most to all of the CTS/Safetynet checks, and doesn't make me choose between having an updated, streamlined version of Android, and using my bank app, or playing Pokemon Go.
I think merging these changes could easily jeopardize that and maintaining it as a fork makes sense to me.
There is a security threat for the user, only if the user puts application inside its /system/priv-app folder.
If an application is in /system/priv-app, it can do pretty much anything anyway.
Worse than that, a threat-model assuming an attacker can write in /system/priv-app, he can most likely write into the whole /system, and replace everything of Android, install Xposed, etc...
So I totally agree that if the patch does what it says (I didn't read, but it's possible.), "no security threat is posed to our users".
Though an acceptable reason from LineageOS imo is "this will be used to circumvent protections (read SafetyNet), we don't want that"
Calling DRM "security" is bullshit and should be called out every time. It's not extra security for the user, it's security for someone else's revenue stream.
The comment above has to do with package signing, which is a security feature. It prevents malicious software from replacing legitimate programs on your device (e.g. a malicious "messages" app cannot overwrite the legit "messages" app you installed). It doesn't have anything to do with DRM.
Basically, Google built important Android OS APIs into proprietary libraries that check that the API-implementing library is signed by Google. This is done for DRM purposes to prevent users from using alternate services and to give Google leverage over manufacturers that use the "open" Android OS. It does not benefit users or provide them any extra security.
The package signing is only circumventable if you already have write access to /system.
That's all the μG team is asking for: If you already have write access to the entire system, at least provide a simple API to circumvent the signatures.
That how lineage ships by default. It's a bit of a pain and many other apps (even open source ones) won't work, since google is providing the library for those apps to do things like access your location.
I'm able to access my location no sweat. The proprietary google track-and-upload-everywhere-you-go thing is an anti-feature, GPS alone works perfectly for me.
Programs that require Google Services just plain suck. That's like a game that only runs if you have a mouse from Logitech or a document viewer that only supports printinf if you have a HP printer. Both would just suck and be shitty, borderline malicious programs.
I don't know if that's a fair comparison since Google Services are running on the vast majority of Android devices (except in China) but Logitech or HP don't have that same market share for those respective products.
I get that it's annoying if you choose not to run Google Services. But from a developer perspective if 99.9% of their target market does run Google Services and they make development of the app easier or provide useful features, I can see why they would choose to rely on them.
The way they've done this basically has users begging for it though because the alternative would likely be excessive battery usage for some things and no updates for others. I'm on lineage but most people aren't fortunate enough to have nexus devices or don't know/care enough to run anything other than what comes with their device. I think moving everything possible to play services is helpful for them.
If it was about the features, they could (and should) have released these bits as part of AOSP, as free software.
Not doing so reveals there actual reason: control. Forcing every manufacturer to ship Play Services and thus being able to force various things on their devices is a major financial benefit. It also ensured that Amazon or Nokia were unable to set up a commercially viable Android Fork without Google.
Then don't install it or uGapps. The point of uGapps it to provide an open-source implementation that can be audited so it's easier for you or me to decide if we want the code running on our phones.
I've been running LineageOS on my OnePlus 3 for a few weeks now, since the whole data collection furore. It's been absolutely fantastic and I'd wholeheartedly recommend it to anyone. Battery life has been much better and I love all the extra features in their camera app, for instance.
I'm not so sure about this though. It seems like they've disabled some very important security features. Their justification of "Lineage obviously hate freedom and are in bed with Google" doesn't sit right with me. Also there seem to be a lot of hoops to jump through just to re-enable the Play Store, which I'd consider basic functionality for any Android device.
Still, the pursuit of more freedom is a noble goal and I wish them all the best.
Just to provide some context for the "very important security feature" that is disabled. The change adds a permission that allows (after explicit whitelisting by the user) an app to impersonate another app.
Specifically, it allows microG apps (which are open-source and auditable) to impersonate Google Play Services apps (which are closed-source and not auditable) and thus provide their functionality.
They could still make it default and then allow an option in settings to allow other apps.
This would be similar to how root apps originally allowed anything to use root capabilities (with user permission), and then they made the default "Apps-only".
Well, functionally that would be the same as if you just don't grant the permission to any other app than microG. Unless you don't trust that Android's permissions work properly, but then I think you have much bigger problems.
We've known that in theory your compiler et al can be backdoored but in practice we can feel a lot safer compiling our own software than using proprietary binaries.
I think that might be where we disagree. Without a competent security audit I think you are falling back to trust.
Open Source vs Closed source is not where I or the security professionals I know put most trust emphasis. I would enthusiastically trust something closed from Google over a rando open source project.
But back to the original point, even the most basic audit steps are the same on an open source project vs closed one. Observe what the binary does & inspect it for standard patterns.
But note you are now adding a lot of extra preconditions that are largely not available.
The counter argument is reverse engineering & black box audits are actually easier than getting the conditions right to trust code audits. As a bonus they work regardless of the code availability.
So you can trust your disassembler and strace, but not your compiler? Your method is just vulnerable to another flavor of trusting-trust. What about the compiler that built your rev-eng and blackbox tools?
My original claim, that I stand beside, is that code audit-ability for security purposes is not a reason to prefer open source software. For all the reasons this thread points out, that is just as fraught as auditing closed source software. Further, a competent audit of the software would not look much different between open and closed source projects.
Absent a competent audit, there are lots of other factors that are higher on my (and many more knowledgeable peoples) lists for importance to security and privacy than open vs closed source. Things such as documented and approved algorithms, the team involved, the amount of legal backing, the market incentives etc.
That is not to say there aren't reasons to prefer non-Google based API or to prefer open sourced software for other reasons. Just security audit-ability is a bad one.
I don't think that you've fully appreciated the rebuttals to your position. Consider this: you audit your build toolchain and thereafter trust it not to manipulate your binaries. With this axiom in place, is it not true that it's easier to audit open source software (assuming it's built on a trusted toolchain) than proprietary software?
I don’t think you’ve understood the original premise. Suggesting that closed source software isn’t auditable Is laughable. No one who does software audits for a living supports that premise.
There are different types of audits. Yes someone doing a full security audit is going to be happy with doing reverse engineering. But I can perform a quick check on a lot of the software that I use that it doesn't do user hostile things (like ring home on startup) this is harder to do on a binary - so given the choice I'll use the open source option.
Because I can trivially read and run code in my head I do that all day. I don't have a clue how to set up a proxy. Also my scan over the code tells me if it is generally badly writtes and a lot more than just one example of potential bad behaviour.
Yeah. As a developer the former is literally the $dayjob. The latter - I've never done so it could be simple or it could be hard. I've heard that getting software to respect proxies is tricky though...
So um. I'm a developer and the idea that I could take an arbitrary code base and get it into my headspace in less time than it would take me to figure out a programs network interactions is one of the most absurd things I've ever heard.
How would you force an arbitrary program to use a software proxy for all network traffic?
The thing is this isn't just about network interactions. By taking a quick scan of the code you also (1) might learn something new, (2) can see the athors general attitudes to things, (3) might spot some other nasty activity (does this program hot load code from a remote source, try to obscure what it is doing, scan the file system? Etc)
How would looking at network sniffer logs let you detect any security flaws for a server, as long as none of the live traffic is doing anything sketchy?
I also recommend it. And I'm a bit sad CopperheadOS, which was an excellent more secure alternative (they had teamed up with The Guardian Project and F-Droid [1]) contains now non-open source code of their own [2].
All of the CopperheadOS source code is still published and can be modified / redistributed. It's not Free Software anymore since that wasn't supported by the community while at the same time it was exploited by (competing) companies without giving back. The choice was either having a working business model by requiring payment for commercial use or ending CopperheadOS.
Signature spoofing in the past and now can only be enabled on a per-app basis by the user. So the ROM can have signature spoofing support, and the user can have 20 malicious apps installed; none of those 20 apps can spoof signatures unless the user allows it.
It's basically just another permission.
With that said though; if a user blindly-enables the permission on any app that asks, that's a pretty big security issue. But I'd rather have the choice than accommodate uninformed users...
LineageOS no longer comes with root installed, you have to install an extra zip file while flashing to enable it - https://download.lineageos.org/extras
IIRC some root detection mechanisms still check for an unlocked bootloader.
There's no root builtin, use Magisk with the Hide feature to prevent it from being detected by banking apps and such - even apps using the rather nasty SafetyNet work.
With that said, I highly question why any banking app would check root, mine doesn't and it seems to me like even if it did I could still use their website on my phone while rooted or my Windows machine with no sandboxing whatsoever. Requiring it just for the app seems pretty damn pointless.
A lot of banking apps store cached transaction data and authentication tokens on the "protected" (not accessable to non-root from other apps) part of the data partition. If you run without encryption or with either unlocked bootloader or TWRP installed, someone could just pull that from a device in recovery mode. That's also why unlocking the bootloader wipes your data partition usually.
This should be OR. If you have FDE enabled, then the data is encrypted and it doesn't matter if your bootloader is unlocked or you have a custom recovery installed -- all caveats about the trustworthiness of the crypto and strength of your key still apply.
I'm guessing this is a gut feeling as opposed to any empirical data? Either way I'm curious as to why this would be the case. Unless I misunderstand the kernel is identical between LineageOS & whatever stock OS was on the device. And it's the kernel that presumably impacts most on battery consumption.
I installed LineageOS on an old Nexus 5. The stock OS on the Nexus is already pretty clean so I can't say I noticed a massive difference (although I didn't spend much time on it)
I actually tested this a little on a Nexus 5X a while back. With a clean install of a LineageOS build manually patched to include microG (before I knew about this fork), I unplugged it from the charger at 100% and left it for 8 hours without using it, at which point the battery read 98%. The same device with a clean install of stock Android from Google read 87% after 8 hours of standby after a full charge. In both cases it had good LTE signal and had no modifications from a clean install other than signing into a Google account.
To me, a fun thing to realize was that putting my phone in airplane mode wasn't enough to stop the phone from discharging a lot during the night.
Also, installing SSL Packet Capture showed me that some of my (not even considered shady) apps made a lot of things in the background, eg sending stats or other data to their mothership.
What did do the thing for me was to go into battery settings and set the device in the lowest mode, that severely restricts background work. This, plus airplane, and the device basically doesn't drop anything over a night.
I miss some option (non-root since I want to be able to use bank apps) to tell my phone to never allow anything from apps A, B, and C unless it is active and/or in foreground.
> I miss some option (non-root since I want to be able to use bank apps) to tell my phone to never allow anything from apps A, B, and C unless it is active and/or in foreground.
Sorry if I sound like a broken record but to me run at boot, run in background, storage (outside your own not-shared-with-other-third-party-apps sandbox), and network should all be explicitly opt-in.
Google services tend to make use of wakelocks a lot I believe (I think the nlp [network location provider] service in particular), so replacing these could lead to better battery life if the replacements use less wakelocks etc.
EDIT: Realised parent comment was about regular LineageOS, not the microG fork, never mind
I'm also in the same boat as SmellyGeekBoy, and can attest the same. With the Oneplus rom I saw maybe 1.5 days of battery, with Lineage I often see 2-3 days.
This is completely anecdotal however, and it's likely that the reduced battery is down to having installed different/fewer apps on Lineage.
Google requests location all the time, but it's hidden under the Android OS and Android System categories.
I find it infuriating when it's obvious some app is draining my phone's battery fast, but I can't see which, because Google is allowing developers to hide that activity within those two generic categories.
You can definitely encrypt your LOS device and update it (manual or OTA) just fine. I have a Nexus 6 and have been doing it for months now, both with official builds and a custom build I was doing.
I have an encrypted S5 with LoS. I believe autoupdate just doesn't work on it with TWRP period, but it might be because of the encryption. Either way, I just download updates once a month and sideload them.
While this is cool, I feel that this will always be a second class citizen at whims of Google, who can break or change their APIs any time. What would it take to provide a proper API replacement that apps can target instead of google play services ? i.e., not spoofing but providing a legit alternative. If I have a spare server for instance, can I set up a GCM like server that can relay messages instead of them going through Google ?
It's not going to be completely at Google's whim, as disabling a certain API/interface means older proper-android devices will also fail. So microg is banking on it's API interface being fine, given Google's interface, for business reasons, has to be fine.
I don't know why. Lack of space on some phones maybe, or they could be configured to autoupdate via wifi only but never see wifi. Whatever the reason, if you use google play services, you'll see a few devices with old versions that don't update even though there is a newer version for that OS version.
This allows developers to use new api calls and have their apps work on old devices, it doesn't let google break existing apis without breaking apps. They aren't like recompiling the whole play store against every new google play services build or something.
What I basically want, and have been wanting for years, is to run Linux on my phone, and run Android apps (∗) inside a sandbox (that works on both my phone and my desktop computer). But I guess it is too much to ask.
One of the "stretch goals" for Purism's Librem 5 [1] (which is a pure GNU/Linux smartphone platform -- designed to work with upstream distributions) is to be able to run Android apps under an emulator.
Their funding goal was $1.5m, and the stretch goal for Android app support was $10m! That says to me they are not interested, putting it as such a ludicrously high goal. Still, I suppose a phone which runs on the mainline kernel will have access to the kernel features necessary to run Anbox. I'd be interested to hear how difficult people think it would be to get Anbox working for this kind of device.
>That says to me they are not interested, putting it as such a ludicrously high goal.
It says to me that they expect it to be super expensive in comparison to other stretch-goals, and that it's not a core goal of the project (and the latter should be true for literally every stretch-goal, in any kickstarter ever).
That is completely unrelated. This is about propriety Google play services. Not about android or aosp. You can anyway run aosp on any number of devices.
> Lots of them run fine without Play Services (including Google Maps).
And there's also OsmAnd, which I think deserves a try.
I haven't used Google Maps in a few years, but I initially switched, because OsmAnd was much more reliable with offline maps. I've also heard people say that they've found OsmAnd's maps to be better, especially in more secluded areas.
+1 for not needing Play Services. I've been running a free Android, and so far every app installed has worked fine, except push notifications, but I see that as a feature—less interruptions.
Can you recommend a good free gmail client? The default email app doesn't work well with gmail -- double sends every time.
Maybe you'd want to migrate away from Gmail too if you're happy without Play Services? I've been happy with Fastmail, and their import from Gmail worked without hiccups.
I'm rather puzzled by all the fuss about this signature spoofing thing. As far as I can tell, the microg team has not proposed what seems to me to be the obvious solution: allow signature spoofing for system apps and their downloaded replacements only. So users can't install a signature-spoofed app unless they do it as root or using a .zip update. No risk of users clicking the wrong box or being dumb. Heck, one of LineageOS's review comments even offered this as a potential option with no meaningful reply.
What am I missing?
Edit: here's the review comment:
> Adnan Begovic
> Oct 8, 2015
>
> Patch Set 2:
>
> Also "dangerous" doesn't limit third party apps from using it, you'd have to limit this explicitly to system|signature if you wanted any realm of a security model.
That doesn't sound like "politics" to me. That's a spot-on reply.
> Moreover, to further strengthen the security of our ROM, we modified the signature spoofing permission so that only system privileged apps can obtain it, and no security threat is posed to our users.
It seems like such a small one method change, in the context of forking an entire distro.
I wonder if PackageManagerService is hard coded in many places, rather than using XML dependency injection. If the latter then may it be possible to override the method in a subclass, e.g. MicroGPackageManagerService and distribute the change via a once-only installable zip?
That way Lineage OS doesn't need to break security, only downstream.
I was under the impression that lineage doesn't come with this anyway and you had to flash whatever google binaries you wanted. This just seems like they've removed one step. See bullet point on Step 1. on the wiki: https://wiki.lineageos.org/devices/cheeseburger/install
LineageOS works without the GApps, but you lose lots of (fundamental) things, like network location and GCM (push notifications). Moreover lots of apps require the GApps API to work (often the Maps API) and crash if the GApps are not installed.
What's the point? If you're using Google services, you're a slave to the mothership and they know what you're doing. So why use a different layer of middleware to access them?
I use F-Droid because I don't want to use Google services. I do miss voice dialing, though.
You're mixing up microG with OpenGApps. microG for instance can do Assisted GPS location searches, but allows you to choose your own Location Services provider, Mozilla instead of Google. It's not just a middleware to access the same Google services.
Finally! Until now after each LineageOS update I had to connect phone to adb, and patch with tingle or needle to re-enable signature spoofing. Great solution, shame the LineageOS devs won't just add this as an flashable zip or configurable option.
This reminds me of what Linux and WINE for Linux was to MS Windows. It's a fight against a closed eco-system. I applaud them, and hope to give it a try.
I wish Google would put and end to this by releasing the code for their Android services and slowly force the Android manufacturers to open source all future drivers.
In order to use MicroG, it is required to patch the ROM to allow app signature spoofing. People from LineageOS claim that this can be a huge security risk (and they are right) but there is no other way to achieve an implementation like this.
So MicroG people created this fork with the patch builtin.
"Wait, on their FAQ page I see that they don't want to include the patch for security reasons. Is this ROM unsafe?
No. LineageOS' developers hide behind the "security reasons" shield, but in reality they don't care enough about the freedom of their users to risk to upset Google by giving them an alternative to the Play Services."
LineageOS's have a policy of not circumventing integrity checks e.g.:
The people behind this ROM seem a bit immature if that's how they react to their policy especially since they're just taking the upstream code wholesale to stick their patch in.
The FAQ states I should shoot them an email to get my device added to the support list, but I can't seem to find the email address… Am I blind? Can someone point me to it?
I haven't been using this ROM in particular but I have been using MicroG almost since its inception (without any of the official Google stuff installed) and I have to say it's a very smooth and seamless experience.
I use Whatsapp, Riot (APK from Google Play with GCM enabled), Google Maps, and a bunch of other apps that depend on Maps and GCM services and all of them work fine.
Sometimes I almost forget I don't have GoogleApps installed.
I'm using a LineageOS Oreo build on a Moto G5s Plus (replacing an iPhone 6) with MicroG and it's like night and day. Everything's ridiculously quick. I've had some minor niggles (which I put down to my lack of knowledge) but it's pretty fantastic. The only thing that doesn't work is the dual lens camera (I don't have the app from the original firmware so I only get one lens).
I'm trying to figure out how to rebuild from non-official github repos, then I'll look at setting up a proper automated build of my own.
The point is that it's entirely up to you how many google apis you want to use, and at what terms. You aren't installing an opaque google play blob as a system app.
Actually is pretty stable right now, the most important features like Google Cloud Messaging and the Maps API v2 work flawlessly. Only certain specific apps give some issues, which usually are fixed in short time.
Can someone explain what this? Is it a fork of Android with the Google service apps rewritten? Or just the latter?
Could I take an old Android OS and install the alternative Gapps?
Yours, confused.
>Only difference when comparing against LineageOS is that the OpenGApps package is "free".
Rather GApps (google) functionality is re-implemented from scratch and the necessary means (app signature spoofing) to replace GApps with microG is built into this LOS fork
Lineage OS is a fork of Android. This is a fork of Lineage which replaces all the binary blobs to make the Google services work with open source code (with the same or similar behaviour).
I don't know for sure but probably not, the services aren't UserReplaceable.
"We ship OTA updates from upstream LineageOS every day. In this way you always receive new features and security updates just few hours after they are released mainline."
Is this going to try to install updates every day? It sounds like too much.
I am utterly baffled by this project. What's the benefit of using open source software to access a completely closed-source set of services? If you're going to trust Google with your data anyways why would you care whether you're running a Google binary blob on the device?
The only Google-related services I'd like to use on my phone is account log-in for Pokemon GO and Ingress. My options are a 120MB+ package of proprietary Google apps with max permissions to do whatever and run in the background, or a 4MB microG package with very limited permissions.
I can't use Signal or my local railway app without Google Cloud Messaging.
So I have two choices:
- Don't use them
- Install Google crapware package
- Install microG, which supplies the APIs so other apps can function normally
microG also reimplements the Google Maps APIs (using OpenStreetMaps) and the Location APIs (with different backends, like Mozilla Location Services or a local offline database). The main Google-based service is Google Cloud Messaging, which is disabled by default in microG.
As you can see, microG doesn't strictly depends on the Google cloud services.
The whole point of this ROM is not including the Play Services at all.
Don't know if it is against their ToS to use the Google services with microG instead of the GApps.
But then, there's no TOS at this URL, and there's no point in taking this repo down, it would only make Google look bad and give microG free advertisement.
It'll probably violate the ToS of hitting Google's APIs. However, no OEM is shipping these. So there's no one to sue. The responsibility is on the user who flashes this. The code itself is free software. If Google sends a takedown to github or whatever, that would be a PR disaster. More practically though, if this becomes big, it would be trivial for Google to break the APIs.
Actually it's not trivial to change server APIs because they don't fully control all the clients (not even all officially supported ones).
For example: push notifications are supposed to work without setting up a Google account (if you use a certain Android version). But if you don't log in to your Google account, you're not receiving updates through Play Store, and thus Google can't update the client. Google breaking their claim will upset some of their users (probably not the typical smartphone users, but think of entertainment systems based on Android for example).
Also note that most Google ToS don't specifically forbid third party usage (and some also specifically allow them), the only thing that's forbidden is to misuse APIs in a harmful way. Just another example would be the login/account management part of microG, that uses the publicly described OAuth APIs, obviously intended for third-party use.
Pretty sure that this is simply copying an API, and Google specifically fought a court case against Oracle, against the notion that they couldn't copy Oracle's Java API. As such, I doubt they'd have a leg to stand on without giving Oracle another shot at them.
It does not turn off signature checking. It allows selective, whitelisted system apps to impersonate other apps after a permission is granted by the user.
Specifically, it allows the open-source, auditable microG apps to impersonate the closed-source, unauditable Google Play Services apps.
As much as I like the idea of running an Android device without gapps while remaining fully functional, and I feel this fork goes out of its way to attempt to remain secure, I just can't get past the fact that it's still a security hole. Eventually some bad actor is going to hammer at this hole until he finds a way in, then it's game over, restart from scratch.
I think the larger problem, the one that caused the microg gang to go this route, is the increasing control Google wants to hold over their platform. Fanatics always promote Android as the "open source alternative" to iOS and Windows Phone, but if you have to strip out so much proprietary gunk that it renders the device unusable, how can they claim it's open source with a straight face? Sure, the core Android code and kernel is still open, but there's a huge difference between being able to boot a device and actually using it daily.
This doesn't make sense to me. You already have other permissions (draw on top of other apps, full filesystem access, etc) that could be catastrophic to grant to malicious apps. If you don't trust yourself not to grant them, or you don't trust the Android permissions system itself to be implemented correctly, it's already game over.
(Edit to add: I agree with everything in your second paragraph.)
Signature Spoofing isn't enabled by-default and can be toggled on a per-app basis. A rogue app installed isn't going to have the ability to spoof another app unless you manually give it the permission.
The signature spoofing in this ROM can be granted only to system privileged apps (so, built in or installed through a ZIP in recovery): the user can't turn it off (why should he?), but no app other than microG can obtain it. In this way you can't even accidentally give this permission to a malicious app.
Q) "Wait, on their FAQ page I see that they don't want to include the patch for security reasons. Is this ROM unsafe?"
A) "No. LineageOS' developers hide behind the "security reasons" shield, but in reality they don't care enough about the freedom of their users to risk to upset Google by giving them an alternative to the Play Services... Moreover, to further strengthen the security of our ROM, we modified the signature spoofing permission so that only system privileged apps can obtain it, and no security threat is posed to our users."
This is such a petulent attitude towards what sound like well-founded objections to the outright spoofing of Google signed apps that I'm just plain out already.
Also, using the phrase "no security threat is posed to our users" in ANY context is blindingly arrogant, and pretty irresponsible to boot.