lbschenkel @Proxima: before you waste a lot of time doing this experiment, actually try something else first. Open the app properties for MitID and enable the switch named Exploit protection compatibility mode. Make sure to force close the app and try activating again.

I have done that in a new profile and the error no longer showed up for me. Hopefully it will do it for you as well, and then it's good news as we do have a workaround to keep MitID working and they didn't decide (yet) to pull the trigger on Play Integrity.

Can both you and @MentalM try this and report back?

    lbschenkel Sorry to say, now I can't get past the face recognition state, the APP just crashes and every thing else I have tried don't work either.

      Proxima OK, I want to confirm that you have done this:

      1. Uninstalled the app (*)
      2. Installed the app again, but did not open it (*)
      3. Opened the app info and enabled the switch Exploit protection compatibility mode
      4. Opened the app and went through the motion of scanning the document

      At least for me, I was able to do it once I have done the above. The error mentioning that the device is "rooted or compromised" no longer shows up at the final activation step.

      (*) Reason for this is because I saw in the logs for my MitID account mentioning of "permanently blocking the installation" when I've done the failing experiment, so better to start fresh with a new installation.

        lbschenkel When I switched off Exploit protection compatibility mode. I was again able to get to the error message.

        Every time I make a try, I force stop the APP, Clear cache, Re-install the APP, first then I turned on the Exploit compatibility mode.

          Proxima All right. Well, it's weird. We'll need to wait for other GOS users to try and chime in.

          P.S.: You didn't use the word "uninstall" but "re-install". In case you didn't uninstall the app, please make sure you did that just to eliminate all doubt.

            Proxima Thanks for that. The wording strongly implies that they decided to use Play Integrity for new activations since June 12. But then again, how did it work on my device after setting the compatibility options? Was it a fluke?

            We will need other reporters to get a complete picture of what is the situation. The complication now that the check is at the time of activation is that we need local users to test, as they need to scan their documents and to have a CPR number. Before, since the app checked at launch, anyone could install and launch and verify if it was working.

            I may try again with my device but I'm a bit wary to do it because I'm actually doing activations and revoking them and this is tied to my real identity, and who knows if that might trigger some anti-fraud algorithms.

            Actually I retract my statement that it works, I think it was a fluke. I tried once more in a new profile, with Play Services, with secure app spawning turned off and the exploit protection compatibility settings turned on, and I am seeing the "rooted or compromised" message at the final step of the activation flow.

            I am convinced that they implemented Play Integrity and it is game over for MitID with GrapheneOS. The lucky ones who managed to activate before June are on borrowed time.

              lbschenkel with secure app spawning turned off and the exploit protection compatibility settings turned on

              I am not at liberty to test the activation, as I'm not a Danish citizen. But I notice that this guide mentions trying with both secure app spawning and exploit protection compatibility mode disabled; then reboot the device before launching the app.

              Obviously this will make no difference if the app decided to actually implement Play Integrity. But if anyone has the opportunity, perhaps it is worth trying before making that conclusion?

                fid02 I spent some time checking all the combinations (plus rebooting between tries). Nothing worked. That is what convinced me that it cannot be made to work, and it is Play Integrity at play (pardon the pun), especially given their own announcement where they are claiming that the app now only activates if Google doesn't consider your device "compromised" (= Play Integrity).

                Nothing would make me more happy than to be proven wrong, though.

                  • Edited

                  lbschenkel In other words, unless users manage to convince MitId to either drop Play Integrity, or implement attestation, it sounds like the end of the road for MitId on GrapheneOS. I'm sorry to hear it. Although I don't use the app myself, I have read this entire thread before, and want to say I appreciate all the work you have done – and are still doing – on this matter.

                  Is there a way to infer from the app logs – or from the Play Services app logs – that Play Integrity is at play here? Or perhaps the checks are all done server side?

                    fid02 It most likely is Play Integrity. Below are logs when I tried installing in a new profile

                    --------- switch to main
                    06-24 11:01:18.079 6162 6162 W WindowOnBackDispatcher: sendCancelIfRunning: isInProgress=falsecallback=android.view.ViewRootImpl$$ExternalSyntheticLambda11@f1811b0
                    06-24 11:01:39.909 6162 6248 I dk.mitid.app.android: Explicit concurrent mark compact GC freed 10MB AllocSpace bytes, 170(46MB) LOS objects, 75% free, 21MB/87MB, paused 230us,860us total 71.399ms
                    06-24 11:01:39.959 6162 6248 I PlayCore: UID: [10150] PID: [6162] IntegrityService : requestIntegrityToken(IntegrityTokenRequest{nonce=REDACTED, cloudProjectNumber=null})
                    06-24 11:01:39.961 6162 6971 I PlayCore: UID: [10150] PID: [6162] IntegrityService : Initiate binding to the service.
                    06-24 11:01:39.974 6162 6162 I PlayCore: UID: [10150] PID: [6162] IntegrityService : ServiceConnectionImpl.onServiceConnected(ComponentInfo{com.android.vending/com.google.android.finsky.integrityservice.IntegrityService})
                    06-24 11:01:39.975 6162 6971 I PlayCore: UID: [10150] PID: [6162] IntegrityService : linkToDeath
                    06-24 11:01:41.235 6162 6191 I PlayCore: UID: [10150] PID: [6162] OnRequestIntegrityTokenCallback : onRequestIntegrityToken
                    06-24 11:01:41.235 6162 6971 I PlayCore: UID: [10150] PID: [6162] IntegrityService : Unbind from service.
                    06-24 11:01:41.498 6162 6248 W FirebaseCrashlytics: A null value was passed to recordException. Ignoring.
                    06-24 11:01:41.617 6162 6996 D TrafficStats: tagSocket(115) with statsTag=0xffffffff, statsUid=-1
                    --------- switch to events
                    06-24 11:01:45.820 6162 6162 I view_enqueue_input_event: [eventType=Motion - Cancel,action=dk.mitid.app.android/dk.mitid.app.android.activity.MainActivity]
                    06-24 11:01:45.822 6162 6162 I wm_on_top_resumed_lost_called: [Token=REDACTED,Component Name=dk.mitid.app.android.activity.MainActivity,Reason=topStateChangedWhenResumed]
                    06-24 11:01:46.500 6162 6162 I wm_on_paused_called: [Token=REDACTED,Component Name=dk.mitid.app.android.activity.MainActivity,Reason=performPause,time=1ms]
                    --------- switch to main
                    06-24 11:01:46.501 6162 6162 D VRI[MainActivity]: visibilityChanged oldVisibility=true newVisibility=false
                    --------- switch to events
                    06-24 11:01:46.525 6162 6162 I viewroot_draw_event: [window=VRI[MainActivity],event=Not drawing due to not visible]
                    06-24 11:01:46.535 6162 6162 I wm_on_stop_called: [Token=REDACTED,Component Name=dk.mitid.app.android.activity.MainActivity,Reason=STOP_ACTIVITY_ITEM,time=3ms]

                      4 days later

                      lbschenkel Hi, I am back in DK, after a long (wedding week) abroad, where I did not have time to 'play around'with phones and such. I can read here, that unfortunately there has been a bad new 'rule' put in place by the masters of MitID. I did update to the latest stabel GOS and rebooted and all. Yet, I had my 'DK user´, the user that handles the DK apps, being random at granting internet access to the apps. Some had access, like my bank, but eBoks and Easypark did not. After some browsing around here and on my phone, i decided to reinstall GPS (google mirror)... and Voila.. both eBoks and Easypark have connection again. I am now in the process of waiting (1 hour) to copy my MitID to a second device, as that is now possible after 1 hour of waiting. So I will report back when I can do - or fail at installing MitID in that manor.

                      Unfortunately I get the same screen after copying from my other phone to the new GOS phone. Well, I have the code display and my old phone still, so no real loss.. Lets see if there is a new future for this app in 2025... or later.. New GOS users from Denmark, get a Code Display (for free) before deleting your old phone/Device with MitID on it.
                      Thank you lbschenkel, proxima and fido2 and all other in trying to get to the bottom of this issue... yes.. we have reached the bottom.... :(

                      fid02 Grooty I took the easy way out and wrote their support. I have made a translated summary here (their email reply contains a whole lot of Google marketing, that I have filtered out):

                      We use Google Play Integrity on Android and Apple Integrity Assertion on iOS, to ensure that users are not using "false apps" that masquerade as MitID, and that the app is downloaded from an official store. We provide them the code and limited backend access, in order for them to verify that the app binary is legitimate. This is not a kind of scam that is currently being employed, but we want to stay ahead of the threat.

                      I initially asked them why they went the Google Play Integrity way, and not things like hardware attestation, but I got most of the relevant information for this thread.

                      Does anyone know of a way, to achieve the same as what they set out to do, but via hardware attestation instead? It sounds like they are trying to solve the following:

                      1. Verify the operating system
                      2. Verify the app binary is legitimate
                      3. Verify that the app is downloaded from Google Play Store, and not somewhere else

                      If so, I wouldn't mind forwarding them that information, and see if I can change their minds about the implementation.

                        Apathy Does anyone know of a way, to achieve the same as what they set out to do, but via hardware attestation instead?

                        https://grapheneos.org/articles/attestation-compatibility-guide

                        Though it is not clear to me why they should require that the app is installed from exactly one app store. Isn't the EU compelling Apple to support multiple app stores?

                          de0u I believe they're trying to avoid users having a version that's installed from other sources, as that's a dead giveaway for a fake app. I know that there's other legitimate app stores out there, so I'll try to convince them of a whitelist approach instead of only Google Play; whole thing is pretty ridiculous, since that field can easily be spoofed.