Remove Google Play Services dependency

[aartoni]

Google Play Services is closed-source non-free software, as stated by the Free Software Foundation:

If an app's own code is free software but it depends on Google Play Services, that app as a whole is effectively nonfree; it can't run on a free version of Android, such as Replicant.

As it may not be a problem for people having Google Play Services installed on their devices, this may have strong implications if the app were to be made mandatory, in fact it would risk creating a precedent for our state to forcedly require us citizens to install closed-source non-transparent software on their smartphones.

Moreover, Google Play Services is not available on recent Huawei and Honor devices if not through unofficial installation methods.

[macteo]

A/G framework is distributed by Google through the Google Play Services, so I don't think this is a feasible request.

[aartoni]

We can still avoid the issue either by not using A/G framework (e.g. reimplement it ourselves, use another framework) or by never making the app mandatory.

[francescotonini]

We can still avoid the issue either by not using A/G framework (e.g. reimplement it ourselves, use another framework) [...]

There are no equivalent frameworks since the API are provided by Google. I don't think that a reimplementation would be possible.

[...] or by never making the app obbligatory.

AFAIK the app won't be obligatory. You are free to not downloading it.

[aartoni]

Yes, as stated in the previous comments this issue only applies to the case where the app becomes mandatory, as this choice is not up to the developers it would be nice to have a plan in advance.

[mirh]

The issue is that there's not an alternative? Either you tinker with the original aosp framework yourself and ship it to phones (and try to be yourself the gatekeeper of good people and bad people) or you use this.

And if the app gets mandatory, I think you have a FAR worse problem (incompetence or malice, your pick) than just the app relying on GMS.

[vincenzoiovino]

There is another serious concern about this issue. Please confirm me if I am wrong. There are tons of phones without google play service, for instance Huawei phones(?). Can somebody knowledgeable in the field confirm that play services does not work on Huawei? From this statistics we know that 25% of Italian phones are Huawei: https://gs.statcounter.com/vendor-market-share/mobile/italy Many other phones may not support play services. Does this imply that your app will NOT work on such phones?

[francescotonini]

There is a common misconception that all Huawei and Honor phones doesn’t come or doesn’t have Google Play Services anymore. That is not true since only recent models being produced after the ban don’t have Google Play Services. Smartphones that have been available in the market before the ban still have Google Play Services and will always receive updates, hence they will be compatible with Immuni. You can find more details on Huawei’s website.

The market share value you are referring to consists of both compatible and non compatible phones.

That said, if the device doesn’t come with Google Play Services you won’t be able to use Immuni since the technology provided by Google is shipped inside Google Play Services. However, I don’t recall other brands than Huawei and Honor that sell smartphones in Italy without Google Play Services. In fact, I think the number of devices without Play Services is very small compared to the whole market. Correct me if I am wrong.

[vincenzoiovino]

There is a common misconception that all Huawei and Honor phones doesn’t come or doesn’t have Google Play Services anymore. That is not true since only recent models being produced after the ban don’t have Google Play Services. Smartphones that have been available in the market before the ban still have Google Play Services and will always receive updates, hence they will be compatible with Immuni. You can find more details on Huawei’s website.

The market share value you are referring to consists of both compatible and non compatible phones.

That said, if the device doesn’t come with Google Play Services you won’t be able to use Immuni since the technology provided by Google is shipped inside Google Play Services. However, I don’t recall other brands than Huawei and Honor that sell smartphones in Italy without Google Play Services. In fact, I think the number of devices without Play Services is very small compared to the whole market. Correct me if I am wrong.

Ok so you confirm that instead all new Huawei phones will not work with Immuni. In the near future, people will switch to new phones so in the near future the percentage of "people with Huawei phones without play service" will equal the percentage of "people with any Huawei phone". So the situation does not change a lot. I personally switched recently to a new phone without play service.

Do you have an estimate of the percentage of phones in Italy that do not have play services and so will not work with Immuni? Do you have an estimate of the percentage of phones in Italy that, let us say, in one year, will not have play service and will not work with Immuni?

Did you communicate to the authorities such big issue that further demotes the epidemiological performances of Immuni?

