Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Investigate more native MicroG integration #494
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
NathanC
Nov 20, 2016
I've been doing some more research, and reading through previous comments you had about Google Apps--
This is a bit of a different direction from MicroG, but perhaps there could be an alternative build with Open GApps Nano (or Pico), signed so that the bootloader can be locked and OTAs can work? Although would that even be allowed on a licensing level?
I get that additional dependencies introduce attack surface-- but as someone who wants some aspects of the google ecosystem but also wants a secure system, there doesn't seem to be a lot of options and I really want to give Copperhead a chance.
I guess what I'm getting as is, long term, how can the Google ecosystem play at least semi-nicely with Copperhead? It's coupled with Android, and realistically that's only going to increase over time. Mocked out APIs with FOSS providers or some way to use OpenGApps would go a long way in making CopperheadOS useable by a larger population.
NathanC
commented
Nov 20, 2016
|
I've been doing some more research, and reading through previous comments you had about Google Apps-- This is a bit of a different direction from MicroG, but perhaps there could be an alternative build with Open GApps Nano (or Pico), signed so that the bootloader can be locked and OTAs can work? Although would that even be allowed on a licensing level? I get that additional dependencies introduce attack surface-- but as someone who wants some aspects of the google ecosystem but also wants a secure system, there doesn't seem to be a lot of options and I really want to give Copperhead a chance. I guess what I'm getting as is, long term, how can the Google ecosystem play at least semi-nicely with Copperhead? It's coupled with Android, and realistically that's only going to increase over time. Mocked out APIs with FOSS providers or some way to use OpenGApps would go a long way in making CopperheadOS useable by a larger population. |
thestinger
added
Type: enhancement
far-future
Priority: low
labels
Nov 20, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Nov 20, 2016
Contributor
This is a bit of a different direction from MicroG, but perhaps there could be an alternative build with Open GApps Nano (or Pico), signed so that the bootloader can be locked and OTAs can work? Although would that even be allowed on a licensing level?
No, it wouldn't be legal and Google would definitely have a problem with it. It's not ever going to happen. We're also interested in doing things properly, and bundling in the Play apps after the fact and hacking around issues is not acceptable. The goal here is a production quality OS taking robustness and security seriously, not a toy, which rules out using any of that stuff. Proper Google Play integration would be fine but isn't going to happen because they aren't going to license it to us under acceptable terms.
I get that additional dependencies introduce attack surface-- but as someone who wants some aspects of the google ecosystem but also wants a secure system, there doesn't seem to be a lot of options and I really want to give Copperhead a chance.
It's not something that we intend to provide any time soon.
I guess what I'm getting as is, long term, how can the Google ecosystem play at least semi-nicely with Copperhead? It's coupled with Android, and realistically that's only going to increase over time. Mocked out APIs with FOSS providers or some way to use OpenGApps would go a long way in making CopperheadOS useable by a larger population.
It's not going to happen, long-term or not. It wouldn't be CopperheadOS anymore but rather something else, which might happen way down the road with proper Google Play integration but it's not planned and Google wouldn't currently be willing to license it under acceptable terms. Talk to Google about it, not us.
No, it wouldn't be legal and Google would definitely have a problem with it. It's not ever going to happen. We're also interested in doing things properly, and bundling in the Play apps after the fact and hacking around issues is not acceptable. The goal here is a production quality OS taking robustness and security seriously, not a toy, which rules out using any of that stuff. Proper Google Play integration would be fine but isn't going to happen because they aren't going to license it to us under acceptable terms.
It's not something that we intend to provide any time soon.
It's not going to happen, long-term or not. It wouldn't be CopperheadOS anymore but rather something else, which might happen way down the road with proper Google Play integration but it's not planned and Google wouldn't currently be willing to license it under acceptable terms. Talk to Google about it, not us. |
thestinger
closed this
Nov 20, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Nov 20, 2016
Contributor
I get that security and usability are competing objectives, but please investigate a potential copperhead OS build including MicroG. It's not ideal that many apps have a Google Services dependency, but that's the reality of the ecosystem a lot of us depend on, and a free-as-in-freedom mockout of the Google Services API seems like a pragmatic compromise.
We're not even going to consider alternate builds with microG until they take security much more seriously. At that point, if there's funding for it, we may consider it. There isn't funding for it, so even if microG was much more robust it wouldn't be on the table. It's not a viable product, so it's not happening without people finding and providing the funding to us.
If this gets on the roadmap I think I'll stick with copperhead OS, donate, and recommend it to people. Otherwise, I'll probably end up grudgingly switching over to Cynogenmod. Obviously, it's your call, but I think the lack of easy support for this is going to turn away a lot of otherwise interested people-- it seems like an example of "perfect being the enemy of the good".
It's not going to be added to the roadmap. Plenty of people already donate to the project and recommend it to other people, without having to undertake a project of unrealistic size for them. I don't see the benefits of integrating microG into a build. It doesn't serve the needs of the niche that we are targeting. There's little indication that the project is going to shift to focusing on robustness/security and I don't think that we could ever have a product based on something essentially subject to the whims of Google since it depends upon private / undocumented APIs and hacks (the inappropriate signature spoofing stuff is just the tip of the iceberg). Parts of it could break at any time and it's held together by volunteers primarily interested in making it work. It's not suitable for what we want.
We're not even going to consider alternate builds with microG until they take security much more seriously. At that point, if there's funding for it, we may consider it. There isn't funding for it, so even if microG was much more robust it wouldn't be on the table. It's not a viable product, so it's not happening without people finding and providing the funding to us.
It's not going to be added to the roadmap. Plenty of people already donate to the project and recommend it to other people, without having to undertake a project of unrealistic size for them. I don't see the benefits of integrating microG into a build. It doesn't serve the needs of the niche that we are targeting. There's little indication that the project is going to shift to focusing on robustness/security and I don't think that we could ever have a product based on something essentially subject to the whims of Google since it depends upon private / undocumented APIs and hacks (the inappropriate signature spoofing stuff is just the tip of the iceberg). Parts of it could break at any time and it's held together by volunteers primarily interested in making it work. It's not suitable for what we want. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
NathanC
Nov 20, 2016
@thestinger Thanks for your reply (especially the second one explaining your reasoning about MicroG).
Could you make it clearer in the documentation/overview that there is fundamental incompatibility with Copperhead and OpenGApps/MicroG, and that there is no intention of supporting it? I understand your design decision, but people coming from other other ROMS usually expect to be able to flash OpenGApps (with an unlocked bootloader), and so it's probably going to continue to cause some confusion (see the other issues related to this).
For what it's worth, I think there might be a larger niche than you're expecting of people who are dissatisfied with CyanogenMod security who would be very interested in Copperhead, but who aren't willing to abandon the entire Google Services ecosystem. The inability to use a vast section of the Android ecosystem may alienate more people than you might expect, as it severely diminishes the functionality of the system. Security and usability are always tradeoffs, but decreasing usability so drastically has the effect of severely hampering adoption and so potentially hurting the overall push for security in the ecosystem. That being said the GApps licensing + MicroG spoofing are understandable problems, and I don't know what a clean solution would look like.
Again, I understand this is all your prerogative, and your security work is indeed very impressive-- but I hope you see where I'm coming from. I am reluctantly not going to use Copperhead for my main phone, but good luck with the project!
NathanC
commented
Nov 20, 2016
•
|
@thestinger Thanks for your reply (especially the second one explaining your reasoning about MicroG). Could you make it clearer in the documentation/overview that there is fundamental incompatibility with Copperhead and OpenGApps/MicroG, and that there is no intention of supporting it? I understand your design decision, but people coming from other other ROMS usually expect to be able to flash OpenGApps (with an unlocked bootloader), and so it's probably going to continue to cause some confusion (see the other issues related to this). For what it's worth, I think there might be a larger niche than you're expecting of people who are dissatisfied with CyanogenMod security who would be very interested in Copperhead, but who aren't willing to abandon the entire Google Services ecosystem. The inability to use a vast section of the Android ecosystem may alienate more people than you might expect, as it severely diminishes the functionality of the system. Security and usability are always tradeoffs, but decreasing usability so drastically has the effect of severely hampering adoption and so potentially hurting the overall push for security in the ecosystem. That being said the GApps licensing + MicroG spoofing are understandable problems, and I don't know what a clean solution would look like. Again, I understand this is all your prerogative, and your security work is indeed very impressive-- but I hope you see where I'm coming from. I am reluctantly not going to use Copperhead for my main phone, but good luck with the project! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
craftyguy
Nov 21, 2016
For what it's worth, here's an interesting blog post from the Tor folks about rolling a CopperheadOS build (with custom keys) that integrates OpenGapps: https://blog.torproject.org/blog/mission-improbable-hardening-android-security-and-privacy
Their project is here: https://github.com/mikeperry-tor/mission-improbable/
This isn't an attempt by me to convince anyone on the CopperheadOS team to integrate these components (I agree with your stance!), merely pointing it out for those folks who want to use these services on CopperheadOS.
craftyguy
commented
Nov 21, 2016
|
For what it's worth, here's an interesting blog post from the Tor folks about rolling a CopperheadOS build (with custom keys) that integrates OpenGapps: https://blog.torproject.org/blog/mission-improbable-hardening-android-security-and-privacy Their project is here: https://github.com/mikeperry-tor/mission-improbable/ This isn't an attempt by me to convince anyone on the CopperheadOS team to integrate these components (I agree with your stance!), merely pointing it out for those folks who want to use these services on CopperheadOS. |
NathanC commentedNov 20, 2016
I just installed Copperhead OS, and there are a lot of things about it that I really like. However, there are some basic applications that are deal breakers (e.g., Uber, better location determination with UnifiedNLP, etc).
I get that security and usability are competing objectives, but please investigate a potential copperhead OS build including MicroG. It's not ideal that many apps have a Google Services dependency, but that's the reality of the ecosystem a lot of us depend on, and a free-as-in-freedom mockout of the Google Services API seems like a pragmatic compromise.
If this gets on the roadmap I think I'll stick with copperhead OS, donate, and recommend it to people. Otherwise, I'll probably end up grudgingly switching over to Cynogenmod. Obviously, it's your call, but I think the lack of easy support for this is going to turn away a lot of otherwise interested people-- it seems like an example of "perfect being the enemy of the good".
(All that being said, great OS!)