First time GOS user here (Pixel 6a).
I have tried to activate MP on my new device. GPS installed. MitID working fine.
When MP wants me to authenticate via MitID, I get an error (Teknisk fejl, prøv igen senere).
This has been the situation for a couple of days.

Are there any steps, I have overlooked? I understand, that MP is working under GOS.

    Owg UPDATE:
    I contacted the MP support, and currently there is a situation, where some Android phones are not allowed to authenticate.

      Marking as off-topic due to it likely being an issue with the app and not the OS.

      Regardless, please keep us in the loop about this so that people in the future can refer back to this thread.

      The solution is to install Google Chrome, as the verification with MitID, doesn't play along with Vanadium at this time.

      14 days later
      6 months later

      CutStandard8309

      How did you get that working? When I try, I get to the MitID login page and, depending on authentication method, it either gets stuck after entering OTP or goes back to Mobilepay app after authentication which then gives an error.

        sup3rior did you manage to fix the issue? ive tried downloading chrome and brave, nothing worked

        SOLUTION AS OF 16/12/2023: Download version 5.26.0 of mobilepay (I used aptoide to do so), have chrome or brave installed & set as standard webbrowser, then login as before. MitID will work and you can login and update MobilePay to the latest version using aurora store or play store, if you want.

        If you try to do this using a newer version (5.27 or above) it simply wont work since vanadium (I assume) doesnt give all the info that MitID wants/needs so it will just throw you an error every single time you try to login. and for whatever reason, you cannot change custom tabs in mobilepay, it will just keep using vanadium (at least in my experience)

          donovxn version 5.26.0 doesnt work at all . you cant even get past the home login screen. 5.26.1 can get you all the way to MitID, but it will still be using Vanadium, resulting in MobilePay waiting endlessly for a response after you have authenticated in MitId. Opening the MitId login screen in Brave doesnt work either, because it seems like the whole login is dependent on a cookie, which will not be present in the Brave instance.

            Engroad

            Yeah, same here. 5.26.0 just returns to start screen with an error message after entering mobile number and CPR. Just guessing, but since it's sitting around waiting for response, I'm wondering if it's some of the hardening features of Vanadium that's causing it to not be able to progress. Not sure how to properly diagnose that though.

              sup3rior "I'm wondering if it's some of the hardening features of Vanadium that's causing it to not be able to progress."

              it sort of is, but its MobilePay blocking these things for no reason, even tho they dont give additional security to the MobilePay app (https://github.com/GrapheneOS/Vanadium/issues/421)

              I suggest you write a long email to them, since you wont be able to get the app working now as there is no fix. (AFAIK)

                Hey @GrapheneOS, just one idea for you to consider.

                First off, let me say we are all in agreement that many important apps (many would even say essential) in Denmark are very finicky and don't work in GrapheneOS due to a lot of security theater bullshit. That's on them, that's not GrapheneOS' fault.

                But being realistic, whoever lives in Denmark cannot avoid these apps. Maybe some, almost certainly not all. It's just how the government/society is set up. What's going to happen is either:

                • they need to use some workarounds, such as different browsers (or worse: making them the default)
                • they stop using GrapheneOS

                In both of these scenarios, the user privacy is greatly compromised compared if they could stay using the option provided by GOS. Even though GOS made the right technical choice, it didn't really help the user since they're forced to use something else instead which is much worse for them.

                Now, here comes the suggestion for you to think about. What if Vanadium offered the choice to relax the "header hardening" setting (for the lack of a better expression) on a per-domain basis? This could be an expert setting that is very hidden (like tap 5 times somewhere) so you can't just stumble upon it, but if you really need it like the users in this thread, then you could enter the particular problematic domains, and then it would solve the issue for these users. No need to even allow disabling on a global basis.

                Sure, this compromises privacy for these domains, but it's going to be compromised anyway because the users here are forced to install Chrome or something else. And worse, make those the default browser which ends up affecting everything else. With the suggestion above, they could relax the headers just for mitid.dk, and mobilepay.dk (or whatever other domain they need) with a much lesser privacy risk, as they can continue to use a hardened browser for their daily needs with the full protection that it brings.

                You may have considered this already, I don't know. But I wanted to put this suggestion out there because it may be a good compromise, as it solves the immediate Danish users' needs, and they will also come less often here to vent. :-)

                  lbschenkel It might not be hard for somebody to build a browser which would be exactly Vanadium plus the silly headers (maybe call it Scandinavium?). Then maybe some journalist could write a piece about how silly the situation is (or maybe one journalist per country plus Ars Technica?), and maybe the silly people might be shamed into being less silly? Then the project could fold.

                  Adding code to Vanadium to put back those headers, plus UI and preference code to conditionalize on domains, wouldn't be impossible, but it would be work, and that work wouldn't be pro-security or pro-privacy.

                  Please note that I don't speak for the GrapheneOS project.

                    de0u

                    Adding code to Vanadium to put back those headers, plus UI and preference code to conditionalize on domains, wouldn't be impossible, but it would be work, and that work wouldn't be pro-security or pro-privacy.

                    Absolutely, I completely agree. It's the biggest drawback of my proposal: it's work. I'm aware that UI preference code needs to maintained, plus I'm not sure how easy it is to make the header behaviour work differently on a per-domain basis.

                    I was hoping that all the necessary hooks are in place and it would be a low-hanging fruit, so to speak. If it's not too much work it could become appealing in terms of work/reward ("reward" in terms of sucking less).

                    Maybe even without UI, to reduce the work and stress this is not really an advertised user-facing feature. Drop a list of domains in a magic JSON file in a specific directory in /sdcard. :-)

                    It might not be hard for somebody to build a browser which would be exactly Vanadium plus the silly headers (maybe call it Scandinavium?).

                    This could also be viable. The potential problem is that another browser will not be GOS' WebView component. Depending on what the app is doing, it might rely on WebView instead of opening a custom tab of the default browser.

                    Then maybe some journalist could write a piece about how silly the situation is (or maybe one journalist per country plus Ars Technica?), and maybe the silly people might be shamed into being less silly?

                    That would be the best outcome all around. These companies only change if a decision-maker is embarrassed. I have personally worked in a number of Danish companies in this domain (financial/authentication sector), and they're absolutely not going to care about a niche OS used by few people that have a specific phone and have wiped it to install another one.

                    Because I know that this is the reality, I don't hold my breath for them to changing their ways in a timescale that is less than years, at least in the absence of some event that forces their hand.

                      8 days later

                      donovxn

                      I'm wondering if this is more MitID-related, as I've now also run into the same issue with both my danish banking app (Lunar) and E-boks app, both failing to authenticate with MitID.
                      It might very well be that all three are doing it the same way and that's why it's failing, but it could also be on the idp side (meaning MitID) that doesn't play well with Vanadium as it seems to be some type of session cookie that doesn't get passed along. Wishing MitID had gone the route of the swedish BankID where the authentication process takes place in the back-end and the app doesn't need to interact with the authenticator in the authenticating session.

                      At least with Lunar, they are actively looking into it, but I've also purposefully called my OS Android 14, which is not untrue. Mobilepay is probably a dead-end from the experience of others, but I'm still wondering how you got it to work. When I did the same as you described (downloaded the older version, installed Chrome and set it as default), it still failed on me.

                        I got MP working with with MitID, by completely uninstalling Vanadium, then installing Brave (I would think Chrome works too), and then going through the Auth process. Otherwise it would it keep using Vanadium, even though another browser was selected as default. Afterwards I installed Vanadium again. All my danish banking, government and Auth apps work fine for now.

                          Johnmhm

                          I'm guessing it's because Mobilepay uses WebView, which will always default to Vanadium if installed afaik. But I'll give your suggestion a shot right away.