(when I say "you" I do not refer to the user I am replying to but to the Immuni's Team)

[lmasellis]

I agree that it is not acceptable to depend entirely on closed source APIs from Apple & Google, which would limit the user base, create an unjustified commercial prejudice for phone manufacturers not approved by Google, discrimitate users of open source ROMs (e.g. AOSP derived) and entrust private foreign entities, such A&G, with undue powers.

A compromise solution could be found in a double protocol implementation: A&G (requiring GMS) and DP3T (not requiring GMS). The user could have the choice to choose which one to use: the former (for better performance on A&G devices) or the latter (when use of GMS is not desired by the user or not possible on the device).

This approach would imply establishing an interoperability mechanism between the two protocols, which however is needed anyway to detect exposure of cross-border travellers (see issue #30 ).

[mirh]

DP3T is the "data collection scheme". In a possibly rough comparison, I think it would at best fit the application layer, but it is something all on paper.

"A&G" is the actual API that gives you ~wide access in the OS to the bluetooth hardware. If we were in 2012, yeah, you don't need anybody permissions on a stock OS to do what you want. Because everything is always allowed. Unfortunately, you know, people had petty complaints about privacy and security, therefore there are tons of background activity restrictions now. It's already a miracle that they could themselves retrofit this for older phones to be honest.

I agree that it is not acceptable to depend entirely on closed source APIs from Apple

You mean their entire operating system? I agree supporting such toy is a sham, still epidemiology demands not to hold grudges now.

[lmasellis]

DP3T is the "data collection scheme".

DP3T as of now is not just a "scheme". It is a fully functional ensemble of protocol, backend and apps and does not rely on A&G exposure tracking APIs.

https://github.com/DP-3T

By the way, it has been adopted by Swiss government (hint: CH is neighbouring to Italy, and is the country with the highest traffic of trans-border workers; sharing the same system would be a smart idea).

I agree that it is not acceptable to depend entirely on closed source APIs from Apple

You mean their entire operating system?

Google Play Services ≠ Android ≠ AOSP

[mirh]

It is a fully functional ensemble of protocol, backend and apps and does not rely on A&G exposure tracking APIs.

https://github.com/DP-3T/dp3t-sdk-android#introduction Come on.

Google Play Services ≠ Android ≠ AOSP

I referenced nothing of that.

[lmasellis]

It is a fully functional ensemble of protocol, backend and apps and does not rely on A&G exposure tracking APIs.

https://github.com/DP-3T/dp3t-sdk-android#introduction Come on.

Supporting A&G APIs does not imply relying exclusively on them.

[lmasellis]

Google Play Services ≠ Android ≠ AOSP

I referenced nothing of that.

The subject of this issue is dependency on Google Play Services. You mentioned "operating system", and Google Play Services is not an OS.

[aartoni]

I'm closing this issue because it is now unlikely for the government to make the app mandatory, and because the discussion moved to a different topic.

This article states that Google is willing to publish a guide for replicating the "A&G" APIs:

For those phones, Google intends to publish a framework that those companies could use to replicate the secure, anonymous tracking system developed by Google and Apple. It will then be up to Huawei, Xiaomi, and other Chinese manufacturers (or the Chinese government) to decide whether to use the system.

[lmasellis]

I'm closing this issue because it is now unlikely for the government to make the app mandatory, and because the discussion moved to a different topic.

This article states that Google is willing to publish a guide for replicating the "A&G" APIs:

For those phones, Google intends to publish a framework that those companies could use to replicate the secure, anonymous tracking system developed by Google and Apple. It will then be up to Huawei, Xiaomi, and other Chinese manufacturers (or the Chinese government) to decide whether to use the system.

Definitely not in agreement with closure of this issue. The referenced article is not an authoritative source for Google's position on the issue; even if it was, the article does not address the question whether Immuni app & backend will support mobile platforms other than Google's and Apple's; nor it does address dependency of open source software on closed source components (as Google Play Services). Please reopen.

[HellPie]

the article does not address the question whether Immuni app & backend will support mobile platforms other than Google's and Apple's

I don't think there is a need to specify this.

The Immuni API is openly documented in this projects and uses no OS-specific authentication or authorization system which solves the issue with uploading TEKs. The only quirk is Protobuf, used for downloading the infected TEKs, but the official Protobuf code is open source, the standard is publically documented and there are >plenty >of >implementations (and even more official and non official libraries if you search online) for all the most used low and high level languages. Google and Apple also both document the protobuf file required to parse the binary data containing the TEKs and the signatures (Google also has a PDF with the same spec) so the entirety of the TEK download procedure can in fact also be replicated.

Exposure Notification Framework, finally, is openly documented including the specs for the encrypted RPI metadata. >Several >projects >have >been >implemented replicating the Exposure Notification protocol for other systems on GitHub. This proves Exposure Notification's Bluetooth and Encryption details are fully and openly documented which solves the issue with the client-side part of the implementation, which can therefore also be ported to other systems.

the referenced article is not an authoritative source for Google's position on the issue

it does not address dependency of open source software on closed source components (as Google Play Services)

There is no need to question whether or not the implementation should rely on closed source components if you spend just a few minutes researching. The reliance on the system-provided (in Android's specific case provided the Google Play Services system app) Exposure Notification Framework APIs are constrained by additional Terms of Services for both Android and Apple which force the app to be published specifically only through the platform's official stores, such as the App Store for Apple devices and the Google Play Store for Android devices, effectively accepting Terms of Service for those platforms. Furthermore, the communication with Google Play Services, regardless of the API used, requires the reliance on the appropriate Google Play Framework dependencies due to the complexity of the communication system as well as other technical challenges that would be impossible to overcome otherwise (most of the classes are minified for space reasons so most of the code is almost impossible to read and program with and on top of that the Inter-Process Communication protocol that allows apps to call into Google Play Services APIs is not provided by Android's official system APIs so it must be provided to the app in the form of an external dependency).

If your gripe is with the Exposure Notification Framework implementation being closed source, locked inside a closed source component which is nearly impossible to reverse engineer successfully then I am 100% with you and I truly despise Google for not even considering releasing it as a Chimera module (the internal name for dynamically loaded Google Play Framework modules) and open sourcing it specifically, but this is something that should be discussed directly with Google as neither the Government or Bending Spoons (and I want to make it very clear that I am NOT affiliated with either of them or Google/Apple in any way and I do not support the decisions they took so far regarding Immuni) have powers over how the system is implemented. The decision to use it is the only thing they can control but the drawbacks and limitations of both Android and iOS force the reliance on system-provided implementations, otherwise it will result in either permanet battery life shortening or flawed, unreliable communication as it was already discussed by almost every single system, including those who still did not decide to rely on Exposure Notification Framework APIs.

I hope this answers most of people's concerns and finally puts an end to this senseless dead horse beating. While I understand not everyone is a developer and not every developer knows the ins and outs of mobile systems, this personally feels like an Issue opened for a purely pedantic argument that could easily be answered by simply researching online and reading the official Apple/Google documentation.

[lmasellis]

Practical demonstration of how one can spend a lot of words to say actually nothing.

[echeoquehaii]

While it might be indeed true that the market share of phones without Google Play Services Framework might be very low, this doesn't imply that the app NEEDS to rely on it. As a pure example, the Norwegian COVID tracing app dosen't rely on Play Services, can be downloaded directly from the Health Ministry webpage and works flawlessly. This means that the decision of making the app dependant on the A/G Framework is purely political and based on the agreements made with such companies, but is not at all necessary for the functioning of the app.

The problem with saying that the number of people not having Play Services is very low is that it shows complete disrespect for such people. It might not be relevant from a statistical point of view for the aggregate data and epidemics control, but it is FUNDAMENTAL that people are given the right and means to know if they have been in contact with any infected person. I, as an individual, take care of my health and try to protect myself and my own family and social circle from getting the virus. The government's sponsored app doesn't allow me to do that because of political reasons.

I AM DISGUSTED and VERY VERY ANGRY, also by the disrespect and superficiality showed by the replies of some users and developers.

[echeoquehaii]

If your gripe is with the Exposure Notification Framework implementation being closed source, locked inside a closed source component which is nearly impossible to reverse engineer successfully then I am 100% with you and I truly despise Google for not even considering releasing it as a Chimera module (the internal name for dynamically loaded Google Play Framework modules) and open sourcing it specifically, but this is something that should be discussed directly with Google as neither the Government or Bending Spoons (and I want to make it very clear that I am NOT affiliated with either of them or Google/Apple in any way and I do not support the decisions they took so far regarding Immuni) have powers over how the system is implemented. The decision to use it is the only thing they can control but the drawbacks and limitations of both Android and iOS force the reliance on system-provided implementations, otherwise it will result in either permanet battery life shortening or flawed, unreliable communication as it was already discussed by almost every single system, including those who still did not decide to rely on Exposure Notification Framework APIs.

So, any implementation of a tracing app that follows the PEPP-PT guidelines is not possible due to the limitations of Android and Apple systems, without incurring in battery draining issues and unreliable communication? There is no way at all? If this would be true that means that any government in the world is not be able (or willing to?) to obtain any guarantees and standards from IT companies, on issues like this which are of major national interest. That would be really really worrying, much more than I thought.

The Exposure Notification Framework API should at least be allowed to be installed separately, instead of being incorporated in the Google Play Services Framework so that people could install it also on other systems which don't get the Play Services update. Or, why not open sourcing the Framework and let anyone implement it in their apps?