this post was submitted on 30 Apr 2024
65 points (100.0% liked)

Technology

37713 readers
369 users here now

A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.

Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.

Subcommunities on Beehaw:


This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] xnx@slrpnk.net 6 points 6 months ago (4 children)
[–] flux@beehaw.org 6 points 6 months ago

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.

[–] Kissaki@beehaw.org 5 points 6 months ago

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@lemmy.sdf.org 1 points 6 months ago (2 children)

What about Session, the Signal fork?

[–] Cube6392@beehaw.org 2 points 6 months ago

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

[–] xnx@slrpnk.net 2 points 6 months ago (1 children)
[–] sxan@midwest.social 1 points 6 months ago (2 children)

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?

[–] KLISHDFSDF@lemmy.ml 2 points 6 months ago

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@slrpnk.net 1 points 6 months ago

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