LibreWolf is a great privacy oriented Browser for desktop. But there is no version for android or IOS . There are some like mull but they have their own problems. Mobile phones stay with us most of the day. So we need extra privacy for it.

  • Skull giver@popplesburger.hilciferous.nl
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 month ago

    If a third part web browser “bypasses or cripples” OS sandboxing, then any app can. Seems like Graphene’s hardening isn’t very good for third party apps in that case.

    Firefox doesn’t use Android’s API for sandboxing processes from each other, but that sandboxing isn’t what’s protecting your phone from getting taken over. There are many layers of security present within Android and process isolation for web content is just one of them.

    I’m sure Graphene’s fork of Chrome is more secure than Firefox (especially with JIT turned off) but that doesn’t mean running Firefox presents any risk.

    Android’s design is such that I should be able to install a random app and see no adverse effects other than battery drain/high network load without clicking through dozens of security prompts. If that’s not the case, there’s a vulnerability in the Android layer that needs patching, such as the Qualcomm vulnerability that was released recently.

    With open security holes like that, not even Chrome’s site isolation is going to protect you

    • circuscritic@lemmy.ca
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      1 month ago

      Right, so if Gecko based browsers can cause that kind of security concern on Graphene, what does that mean for people using Android ROMs that are not hardened, or, OEM variants that do not receive regular security updates?

      Any app installed by a user that takes advantage of an active and unpatched CVE, can do all sorts of actions to compromise an entire phone, or critical parts of it. Are you saying that’s not the case?

      The difference between a compromised app, and a browser, is that even a “safe” Firefox install is used to browse a near infinite possibility of websites, any number of which might be running an active campaign targeting unpatched Android vulnerabilities.

      It sounds like you’re saying that despite Firefox Geckos significantly larger attack surface, the fact that Chromium doesn’t eliminate all risk, means there’s no difference.

      • Skull giver@popplesburger.hilciferous.nl
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        1 month ago

        I still don’t really see what “that kind of security concern” is in this context. Same-site isolation protects two websites from each other, nothing more. The isolation API Chromium uses to drop permissions on some of its threads are used to limit the potential of a single exploit, but they don’t prevent things like the Qualcomm vulnerability from being abused.

        It’s not like any website can just break a web browser, they need to exploit the browser in the first place.

        For unpatched people, that means they’re in trouble. Luckily, Android is so fragmented that there is no exploit that’ll get root access on all devices. It’s hard to even get root access on the same model of phone. In practice, drive-by malware is actually quite rare for how many unpatched Android phone are out there.

        There is probably more risk in using Firefox than there is in using Chromium, but the additional protections here are quite overstated in my opinion. You can’t get enough layers of defence when you’re a human rights activist or whatever (but then you’d use an iPhone in lockdown mode anyway), but just because Firefox doesn’t implement a particular API doesn’t mean your phone can be taken over by any website you visit. You need a complex chain of exploits directly targeting your phone’s hardware and software configuration to get anything more than a force closed browser tab.

        As for the attack surface, Chromium implements a significantly larger API and provides a significantly larger attack surface, with permissions and code to do things like access USB drives and open serial ports. I’d say the huge chunk of Chromium-only browser features leave Chromium with a larger attack surface, not a smaller one.

        I personally prefer the additional privacy improvements Firefox brings over the two layers of malware protection that patched versions of Chromium provide. I’m no Khashoggi and I don’t work on any nuclear plants, I’ll probably be Fine™️ and so will you.

        • circuscritic@lemmy.ca
          link
          fedilink
          English
          arrow-up
          0
          ·
          edit-2
          1 month ago

          It’s like you’re arguing because you like to argue, and can’t admit that you’re wrong. So you keep finding new ways to qualify your response in the hopes that I forget what this is even about.

          Chromium is significantly more secure than Firefox Gecko on Android. That is according to the developers of probably the two most well regarded hardened Android ROMs.

          One of which, Graphene, even advises completely avoiding Gecko based browsers.

          Which is what I said in my original comment, well, the part about relative security.

          You’ve also claimed that at most, a malicious android application can only harm battery life and cause network issues, which is objectively false. I’m honestly kind of confused why you even said that, but whatever.

          I never said no one should use Firefox based browsers on Android, I just said they weren’t as secure and that user should understand the risks associated with them.

          But what I’m most confused and perplexed by, is your insistence that only high risk individuals should be concerned with using a browser that comes with, at minimum, double the attack service they’re exposed to when browsing the web.

          Again, that is per the GrapheneOS wiki/FAQ.

          I mean, we’re not talking about some hardcore and incredibly inconvenient levels of unnecessary OPSEC for the sake of OPSEC, we’re talking about a browser.

          Tell you what, if you post a link to your GitHub showing me the hardened Android ROM that you develop, or heavily contribute to, I would be happy to revise my opinion on your credibility versus those developers.

          • Skull giver@popplesburger.hilciferous.nl
            link
            fedilink
            English
            arrow-up
            0
            ·
            1 month ago

            You make claims like “that means one website can take over your entire phone” and I reject that. I know what these isolation layers do and I also know that they’re not going to make a difference in practice for the vast majority of people. For instance, same-site isolation, which you specifically mentioned, is not a defence against anything but CORS bypasses and maybe some memory leaks. Firefox not having it is suboptimal, but it’s hardly the end of the world. Just rather annoying to let them open themselves up to the risk of side channel attacks and such.

            The Android sandbox is designed to sandbox entire binaries. That alone should withstand any malware that enters the phone, or at least constrain it within a sandbox. If that sandbox is broken, GrapheneOS itself is broken. There are CVEs and CVE chains to break out of that sandbox in unpatched version of Android and there are probably a few that are present but haven’t been discovered by the good guys yet, but that’s the part that prevents any app from taking over your phone. It’s also why rooting your phone is such a hassle if you don’t have an unlocked bootloader.

            That’s also what Firefox is supposedly “crippling” by not using Googles process sandboxing API. That just shows that GrapheneOS assumes their sandbox to be broken to the point where every app is crippling their security by not calling the APIs used for process isolation.

            The kind of browser protections you’re arguing for are defence-in-depth measures. They lengthen the kill chain of certain families of exploits by requiring more workarounds and making exploits less stable and efficient. That’s no doubt good for security in general, and I’m not denying Firefox has work to do here, because Google is ahead of them.

            However, their browsing recommendations are only valid for their threat model. That includes “always disable USB”, “always hide your IP address”, “sacrifice RAM and performance for better ASLR”, “break API compatibility to enforce better malloc rules”, and tons of other modifications that are protections against the most advanced kinds of malware. Of any if this were a problem, the average Android user with their four month old copy of Chrome on their two years outdated Android phone would get hacked every single day. Writing reliable Android exploits is actually quite hard because every manufacturer likes to alter their ROMs in tiny but annoyingly significant ways. Your ROP chains don’t line up anymore, your kernel exploit needs to call a different method, the ROM comes with a different version of a driver for no good reason, it’s almost security-through-annoyance.

            The protections Graphene provides are similar to those of an iPhone in lockdown mode (a severely underused mode, in my opinion, one that mainline Android should include). It protects against vicious malware that’s made by people with vast resources through several levels of defence in depth and sacrificing usability for security where necessary, to the point they call themselves “an operating system with Android app compatibility”. It’s why only GrapheneOS and the latest (well-configured) iPhone were shown to be resistent to hacking tools such as Celebrite. Excellent for journalists, human rights activists, and other potential targets of such directed advanced malware. Hardly a problem for the majority of the population whose malware exposure is “your WhatsApp is outdated click here to install WhatsApp.apk” and “download super gambler from the Play Store and Elon Musk will send you free crypto”.

            For some perspective, compare GrapheneOS’ opinions on Gecko with those of DivestOS, which provides a more nuanced recommendation. They recommend their Mull and Tor for privacy reasons, despite the lack of the two isolation features GrapheneOS is so adamant about. They also mention dynamic first party isolation, which Firefox implements but Chromium doesn’t, and which even Vanadium doesn’t have a comparable implementation.

            You said users should understand the risks associated with their browser choices, and I agree. I just don’t think the risk is as high as you seem to think. And no, I’m not developing an Android ROM, and even if I should, that wouldn’t make me more or less reliable on a forum like this. When it comes to browsers, my recommendation would be “use Mull for privacy against advertisers and data brokers, buy a Pixel and use Vanadium or buy an iPhone and put it in lockdown mode if you’re afraid of one or more governments”.

            • circuscritic@lemmy.ca
              link
              fedilink
              English
              arrow-up
              0
              ·
              edit-2
              1 month ago

              What if I told you I work in information security, and your not impressing me, or tripping me up, by using terms like defense in depth and attack chains, nor am I confused and unable see through your misrepresenting Graphene’s threat model to imply it only matters for high threat risk individuals.

              Just because I said I don’t have enough low level understanding of Android development to refute those devs write-ups on Android browser security, doesn’t mean I’m coming here without a professionally informed understanding of security, and all the terms you keep throwing out to muddy the issue.

              So, I’ll leave it there. I will take my professional knowledge and experiences, along with my judgment on which sources I incorporate into my broader understanding of this situation, and agree to disagree with your analysis and conclusions.