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.

                      @Johnmhm

                      That actually worked. Although, not un-installing, as that didn't seem to be a straight-forward option, but disabling it, setting Chrome as default and then activating Mobilepay worked. Same for Lunar Bank and E-boks. Enabled Vanadium afterwards and changed default browser back, all apps still working.
                      So it sounds like either something in those apps interaction with the idp (Criipto) in the session or in their checks of the browser being used.

                      lbschenkel No, GrapheneOS is not breaking compatibility by removing optional new headers providing OS and device model information. This app is deliberately trying to break support for anything but Chrome. It does not make sense to offer a toggle in this case. The app developers need to fix their broken code. We aren't going to maintain a new feature for working around a single broken app that's purposely disallowing people from using Vanadium. You should pressure them to fix it. We will not add OS and device model info back to the headers. It's not reasonable for a site to break compatibility because the browser isn't giving it that info or fake information about it.

                        de0u They're deliberately trying to break support for using browsers other than Chrome, Safari or other browsers they support by checking assorted things to see if they match. This isn't a compatibility issue but rather a company trying to disallow people from using other browsers. They should be pressured to either stop doing this security theater or to add Vanadium to the list of what they hard-wire as permitted.

                        lbschenkel It doesn't make sense and isn't being added. This app needs to stop people disallowing using alternate browsers for alternate browsers to work with it consistently. They're going out of the way to try to detect and disallow using alternate browsers. Adding toggles for this isn't a solution. They could detect it based on anything that's changed which is visible to sites, not only this. They need to stop deliberately breaking their app and site.

                        MitID has repeatedly deliberately broken their app with alternate operating systems and then fixed it. This is the same nonsense. We've never done anything to work around it and never will. It's on them to stop doing this. They know they're causing the problem and need to stop causing it. Users need to put pressure on them, not us.

                        If we worked around what they're doing, it would only encourage them to keep doing nonsense like this, and would be counterproductive. It would lead to them blaming us for their problems and refusing to fix them in the future. Therefore, we have a hard rule against working around the issues this app / app ecosystem are deliberately causing. They've previously wrongly tried to blame GrapheneOS and would leverage us working around their nonsense as an excuse to not fix it.

                        lbschenkel

                        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.

                        If an app uses the WebView, changing the default browser or disabling the Vanadium browser won't make any difference.

                        sup3rior MitID needs to stop deliberately disallowing alternate operating systems and browsers. It will be consistently problematic until they stop, and we have a hard rule to avoid working around it due to their dishonest behavior trying to blame GrapheneOS for them deliberately trying to break alternate operating systems. You must pressure them to fix this, not us. They've broken it deliberately, not by accident. It's not an accident that they're trying to detect and disallow alternate browsers.

                          sup3rior You're incorrect. It's not possible to use another WebView implementation, and disabling the Vanadium browser will not disable the Vanadium WebView. Disabling the Vanadium WebView would leave you with no WebView and would cause many apps to crash. That is not what's happening.

                            GrapheneOS

                            I agree, and my apologies if it came off as anything else. It is not on your end and I know very well that the ones making these choices at MitID are to blame. Unfortunately for us that has to interact with Danish authorities, they have a monopoly and can do as they please, just as their predecessors did with NemID.

                            GrapheneOS

                            Well, then I have no explanation. Just installing Chrome and setting it as default didn't do the trick, but once I disabled Vanadium it did. But again, not your headache, this is on us to chase the responsible politicians for them to put pressure on MitID.