LineageOS for microG – Access Google services without closed software(lineage.microg.org)
lineage.microg.org
LineageOS for microG – Access Google services without closed software
https://lineage.microg.org/
195 comments
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.
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.
Why not hardcode this for microG only, and not any system app ?
If you can put an app into /system/priv-app, you can already overwrite everything.
The only thing this patch does is provide a clean API for it, so that microG doesn't have to patch your entire system every time.
The only thing this patch does is provide a clean API for it, so that microG doesn't have to patch your entire system every time.
You can't install any system apps without root permissions, and at this point you can do anything, so why bother?
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.
I think it's not really in the spirit of openness/freedom to say "you can replace Google's software, but ONLY with ours"
You could allow this in config though. I.e.
() No app spoofing () Microg apps can spoof Google apps () Any apps can spoof any apps
() No app spoofing () Microg apps can spoof Google apps () Any apps can spoof any apps
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".
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".
Minor nitpick. Closed source software is of course audit-able. Being able to audit binaries is table stakes to even call someone an auditor.
There may be many valid reasons to prefer open source software but security audits aren’t one of them.
There may be many valid reasons to prefer open source software but security audits aren’t one of them.
I'm gonna take it on good faith that you're not a troll...
Open source software is much easier to audit than closed source software. People have a finite amount of time to do things like audit their software.
Open source software is much easier to audit than closed source software. People have a finite amount of time to do things like audit their software.
But auditing the source is only useful if you can do reproducible builds to be sure you run the audited source.
This is rarely the case unfortunately, and for most of open source prebuilt software you use, you rely on trust and not on audit.
This is rarely the case unfortunately, and for most of open source prebuilt software you use, you rely on trust and not on audit.
That's not true. You could always, you know, run the version you compiled yourself.
We’ve known for 30 years that’s not enough (depending on your risk characteristics).
Trusting trust is one of the seminal talks in software.
Trusting trust is one of the seminal talks in software.
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.
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.
Observation only goes so far. You couldn't find backdoors unless you started to decompile it.
I think having a trusted compiler is an important first step to trusting software, even if you have to analyize it in depth yourself.
I think having a trusted compiler is an important first step to trusting software, even if you have to analyize it in depth yourself.
2 actually:
https://www.dwheeler.com/trusting-trust/dissertation/wheeler...
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.
https://www.dwheeler.com/trusting-trust/dissertation/wheeler...
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?
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.
For those kind of checks why would you look at the source? Stick a proxy between the internet and the device to see what it does.
Seems waaaay easier than looking for the mythical badCodeGoesHere function.
Seems waaaay easier than looking for the mythical badCodeGoesHere function.
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.
You are more prepared to run arbitrary code “in your head” than setup a simple network proxy?... uh huh
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 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?
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)
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)
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].
[1] https://guardianproject.info/2016/03/28/copperhead-guardian-...
[2] https://en.wikipedia.org/wiki/CopperheadOS
[1] https://guardianproject.info/2016/03/28/copperhead-guardian-...
[2] https://en.wikipedia.org/wiki/CopperheadOS
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.
I know, and I totally understand the situation and your choice.
How is the collaboration with The Guardian Project and F-Droid announced in [1] going?
Don't you think Copperhead might become a really niche choice given how expensive Pixels (vs Nexus) are?
[1] https://guardianproject.info/2016/03/28/copperhead-guardian-...
How is the collaboration with The Guardian Project and F-Droid announced in [1] going?
Don't you think Copperhead might become a really niche choice given how expensive Pixels (vs Nexus) are?
[1] https://guardianproject.info/2016/03/28/copperhead-guardian-...
They didn't really disable anything.
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...
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...
Can you run banking applications (or any that do root detection) on LineageOS? And does the dash charger work as expected with the OnePlus?
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.
IIRC some root detection mechanisms still check for an unlocked bootloader.
And from the same web page there's an uninstall script to un-root the phone.
This is handy if you only need root occasionally, e.g. Titanium Backup, and don't mind messing about in TWRP.
This is handy if you only need root occasionally, e.g. Titanium Backup, and don't mind messing about in TWRP.
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.
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.
And that matters how?
At least all German banks have to have an open API for transactions, and I can run my transactions with curl if I wanted to.
A banking app shouldn't care about how I run it, otherwise I'll just throw it out and use one of the open apps for HBCI.
At least all German banks have to have an open API for transactions, and I can run my transactions with curl if I wanted to.
A banking app shouldn't care about how I run it, otherwise I'll just throw it out and use one of the open apps for HBCI.
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.
Depends. I have a phone with LineageOS installed, and it only passes SafetyNet Basic Integrity. That's a nogo for Netflix or Android pay.
> Battery life has been much better
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'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)
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.
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.
The Google Play Services collect a ton of data. And for that to happen, your phone has to send this data to Google, which drains battery.
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
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.
This is completely anecdotal however, and it's likely that the reduced battery is down to having installed different/fewer apps on Lineage.
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.
It is a bit entertaining to think of Google's surveillance quantified via electricity - we can measure their intrusiveness in mAh.
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.
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.
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.
So it allows microG apps which by their very nature are open-source to pretend they're Google Play apps?
you also have disabled important security features. Or can you encrypt your LineageOS device and update it without problems finally?
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.
ah maybe this is was my issue, I was only trying with TWRP and it always failed (I tried last time May this year).
I have an encrypted LineageOS device and can update it just fine.
Sounds good, but I really need some apps that only run on Android, e.g. for travel, banking, and local TV.
So I hope they will at one point support sandboxed Android apps.
So I hope they will at one point support sandboxed Android apps.
All the banking and TV apps I've used on Lineage have worked fine. They don't complain about it not being an "official" version of Android.
Some won't work if the device is rooted. That's why the latest version of Lineage doesn't come with root.
Some won't work if the device is rooted. That's why the latest version of Lineage doesn't come with root.
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 ?
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.
(∗) for the occasional banking/railway app
(∗) for the occasional banking/railway app
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.
[1]: https://puri.sm/shop/librem-5/
[1]: https://puri.sm/shop/librem-5/
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.
Yeah, I anticipate that Android emulation will be something the community jumps on rather than being a built-in feature for v1.0.
>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).
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).
I don't trust Purism their laptop were rebranded chinese laptop sold at a premium supposedly because they were completely open but they were not.
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.
If you re-read the comment I was responding to[1], you'll find that it is very much related (in fact I was providing an answer).
[1]: https://news.ycombinator.com/item?id=15618507
[1]: https://news.ycombinator.com/item?id=15618507
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.
But isn't Google auto-updating on all devices, including old ones?
Only mostly.
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.
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'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.
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.
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.
Please Google, don't be evil.
Please Google, don't be evil.
Is this going to try to install updates every day? It sounds like too much.
Can't you just install microG services from F-Droid on any LineageOS phone? Why doesn't that have the same issue with spoofing?
I tested a few apps that required gapps like uber and transit and both would load a map but would crash and fail
I have a Pixel XL (first gen) on Google Project Fi. Do I need LineageOS?
can't answer your question, but there is no official LineageOS for any Pixel (1st or 2nd gen). There are unofficial ones
IANAL, but won’t this violate the license terms Google provides for Play services?
Maybe, since this hits Google APIs directly:
https://github.com/microg/android_packages_apps_GmsCore/blob...
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.
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.
Most GCM and checkin related code is actually a Java rewrite of open-source code by Google. They released a client and some protocol specs as part of Chromium: https://chromium.googlesource.com/chromium/chromium/+/trunk/...
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.
Isn't it under the Apache 2.0 license, allowing modification and redistribution of such?
Edit: That license might just be for FOSS components used within google play services, I'm hard pressed to find any specific license anywhere.
Edit: That license might just be for FOSS components used within google play services, I'm hard pressed to find any specific license anywhere.
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.
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.
> "it would be trivial for Google to break the APIs"
That's the most likely route they will take. It keeps their hands clean, as they can drum up a perfectly valid technical reason to break the API.
That's the most likely route they will take. It keeps their hands clean, as they can drum up a perfectly valid technical reason to break the API.
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.
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.
Note I wasn't the one saying it would be trivial, just that it's the path Google can take if they want to keep their nose clean.
Anyone actually using this and can comment on the stability of various apps/services?
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 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.
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.
I'm running my own build that's very similar to this fork: https://forum.xda-developers.com/nexus-6/development/rom-lin...
Works fine for me. I only use Google services to play Ingress and Pokemon GO, and both work without issue with microG.
Works fine for me. I only use Google services to play Ingress and Pokemon GO, and both work without issue with microG.
I switched to LOS+OpenGapps from MIUI on my Xiaomi. It's like day and night. Everything just works. Can't name a single problem really.
OpenGApps != microG
OpenGApps are just the usual bloated proprietary Google Apps, just packaged in a nice and handy way.
See https://lineage.microg.org/#faq1
OpenGApps are just the usual bloated proprietary Google Apps, just packaged in a nice and handy way.
See https://lineage.microg.org/#faq1
Well, it's just the Google play services and some other API they are attempting to replace. Not even mentioning poor documentation.
But anyway, what's the point if I'm going to use ~10 of proprietary GApps anyway (maps, keep, inbox...) ?
But anyway, what's the point if I'm going to use ~10 of proprietary GApps anyway (maps, keep, inbox...) ?
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.
There is wiki page with that info: https://github.com/microg/android_packages_apps_GmsCore/wiki...
looks like it's not stable yet.
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.
That wiki page was last updated roughly a year ago, I'm suspecting it's not accurate enough to rely on.
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.
It's a fork of LineageOS, which is the daughter of CyanogenMod, which is a fork of Android.
Only difference when comparing against LineageOS is that the OpenGApps package is "free".
Only difference when comparing against LineageOS is that the OpenGApps package is "free".
>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
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.
I don't know for sure but probably not, the services aren't UserReplaceable.
Why is this its own fork though? Seems in line with the Lineage mission, shouldn't they just merge in?
Apparently this requires a hole to be punched in the sandbox to allow android apps to "impersonate" other apps (by way of signature spoofing).
The lineage folks didn't want to merge it in on grounds of security concerns.
(I'm not affiliated with the project, I just read the code reviews because I had the exact same question).
EDIT: for those interested: https://review.lineageos.org/#/c/64967/ and https://review.lineageos.org/#/c/65366/
The lineage folks didn't want to merge it in on grounds of security concerns.
(I'm not affiliated with the project, I just read the code reviews because I had the exact same question).
EDIT: for those interested: https://review.lineageos.org/#/c/64967/ and https://review.lineageos.org/#/c/65366/
More information:
http://blogs.fsfe.org/larma/2016/microg-signature-spoofing-s...
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.
More info here: https://github.com/microg/android_packages_apps_GmsCore/wiki...
So MicroG people created this fork with the patch builtin.
More info here: https://github.com/microg/android_packages_apps_GmsCore/wiki...
See https://lineage.microg.org/#faq7
Also http://blogs.fsfe.org/larma/2016/microg-signature-spoofing-s... is an interesting read
Also http://blogs.fsfe.org/larma/2016/microg-signature-spoofing-s... is an interesting read
"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.:
https://www.lineageos.org/Safetynet/
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.
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.:
https://www.lineageos.org/Safetynet/
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.
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
https://lineage.microg.org/#faq3
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.
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.
I guess that's more convenient than what I've been doing (manually patching Lineage using Tingle to support microG on every update :D)
Personally, don't think it's worth turning off proper signature checking in exchange for shaving off 100MB of proprietary code.
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.
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.
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.)
(Edit to add: I agree with everything in your second paragraph.)
I may be misunderstanding the methods involved then; I'm not a security expert and I no longer use Android so I am behind the curve.
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.
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.
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.
Sounds like they do this: https://lineage.microg.org/#faq7
> 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.
> 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.
Sure, but did they submit a patch like that to Lineage OS? As far as I can tell, they didn't.
The patch was submitted, it's unfortunately not visible to the public: https://review.lineageos.org/194562
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 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.
[deleted]
How long did this fork exist?
I've been providing a similar fork for the Nexus 6 for a little while: https://forum.xda-developers.com/nexus-6/development/rom-lin...
I've been providing a similar fork for the Nexus 6 for a little while: https://forum.xda-developers.com/nexus-6/development/rom-lin...
I am perfectly fine with plain LineageOS and no Play Services at all. But, then, I am fine with just Firefox and some instant messaging app.
If I need other apps, I install them with Yalp store or F-droid. Lots of them run fine without Play Services (including Google Maps).
The phone is fast, the battery lasts a lot, slightly better security
If I need other apps, I install them with Yalp store or F-droid. Lots of them run fine without Play Services (including Google Maps).
The phone is fast, the battery lasts a lot, slightly better security
> 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.
https://f-droid.org/app/net.osmand.plus
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.
https://f-droid.org/app/net.osmand.plus
Thanks for the advice, I downloaded OsmAnd plus. :)
+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.
Can you recommend a good free gmail client? The default email app doesn't work well with gmail -- double sends every time.
I use K-9 Droid without any issues with gmail. https://f-droid.org/packages/com.fsck.k9/
Same here, it's great. Integrates with OpenKeychain as well for the best PGP/GPG workflow on a phone.
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.
[deleted]
From the FAQ:
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.
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.
Take a look at the actual technical rationale: https://blogs.fsfe.org/larma/2016/microg-signature-spoofing-...
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:
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.
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 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.
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"
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.
What are you talking about?
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.
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'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.
Maybe some of us don't want any kind of google services on their phone, open source or not?
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.
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 problem is that Google has moved almost all Android features into Google apps.
You can't access the stepcounter directly anymore, only through Google Fit.
Most location features are only available through Google Play's location API.
You can't even get up-to-date openssl or OpenGL support in your app without Play Services.
You can't access the stepcounter directly anymore, only through Google Fit.
Most location features are only available through Google Play's location API.
You can't even get up-to-date openssl or OpenGL support in your app without Play Services.
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.
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.
In that case, you can still have signature spoofing support built-into the ROM, but without microG, it just won't be used.
Signature spoofing only affects app you explicitly give permission to use it, and only apps that call for it.
Signature spoofing only affects app you explicitly give permission to use it, and only apps that call for it.
But, isn't the whole point of this to access Google services? If you didn't want them on your phone, why are you still using them?
No, I don't want to access Google services. I don't want microG on my phone. I don't want Google Play Services on my phone.
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.
Did you try understanding or asking them why they made those choices, and whether your interpretation is accurate?
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?
This seems reasonable to me. How is this more dangerous than, e.g., giving an app permission to continously track your physical location?
That's comparing apples to oranges.
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.
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).
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.
I'm not sure what "fairness" has to do with it.
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.
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.
They're both smartphone platforms. Of course they're going to be compared to one another.
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.
What makes you think that Play Services is well-designed?
Google also designed the media system, and that leads the security patches every month - what would have rehabilitated them?
https://interviews.slashdot.org/story/16/08/26/1338246/the-s...
"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."
Google also designed the media system, and that leads the security patches every month - what would have rehabilitated them?
https://interviews.slashdot.org/story/16/08/26/1338246/the-s...
"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.
People are 100% vigilant all the time.
People are 100% vigilant all the time.
>People are 100% vigilant all the time.
I think you mean the reverse?
I think you mean the reverse?
Well this isn't a normal OS that an everyday user uses?
There are people who don't want any binary blobs from Google on their devices.
There are people who don't want any binary blobs from Google on their devices.
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?
Why can't it be both?
Their system is explicitly for people that don’t trust Google.
With certificate spoofing, the risk is that I might accidentally click through permissions on a malicious, already installed and privileged app.
With LineageOS the risk is that I will, with 100% certainty, run code that I have deemed malicious (== any service-facing client-side Google blob).
Maybe you haven’t decided those binaries are malicious, but that doesn’t change my opinion, and what I do with my phone isn’t your business.
I don’t see why certificate spoofing is controversial at all (especially amongst the “free as in freedom” crowd).
With certificate spoofing, the risk is that I might accidentally click through permissions on a malicious, already installed and privileged app.
With LineageOS the risk is that I will, with 100% certainty, run code that I have deemed malicious (== any service-facing client-side Google blob).
Maybe you haven’t decided those binaries are malicious, but that doesn’t change my opinion, and what I do with my phone isn’t your business.
I don’t see why certificate spoofing is controversial at all (especially amongst the “free as in freedom” crowd).
> 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.
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.
No one said they have an agreement. I said they didn't want to do anything to disrupt the status quo.
> 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.
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.
Again it has nothing to do with agreements. Google is not preventing them from running the blobs, but they could.
LineageOS doesn't want to give the provocation to prevent them from being able to run the blobs.
LineageOS doesn't want to give the provocation to prevent them from being able to run the blobs.
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.
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.
All bets are off for the owner of the device or the author of an app? Bad for who's security?
As a device owner and user I don't care for DRM style 'security' protecting app authors from me running my software on my computer.
As a device owner and user I don't care for DRM style 'security' protecting app authors from me running my software on my computer.
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
Signal can now work without GCM, they merged an alternative that uses websockets.
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.
As you can see, microG doesn't strictly depends on the Google cloud services.
Thanks, this explains things a bit. I think I just misunderstood the scope of this since I'm not in the Android ecosystem.
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.
This sounds great but they lost me immediately as a near-complete rookie with no list of supported devices.
Maybe someone else will will find this useful: https://wiki.lineageos.org/devices/
Can this properly support Google Fi and their network-switching magic? Preliminary research claims it's possible.
https://www.reddit.com/r/Nexus6P/comments/5qusmn/lineage_os_...
if you install it from the play store you need to make sure that Project Fi has all of it's permissions granted
Maybe someone else will will find this useful: https://wiki.lineageos.org/devices/
Can this properly support Google Fi and their network-switching magic? Preliminary research claims it's possible.
https://www.reddit.com/r/Nexus6P/comments/5qusmn/lineage_os_...
if you install it from the play store you need to make sure that Project Fi has all of it's permissions granted
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.