Add standalone fido services #2183
Conversation
This allows users to use some microG services with non-system app
|
Hi @p1gp1g. Thanks for the PR. The idea is that apps that want to use We already used this model with wide success for the exposure notifications API in CCTG, see https://codeberg.org/corona-contact-tracing-germany/cwa-android |
|
Thanks for the reply. I've seen that you were recommended it, and I think that's a good solution. Nevertheless, some project just want to change While adding I think some app just want to avoid google proprietary blobs, and they just change the group of the import part. Maybe other project want to avoid some side effects. For instance, there was a crash that blocked Fennec to use it back in the days and with an external service it would have crash that service and not the client app. To resume:
|
|
I'd rather see any issues arising with the embedding of Given that the Fido service stores credentials (when using fingerprint unlock or soon-to-be-supported passkeys), it's important that users are aware of its existence and its purpose. An additional service app without any UI is not really helpful for this. Also, as @ale5000-git already mentions: everyone that can make use of this service could also just install and use regular microG services (as a user app and without the need for signature spoofing) and will have the same results. |
In many systems, the application with the identifier In a first time, I thought about adding the possibility to use microG Services as a regular user app with its proper id (see p1gp1g@895bae1).
|
I haven't encountered any system where it was not possible to install a package with the package name Applications that try to use I think I would generally be fine with allowing the use of the Android's package system is really not build for "library" or "service" packages. It might be suitable for you and some other power users, but not for the majority of the users. We already have enough users complaining because of ReVanced microG (a weird fork of microG only intended for using a patched YouTube app). |
GrapheneOS doesn't allow it at least. And there are some applications not using the original client library that will have side effects, like the mastodon application. [EDIT: but a working regular-app microG services will probably allow FCM push notif for mastodon then (BTW, a FOSS firebase-messaging may be something interesting to do, we already have FOSS code for clients)]
That was another reason I thought about in favor of a proper feature only service. I can edit that PR in this way if you want. |
|
What is the best order to check for the service ?
|
|
@mar-v-in
What do you think? |
|
This is a bit related to this. What do you think about providing a reimplementation of firebase-messaging ? Most of the proprietary blobs are already written and we already have foss client-side code. With microG version of firebase-messaging, org.microg.gms would be able to be used too. |
|
@ale5000-git The problem with your approach is that it doesn't cover updates. If we want to provide updates, we should do it through f-droid, but if we do it through f-droid (default or microG repository doesn't matter) it will confuse users that don't need it in any way. "microG User Services" and "microG Services" sound very similar, especially for people that don't speak English. @p1gp1g That's a very good question. The problem if we give I didn't know GrapheneOS does not allow installing packages with the name Regarding |
I think we can do some tests for this, if moving from self to gms changes something. The keys are stored on the TPM with uniq ids, and it may be able to use them even if we change the app requesting it.
I think too
That's on my todo list too, I'd be happy to work on this with you. For the FOSS library, I've done this already, and some projects already use it (nextcloud neon and schildichat) : https://github.com/UnifiedPush/android-foss_embedded_fcm_distributor/ |
With Passkeys, there is the need of auxiliary discovery data to be stored that can't go into the TPM, so this wouldn't be an option anymore soon.
The advantage of my idea is to actually use WebPush. FCM allows receiving push events via WebPush with VAPID natively, as does UnifiedPush and Web browsers, so as long as the pushing server supports WebPush with VAPID, it could send to all of them if there were client library supporting this usecase. WebPush by design does not require the server to be registered apriori to the push provider, instead registration happens through the client at push registration time (the app still needs to be registered for FCM though). This means that in decentralized environments (like Matrix, JMAP, XMPP) we don't need a centralized (per-app) proxy server to handle push notifications anymore, even if FCM compatibility is desired. And, if popular apps were to use this, people that don't use FCM can still have their push notifications delivered through other means via UnifiedPush. |
|
@mar-v-in For the name I'm not sure what name can be good but we may ask others to suggest.
I think that the first time the app is executed should detect what to use and store the value in their data so that even if another app with higher priority became available it keep using the one stored in settings (if it is still avaiable). |
Yes, that's probably a good option (not on first app execution, but on app first use of a certain API). And then we go with |
But in this case you may end up with having have the same app that use an API from base microG, a second API from user microG and a third API from self, it would be confusing. |
|
Yes, but some APIs might be not a good idea to ship with the app and should rather fail when used. e.g. if FIDO API is used with internal storage, you might want to still not use some other API with internal storage. I would hope and expect that users don't have microG Service and microG User Service installed at the same time (in fact we should display warning if they do), so it's only between self and shared service, and it's up to the app that embeds CCTG, for example, was showing a message in some details screen to let the user know if bundled |
|
We should also expect users that have a ROM with bundled microG (with custom signature); in case the ROM author no longer update the ROM (and doesn't give a way to update microG) then the user may want to use User microG instead. |
That's what I've in mind too. We may find another place for this discussion, what do you think ? :) |
|
@ale5000-git I think a different repository used only to hosts the user-microG builds is a good idea. We can also show a dialog to the user if the service is installed with id org.microg.gms and com.google.android.gms is installed on the system. |
|
Just to be more clear since my initial message was confusing before I edited it: |
|
An additional thing useful for debugging would be to provide a way to query the used service via adb (in every app using microG libraries), for example: |
|
What other feature may use self as fido/fido-core ? And how do you want to do your shell command ? Like a broadcast + logcat ? |
Most features that are actually useful could also be bundled as -core. Location, Maps, Nearby, ReCaptcha, Vision, Firebase, ... We don't have the code for most of them yet (and/or haven't tested it yet).
I once built a more complex solution for location. I'd like to not do that again. It means a lot of complexity that needs to be maintained (e.g. Google might change the APIs) and is always on a case-by-case basis. A generic solution based on the API connection doesn't have that issue, that's why I prefer if everythings works generic, even if this meant some minimal downside for users that change how they use microG APIs. Regarding shell command: I think that's a nice to have that we don't need to think about just yet. |
It is a low priority thing but I think broadcast could be easily parsed by a shell script on the PC compared to logcat. |
FWIW, I am convinced most of the confusion there stemmed from the way F-Droid (mis)handled packages with the same package name and would show UnifiedNLP (no GAPPS) instead of microG even when people had the microG repository enabled... It was an issue for years, and actual issues were filed about it, but somehow it kept being an issue for a long time anyway. I say this as an op in #microG (Libera and Matrix) too, where I've witnessed this confusion a number of times, and I really don't think it would have happened with a package that had another name, or with F-Droid handling the overlap better. |
https://f-droid.org/en/packages/com.google.android.gms it's solved now at least. There's still https://f-droid.org/en/packages/com.google.android.location/ and https://f-droid.org/en/packages/org.microg.nlp/ but that's unrelated. |
|
Closing, superseded by #2188 |
This PR gives user the ability to use FIDO services with applications using the microG FIDO library (
org.microg.gms:play-services-fido), like the Fennec browser, even if they don't have signature spoofing on their system.This PR allows users to use FIDO services with applications using the microG FIDO library (
org.microg.gms:play-services-fido), such as the Fennec browser, even if there is no signature spoofing on their system. Specifically, it will (finally) allow everyone to use non-discoverable FIDO credentials and physical security keys on Android.To achieve this:
org.microg.gms.fido.appas the additional allowed package for the FIDO requests.org.microg.gms.fido.app).To test it, you can use this demo application : https://github.com/p1gp1g/androidfido2demo . You need to use a system without microG, PlayService, or signature spoofing.
PS: This idea of obtaining user-installable services without signature spoofing, working with applications using microG libraries as a (drop-in) replacement for Google libraries, can perhaps be extended to other functions.