• XNX
    arrow-up
    6
    arrow-down
    0
    ·
    6 months ago
    link
    fedilink

    Android only sadly

    • flux
      arrow-up
      6
      arrow-down
      0
      ·
      6 months ago
      link
      fedilink

      As I understand it, these kind of applications depend on being able to perform activities in the background, which is highly limited in iOS for battery efficiency reasons–and maybe for privacy.

      Many years ago I was working on a project that shared connectivity details over wifi/bt, and iOS was troublesome also due to the application not being aware of the local bluetooth address.

      Possibly similar issues impact other mesh networking applications on the platform.

    • KissakiEnglish
      arrow-up
      5
      arrow-down
      0
      ·
      6 months ago
      link
      fedilink

      https://code.briarproject.org/briar/briar/-/wikis/FAQ#will-there-be-an-ios-version-of-briar

      We’re looking into whether an iOS version is feasible.

      A typical iOS messaging app would use a push notification to wake the app when a message is received, but this exposes metadata to Apple’s push notification service and the app developer’s push gateway

      If we don’t use push notifications then the best Apple allows us to do is wake up every 15 minutes and check for messages. But maybe the sender won’t be online when we check (their 15 minute intervals might not be aligned with ours - clocks aren’t perfect).

    • 6jarjar6
      arrow-up
      1
      arrow-down
      0
      ·
      6 months ago
      link
      fedilink

      What about Session, the Signal fork?

      • XNX
        arrow-up
        2
        arrow-down
        0
        ·
        6 months ago
        link
        fedilink

        That is meshnet based

        • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍
          arrow-up
          1
          arrow-down
          0
          ·
          6 months ago
          link
          fedilink

          And? It works on iOS.

          I’m missing the point. Was it that systems like Briar can’t work in iOS because they aren’t mesh net? If so, why not choose one that does, like Session?

          • ᗪᗩᗰᑎ
            arrow-up
            2
            arrow-down
            0
            ·
            6 months ago
            link
            fedilink

            For anyone considering Session messenger:


            The Session developers dropped Perfect Forward Secrecy because it would be hard to work around it.

            First things first, let’s talk about what we’re leaving behind: Perfect Forward Secrecy (PFS) and deniability.

            Source: https://getsession.org/session-protocol-explained

            In plain English, they dropped a security feature for their convenience to the detriment of their users’ security.

            For anyone unsure what PFS provides:

            The value of forward secrecy is that it protects past communication.

            Source: https://en.wikipedia.org/wiki/Forward_secrecy

            The Session devs also claim:

            Session provides protections against these types of threats in other ways — through fully anonymous account creation, onion routing, and metadata minimisation, for example.

            Reading between the lines, we can interpret that as introducing security through obscurity, which is generally considered bad practice - https://cwe.mitre.org/data/definitions/656.html

          • XNX
            arrow-up
            1
            arrow-down
            0
            ·
            6 months ago
            link
            fedilink

            The point is being able to communicate when the internet is shut off

      • The CuuuuubeEnglish
        arrow-up
        2
        arrow-down
        0
        ·
        6 months ago
        link
        fedilink

        Session has made some insecure solution surrounding important design elements like forward secrecy